Jak testować formularz rejestracji?

Formularz wyświetla „Konto utworzone”. Czy rejestracja rzeczywiście się powiodła? Sam komunikat tego nie rozstrzyga. Trzeba porównać zachowanie aplikacji z wymaganiami, obejrzeć odpowiedź serwera i sprawdzić, czy powstało konto. W tej lekcji przygotujesz dane, wykonasz testy granic, zajrzysz do DevTools i opiszesz znaleziony błąd tak, aby inna osoba mogła go odtworzyć.

Materiał jest przeznaczony dla początkujących testerów aplikacji webowych. Wystarczy umieć wypełnić formularz i uruchomić polecenie w terminalu. Kod JavaScript pojawi się tylko jako opcjonalne ułatwienie przygotowania danych. Pracujemy na lokalnym demo z celowymi defektami; wszystkie adresy i hasła w przykładach są syntetyczne.

1. Ustal, co oznacza poprawna rejestracja

Zanim wpiszesz pierwszą wartość, zapisz kryteria akceptacji: warunki, po których uznasz funkcję za działającą poprawnie. Bez nich można pomylić własne oczekiwanie z wymaganiem projektu. To szczególnie ważne przy hasłach, adresach e-mail i zgodach, ponieważ różne produkty przyjmują różne reguły.

Laboratorium v1.0 ma pięć kontrolek: e-mail, hasło, powtórzenie hasła, akceptację regulaminu DEMO oraz dobrowolny marketing. Obowiązują następujące wymagania:

• E-mail jest wymagany. Spacje z początku i końca są usuwane. Demo przyjmuje uproszczony format local@domain.tld.
• Hasło ma od 12 do 64 widocznych znaków ASCII (od ! do ~) i nie zawiera spacji. Cyfra, wielka litera oraz znak specjalny nie są wymagane.
• Powtórzenie ma być identyczne z hasłem, włącznie z wielkością liter.
• Regulamin DEMO trzeba zaakceptować. Marketing jest opcjonalny i domyślnie wyłączony.
• Poprawne wysłanie tworzy jedno konto demo i zwraca HTTP 201. Duplikat adresu zwraca HTTP 409; błąd walidacji backendu — HTTP 422.
• Awaria serwera lub brak połączenia nie mogą zostać przedstawione jako sukces. Podczas oczekiwania formularz blokuje ponowne wysłanie.

Te reguły są specyfikacją ćwiczenia. Uproszczony format e-maila nie opisuje wszystkich poprawnych adresów według standardów poczty. Limit ASCII i długość hasła służą nauce granic; nie są rekomendacją polityki haseł dla produktu. Nie dodawaj wymagania wielkiej litery tylko dlatego, że widziałeś je w innym serwisie.

Każdy test kończy się porównaniem wyniku z konkretną regułą. Samo wykonanie kliknięć nie daje jeszcze oceny.

2. Przygotuj środowisko i stan początkowy

Otwórz terminal w katalogu projektu i uruchom lokalny serwer:

node tools/serwer-lekcji.cjs

Następnie otwórz w przeglądarce adres:

http://127.0.0.1:8787/content/cwiczenia/formularz-rejestracji/lab.html

Potrzebujesz dostępnego polecenia node; serwer nie wymaga instalowania pakietów przez npm. Nie otwieraj formularza dwuklikiem jako file://, ponieważ ćwiczenie korzysta z lokalnego API. Jeśli port 8787 jest zajęty albo terminal zgłasza brak Node, najpierw usuń problem uruchomienia. Taki wynik nie mówi jeszcze nic o poprawności formularza.

Demo przechowuje konta w pamięci procesu serwera. Nie zapisuje hasła, nie wysyła poczty i nie aktywuje kont. Po restarcie lub zresetowaniu stanu wraca adres początkowo zajęty: zajety@example.com. Adres qa@example.com można wykorzystać do poprawnej rejestracji. Przed niezależnym scenariuszem użyj przycisku resetowania stanu; samo odświeżenie strony nie jest resetem serwera.

Zanotuj datę, system, wersję przeglądarki i wersję laboratorium. Po każdej zmianie trybu sprawdź ustawienia: zwykła odpowiedź serwera oraz sieć bez symulowanego ograniczenia. Dzięki temu błąd pozostawionego trybu Offline nie zostanie pomylony z kolejnym defektem aplikacji.

3. Wybierz dane, które sprawdzają reguły

Nie potrzebujesz stu losowych haseł. Klasa równoważności to grupa danych, dla których według wymagania oczekujesz podobnego zachowania. Przykładowo hasła o dozwolonej długości tworzą jedną klasę, a zbyt krótkie — inną. Wartość graniczna leży na krawędzi takiej grupy albo tuż obok niej.

Poniższa tabela jest planem testów dla naszego demo, nie listą gwarantowanych wyników jego wadliwej wersji.

Przy badaniu długości powtórz dokładnie to samo hasło w drugim polu. Używaj świeżego adresu i zaznaczonego regulaminu. Zmieniaj jedną rzecz naraz: inaczej odrzucenie z powodu zajętego e-maila może zasłonić błąd limitu hasła. Marketing świadomie wyłącz, aby nie mieszać testu danych z testem wyboru zgody.

Do przygotowania 64 i 65 znaków możesz użyć w konsoli DevTools wyrażeń 'a'.repeat(64) oraz 'a'.repeat(65), a następnie skopiować wynik bez otaczających cudzysłowów. To generator danych, nie skrypt testujący aplikację. Jeżeli pole ogranicza wklejenie do 64 znaków, zanotuj tę obserwację; sam formularz nie sprawdzi wtedy odrzucenia 65 znaków przez backend.

Dane graniczne sprawdzają obie strony limitu. Wszystkie znaki w tym przykładzie to litery ASCII.

4. Wykonaj poprawną ścieżkę i sprawdź Network

Zacznij od scenariusza bazowego. Resetuj stan, wpisz qa@example.com, hasło i powtórzenie abcdefghijkl, zaakceptuj regulamin, wyłącz marketing. Dopiero wtedy wyślij formularz. Ten test ustala punkt odniesienia dla późniejszych prób negatywnych.

Na Windows otwórz DevTools skrótem Ctrl+Shift+I, wybierz Network i upewnij się, że rejestrowanie jest włączone. Panel pokazuje żądania zarejestrowane podczas pracy narzędzia; otwórz go przed wysłaniem formularza. Włącz filtr Fetch/XHR i wpisz register, aby znaleźć wywołanie rejestracji. Przed kolejną próbą wyczyść listę. Chrome DevTools: obserwowanie ruchu sieciowego.

Kliknij żądanie i sprawdź Headers: metodę POST, adres /api/register i status. W Payload porównaj wysłane dane z formularzem, szczególnie marketing. W Response odczytaj odpowiedź. Te widoki opisuje referencja panelu Network.

W poprawnym scenariuszu wymagamy HTTP 201 i nowego konta. Porównaj komunikat interfejsu ze stanem demo dostępnym przez GET /api/state. Możesz otworzyć http://127.0.0.1:8787/api/state w drugiej karcie. Odśwież ją po próbie i znajdź użyty adres. Zapisuj osobno: „UI pokazuje sukces”, „odpowiedź 201” i „konto widoczne w stanie”. To trzy dowody dotyczące różnych części przepływu.

Następnie wyślij ten sam adres drugi raz. Oczekuj HTTP 409 i komunikatu o konflikcie, bez kolejnego konta. Status HTTP oraz treść odpowiedzi interpretuje się razem z umową API; sam numer nie wyjaśnia całego zachowania. W prawdziwym produkcie ustal również, co kończy rejestrację: utworzenie rekordu, wysłanie wiadomości czy aktywacja linkiem. Demo kończy ją na lokalnym koncie.

5. Oddziel walidację przeglądarki od walidacji serwera

Frontend to część aplikacji działająca w przeglądarce. Backend obsługuje żądania po stronie serwera. Komunikat obok pola może pochodzić z HTML lub JavaScript i pojawić się przed jakimkolwiek żądaniem. Sprawdź Network: jeśli nie ma nowego wywołania /api/register, serwer nie otrzymał tej próby.

Walidację klienta można obejść, dlatego serwer musi sam kontrolować dane. To zasada opisana w MDN: walidacja formularzy. Usunięcie atrybutu HTML required nie dowodzi jednak, że ominąłeś każdą regułę — aplikacja może nadal sprawdzać dane w JavaScript. MDN: Constraint Validation.

W tym ćwiczeniu osobno sprawdź API zgodnie z instrukcją laboratoryjną. Dla pustego e-maila albo braku regulaminu backend powinien zwrócić HTTP 422 i nie utworzyć konta. Porównaj też obie warstwy dla 11 znaków i niezgodnego powtórzenia. Jeśli wadliwy frontend oraz backend przyjmują te same dane, nadal jest to błąd względem wymagania.

Przy braku żądania nie wpisuj w raporcie „serwer odrzucił dane”. Zapisz „formularz zablokował wysłanie”. Przy HTTP 422 możesz opisać odrzucenie przez backend. To rozróżnienie pomaga wskazać zakres defektu bez zgadywania, która linia kodu go powoduje.

6. Sprawdź oczekiwanie, awarię i brak sieci

Odpowiedź demo ma opóźnienie około 500 ms. Kliknij wysyłkę dwukrotnie przed jej nadejściem. Oczekuj jednego żądania rejestracji i zablokowanego przycisku podczas oczekiwania. Licz wyłącznie POST /api/register: pobranie stanu lub reset to inne żądania. Po odpowiedzi przycisk ma umożliwić kolejną świadomą próbę.

Przełącz demo w tryb „Błąd serwera 503”. Przy poprawnych danych oczekujesz błędu, braku sukcesu i niezmienionego stanu kont. Jeśli Network pokazuje 503, a formularz ogłasza utworzenie konta, masz konkretną sprzeczność. Najpierw udokumentuj ją; nie zakładaj automatycznie, że konto powstało mimo awarii.

Jedna z możliwych przyczyn takiej pomyłki to obsługa fetch(). Odpowiedź HTTP z kodem błędu nie powoduje automatycznie odrzucenia jego obietnicy; kod powinien sprawdzić status albo response.ok. Brak połączenia jest innym przypadkiem. To wyjaśnienie mechanizmu, a nie diagnoza kodu na podstawie samego ekranu. MDN: używanie Fetch API.

Po wczytaniu formularza wybierz w menu ograniczania sieci panelu Network Offline, wyślij poprawne dane i obserwuj wynik. Przywróć No throttling przed dalszą pracą. To udokumentowana funkcja Chrome DevTools. Nie utożsamiaj błędu sieci z HTTP 503: w pierwszym przypadku możesz nie otrzymać żadnej odpowiedzi HTTP. W ćwiczeniu sprawdź stan po ponownym połączeniu.

7. Przetestuj wybory użytkownika i dostępność

Sprawdź marketing od razu po otwarciu formularza. Domyślne zaznaczenie łamie wymaganie projektu, nawet jeśli da się je odznaczyć. Wykonaj poprawną rejestrację bez marketingu, a potem osobną próbę z marketingiem świadomie zaznaczonym. Porównaj wybór, Payload i stan konta. Nie oceniaj zgodności prawnej prawdziwego serwisu na podstawie tego uproszczonego ćwiczenia.

Każde pole powinno mieć jednoznaczną etykietę i informację o wymaganiach przed wysłaniem. Sprawdź także nazwę dostępną kontrolki, odczytywaną przez technologie asystujące. Sam napis widoczny obok pola nie gwarantuje powiązania programowego; typowy mechanizm to <label> powiązany z polem. W3C WAI: etykiety formularzy.

Odłóż mysz. Przejdź przez kontrolki klawiszem Tab, wróć przez Shift+Tab, zmień checkbox Spacją i aktywuj wysyłkę klawiaturą. Sprawdź logiczną kolejność, widoczny fokus i możliwość opuszczenia każdej kontrolki. Przy wąskim widoku oraz powiększeniu 200% oceń, czy etykiety, komunikaty i przycisk pozostają dostępne. To kontrola wstępna; W3C WAI Easy Checks nie traktuje prostych sprawdzeń jako pełnej oceny dostępności.

Wywołaj błąd i oceń jego treść: „Hasło musi mieć co najmniej 12 znaków” pomaga poprawić dane; „Nieprawidłowe dane” pozostawia zgadywanie. Oznaczenie nie powinno polegać tylko na czerwonym kolorze. Sprawdź czytnikiem ekranu, czy dynamiczny błąd i sukces są ogłaszane oraz czy wiadomo, którego pola dotyczy problem. Możliwe mechanizmy to powiązanie przez aria-describedby i region komunikatów; samo istnienie atrybutu nie potwierdza użyteczności. W3C WAI: komunikaty formularzy.

8. Opisz błąd, który można odtworzyć

Poniżej znajduje się wzór zgłoszenia dla celowego defektu demo. To przykład rozwiązania, nie zapis przeprowadzonego testu czy przeglądu eksperta. Własny raport uzupełnij rzeczywistą datą, wersją przeglądarki, wynikami i załącznikami.

Tytuł: Rejestracja przyjmuje hasło 11 znaków przy wymaganym minimum 12
Środowisko: lab v1.0, 127.0.0.1:8787; [system i wersja przeglądarki]
Warunki: reset stanu, tryb zwykły, sieć No throttling
Kroki:
1. Wpisz qa@example.com.
2. W obu polach hasła wpisz abcdefghijk (11 znaków).
3. Zaznacz regulamin i wyłącz marketing.
4. Wyślij formularz; sprawdź Network i /api/state.
Oczekiwany wynik: odrzucenie z powodu minimum 12; brak konta.
Wynik rzeczywisty: [komunikat UI, status i treść odpowiedzi, stan kont]
Dowody: [zrzut komunikatu, szczegóły żądania, stan po próbie]
Powtarzalność: [liczba odtworzeń / liczba prób]
Wpływ: konto może powstać z hasłem niespełniającym wymagania.

Oddziel wagę błędu, czyli jego wpływ, od priorytetu naprawy ustalanego w zespole. Nie przypisuj „krytyczny” tylko dlatego, że problem dotyczy hasła. W tym demo nie ma logowania ani przechowywania haseł; skutki produkcyjne trzeba ocenić w rzeczywistym kontekście.

Do raportu dodawaj wyłącznie dane testowe. W pracy z prawdziwym produktem sprawdź załączniki i eksport ruchu przed udostępnieniem: mogą zawierać hasła, tokeny albo dane osobowe. Zrzut czy plik Network powinien potwierdzać problem bez niepotrzebnego ujawniania informacji.

9. Wykonaj ćwiczenie i określ granice wniosku

Przejdź do ćwiczenia z instrukcją i rozwiązaniem. Najpierw przygotuj własne przypadki i spróbuj odnaleźć cztery celowe defekty, a dopiero później przeczytaj rozwiązanie. Użyj checklisty w Markdown albo PDF do pobrania, aby zanotować wyniki i brakujące sprawdzenia.

Po teście nie pisz ogólnie „rejestracja działa”. Podaj zakres: które dane, warstwy i warunki sprawdziłeś, co nie spełniło wymagań, a czego nie oceniałeś. Niewykonany przypadek pozostaje niewykonany. Po poprawce powtórz kroki błędu oraz przypadki sąsiednie, na przykład 11 i 12 znaków, aby wykryć przesunięcie granicy w przeciwną stronę.

Lekcja nie obejmuje audytu bezpieczeństwa, trwałej bazy danych, aktywacji e-mail, limitów prób, równoczesnych żądań wielu klientów ani pełnej zgodności WCAG. Blokada przycisku nie rozwiązuje wszystkich problemów współbieżności. Lokalny HTTP i konto w RAM nie są wzorcem systemu produkcyjnego. Zdobyta umiejętność to sprawdzanie wymagania na podstawie danych i dowodów z interfejsu oraz serwera.

Źródła dokumentacyjne sprawdzono 2 października 2026 r. Tego dnia wykonano weryfikację techniczną laboratorium w Node v24.16.0 i Chromium 151.0.7922.34: potwierdzono cztery celowe defekty, poprawną rejestrację, wskazane granice, wybrane błędy backendu, wybór marketingu, obsługę braku połączenia i widok 360 px. Nie był to pełny audyt bezpieczeństwa ani dostępności. Nazwy paneli podano w języku angielskim; wygląd DevTools może różnić się między wersjami. Autor serwisu: Marcin Kozłowski. Tekst przygotowano z pomocą AI.