„Rejestracja nie działa” opisuje frustrację, ale nie daje drugiej osobie sposobu sprawdzenia problemu. Czy formularz nie pozwala wpisać danych, wysyła błędne żądanie, pokazuje niewłaściwy komunikat czy nie tworzy konta? Dobre zgłoszenie pozwala rozstrzygnąć te pytania bez odgadywania przebiegu testu. W tej lekcji przygotujesz raport dla konkretnej sprzeczności: interfejs ogłasza utworzenie konta, mimo że lokalne API odpowiada błędem i konta nie ma w stanie serwera.
Materiał jest przeznaczony dla początkujących testerów, którzy potrafią wypełnić formularz i otworzyć Network. Jeśli to nowe pojęcie, zacznij od lekcji o żądaniach i odpowiedziach. Nie potrzebujesz systemu zgłoszeń: wystarczy plik tekstowy. Celem jest jakość informacji, którą możesz później przenieść do narzędzia zespołu. Wszystkie dane w ćwiczeniu są syntetyczne; demo nie prowadzi prawdziwej rejestracji użytkowników.
1. Najpierw sprawdź, co jest wymaganiem
Błąd rozpoznajesz przez porównanie zaobserwowanego zachowania z ustaloną regułą. Nie zaczynaj raportu od diagnozy „backend jest zepsuty”. Najpierw ustal, co miało nastąpić. W naszym laboratorium sukces oznacza HTTP 201 i utworzenie konta w pamięci serwera. Dla symulowanej awarii 503 wymagamy komunikatu błędu, braku sukcesu i niezmienionego stanu kont.
Źródłem tego oczekiwania są wymagania ćwiczenia, a nie intuicja dotycząca koloru komunikatu. W rzeczywistym projekcie wskaż kryterium akceptacji, opis API lub uzgodnioną regułę. Jeśli wymaganie jest niejasne, zanotuj pytanie do ustalenia. Obserwacja nadal może być wartościowa, ale nie przedstawiaj własnej preferencji jako zatwierdzonej specyfikacji.
Przygotuj krótkie zdanie opisujące różnicę: „W trybie awarii API zwraca 503 i nie tworzy konta, ale formularz pokazuje sukces”. Jest już bardziej użyteczne niż „problem z rejestracją”. Nadal nie podaje przyczyny w kodzie. Do odtworzenia defektu wystarczy udokumentować sprzeczność; wyjaśnienie mechanizmu można dodać oddzielnie, jeśli zostało sprawdzone.
2. Przygotuj warunki, które da się przywrócić
Uruchom serwer w katalogu projektu:
node tools/serwer-lekcji.cjsOtwórz http://127.0.0.1:8787/content/cwiczenia/formularz-rejestracji/lab.html. Potrzebujesz polecenia node i działającego portu 8787. Formularza nie uruchamiaj jako pliku file://, ponieważ korzysta z lokalnego API. Jeśli strona się nie wczytuje, rozwiąż problem uruchomienia przed testem rejestracji.
Kliknij „Resetuj ćwiczenie”. Sprawdź, czy stan zawiera tylko początkowy adres zajety@example.com. Reset obejmuje stan API i formularz; odświeżenie strony nie usuwa kont. Ustaw sieć na No throttling, a następnie włącz przełącznik „Błąd serwera 503”. Zanotuj te warunki w raporcie. Pozostawiony Offline albo wcześniej utworzony adres może dać zupełnie inny wynik.
Do prób użyj raport@example.com, hasła i powtórzenia abcdefghijkl, zaznaczonego regulaminu oraz wyłączonego marketingu. Zapis danych ma pozwolić drugiej osobie odtworzyć scenariusz. W tym demo hasło jest fikcyjne i nie jest przechowywane. W produkcie nie dołączaj prawdziwego hasła użytkownika tylko dlatego, że pole wymaga konkretnej wartości.
Trzy obserwacje wspierają jeden wniosek. Sam komunikat na ekranie nie dowodzi utworzenia konta.
3. Wykonaj jedną próbę i zachowaj jej dowody
Otwórz DevTools skrótem Ctrl+Shift+I, wybierz Network, włącz rejestrowanie i wyczyść listę. Użyj filtra Fetch/XHR oraz tekstu register. Kliknij „Utwórz konto” i poczekaj na zakończenie. W szczegółach nowego POST /api/register sprawdź Headers, Payload i Response. Te funkcje opisuje dokumentacja Chrome DevTools.
Zapisz osobno komunikat formularza, status i treść odpowiedzi. Następnie usuń filtr, sprawdź GET /api/state albo odczytaj aktualny panel kont. Adres raport@example.com nie powinien pojawić się w stanie po awarii. Nie łącz odpowiedzi jednej próby ze zrzutem innej; taki raport może wyglądać przekonująco i jednocześnie opisywać nieistniejący przebieg.
W weryfikacji technicznej tej lekcji wykonano opisaną próbę automatycznie w Chromium 151.0.7922.34. Otrzymano HTTP 503 oraz odpowiedź {"error":"Symulowana awaria serwera. Konto nie powstało."}. Formularz pokazał „Konto zostało utworzone.”, a GET /api/state zawierał tylko zajety@example.com. To potwierdza defekt lokalnej demonstracji. Nie wykonano przy tym ręcznej kontroli kliknięć w panelu DevTools ani testu rzeczywistego systemu rejestracji.
Jeżeli własna próba daje inny wynik, wpisz właśnie ten wynik. Sprawdź ustawienia i wersję labu, a następnie powtórz od początku. Nie przepisuj rozwiązania do sekcji „wynik rzeczywisty” bez wykonania testu. Raport jest zapisem obserwacji, a rozwiązanie lekcji jedynie punktem porównania.
4. Napisz tytuł i kroki bez ukrytych zależności
Dobry tytuł wskazuje obszar, warunek i objaw: „Rejestracja pokazuje sukces po odpowiedzi HTTP 503, mimo braku konta”. Tytuł „Błąd krytyczny w backendzie” pomija obserwowany objaw i od razu narzuca niepotwierdzoną interpretację. Nie potrzebujesz numeru linii kodu ani nazwy osoby odpowiedzialnej, aby problem został zrozumiany.
Warunki początkowe oddziel od numerowanych kroków. „Reset stanu; No throttling; tryb 503” to informacje potrzebne przed akcją. „Wpisz e-mail”, „zaznacz regulamin”, „wyślij” to kroki. Zapis „wypełnij poprawnie” jest zbyt szeroki: jedna osoba wyłączy marketing, druga pozostawi go zaznaczonego. Podaj wartości oraz wybory wpływające na próbę.
Nie opisuj wszystkich kliknięć od uruchomienia komputera. Potrzebna jest minimalna, kompletna droga do defektu. Jeśli powtórzenie nie wymaga przewijania czy zmiany wielkości okna, nie dodawaj tych szczegółów jako koniecznych kroków. Jeśli natomiast błąd występuje tylko przy określonej szerokości, ta wartość staje się warunkiem odtworzenia i nie można jej pominąć.
Po zapisaniu raportu wykonaj go jeszcze raz, korzystając wyłącznie z własnych instrukcji. Czy trzeba dopowiedzieć, że adres ma być nowy? Czy stan serwera został zresetowany? Czy przełącznik awarii jest włączony? Takie uzupełnienia kosztują mniej niż późniejsza wymiana pytań z odbiorcą zgłoszenia.
5. Rozdziel oczekiwanie, wynik i interpretację
Sekcja „oczekiwany wynik” opisuje wymagane zachowanie: „Komunikat błędu, brak komunikatu sukcesu, brak nowego konta”. Sekcja „wynik rzeczywisty” opisuje to, co odczytano: komunikat UI, HTTP 503, treść odpowiedzi i brak adresu w stanie. Sekcja „wpływ” wyjaśnia konsekwencję: użytkownik otrzymuje fałszywe potwierdzenie zakończenia operacji.
Nie wpisuj „konto zniknęło”, jeżeli nie masz dowodu wcześniejszego utworzenia konta. Nie wpisuj „baza danych nie działa”, skoro demo ma tylko stan w pamięci. Nie wpisuj „serwer nie odpowiedział”, gdy otrzymałeś 503. Takie sformułowania zmieniają znaczenie danych i mogą skierować naprawę w niewłaściwą stronę.
Mechanizm fałszywego sukcesu można wyjaśniać osobno: fetch() nie odrzuca automatycznie obietnicy dla odpowiedzi HTTP z kodem błędu. Kod obsługi musi ocenić odpowiedź. MDN: Using Fetch. W tym labie kod wręcz traktuje 503 jak sukces. Sam wygląd ekranu w obcym produkcie nie wystarcza jednak do przypisania identycznej przyczyny.
6. Dobierz dowody do twierdzenia
Zrzut komunikatu potwierdza tekst UI. Zapis statusu i odpowiedzi potwierdza zachowanie API. Stan kont potwierdza wynik operacji w zakresie demonstracji. Każdy załącznik powinien mieć krótki opis: czego dowodzi, z której próby pochodzi i jaki fragment odbiorca ma obejrzeć. Film nie zastępuje tekstowych kroków, a dziesięć podobnych zrzutów nie zastępuje jednego istotnego dowodu.
Przed udostępnieniem sprawdź treść danych. Żądanie rejestracji zawiera hasło testowe; w rzeczywistym systemie zapis ruchu może zawierać również sesję, token albo dane osoby. Dokumentacja Network rozróżnia eksport HAR z ograniczeniem danych wrażliwych i eksport obejmujący takie dane. Nie zakładaj, że wybrany tryb usuwa każdą informację poufną z dowolnego Payload. Przejrzyj załącznik zgodnie z zasadami projektu.
Sposób zebrania dowodów ma być proporcjonalny do problemu. Dla błędnego domyślnego checkboxa wystarczy zapis stanu po resecie i czytelny zrzut. Dla fałszywego sukcesu potrzebne jest porównanie kilku warstw. Samo pole „załącznik” w narzędziu nie czyni raportu kompletnym.
7. Waga, priorytet i powtarzalność
Waga opisuje wpływ problemu, a priorytet kolejność jego obsługi. Te pola są odrębne także w sylabusie ISTQB CTFL v4.0.1, sekcja 5.5. Opisz skutek zanim wybierzesz etykietę. „Fałszywe potwierdzenie może skłonić do zakończenia próby mimo braku konta” jest argumentem; „to ważne” nie wyjaśnia wpływu.
W demo nie ma prawdziwych klientów, płatności ani logowania. Nie przypisuj mu nieudokumentowanych strat finansowych. W produkcie uwzględnij skalę, częstość warunku, możliwość obejścia i znaczenie ścieżki dla użytkowników. Propozycja testera może zostać zmieniona przez zespół po porównaniu z innymi problemami.
Powtarzalność zapisuj jako liczby: „2 odtworzenia na 2 próby po resecie”, jeśli rzeczywiście wykonałeś dwie. Jedna udana reprodukcja nie uzasadnia słowa „zawsze”. Przy niestabilnym problemie zachowaj również warunki prób bez defektu. Różnica może pomóc zawęzić problem, ale jej domniemana przyczyna pozostaje hipotezą.
8. Zadanie: przygotuj raport i sprawdź jego kompletność
Wykonaj scenariusz 503, zapisz własny raport i przejdź przez checklistę zgłoszenia, dostępną także jako PDF. Następnie przygotuj drugi raport dla przyjęcia hasła abcdefghijk, czyli 11 znaków przy minimum 12. Użyj osobnego resetu i zwykłego trybu serwera. Nie łącz obu problemów w jedno zgłoszenie tylko dlatego, że dotyczą tego samego formularza.
W drugim raporcie wymaganiem jest minimum długości, a dowodami wynik rejestracji oraz stan kont. W pierwszym wymaganiem jest obsługa awarii. Takie rozdzielenie umożliwia niezależną ocenę, naprawę i ponowne sprawdzenie obu defektów. Nie dopisuj wyników drugiego raportu, dopóki nie wykonasz własnej próby.
9. Rozwiązanie: wzór dla fałszywego sukcesu
Tytuł: Rejestracja pokazuje sukces po HTTP 503, mimo braku konta
Środowisko: lab 1.0, adres lokalny; [system, przeglądarka, data]
Warunki: reset; No throttling; włączony Błąd serwera 503
Kroki:
1. Wpisz raport@example.com.
2. Wpisz abcdefghijkl w obu polach hasła.
3. Zaznacz regulamin; wyłącz marketing.
4. Wyślij formularz i odczytaj UI, POST /api/register oraz stan.
Oczekiwanie: błąd bez sukcesu; brak konta zgodnie z wymaganiem.
Wynik: [własny komunikat, status, odpowiedź i stan]
Dowody: [identyfikatory załączników z tej próby]
Powtarzalność: [odtworzenia / wszystkie próby]
Wpływ: nieprawdziwe potwierdzenie zakończenia rejestracji.Dla potwierdzonego przebiegu z sekcji 3 wynik uzupełnia się konkretnymi obserwacjami, nie samym słowem „błąd”. Po poprawce wykonaj ponownie identyczny scenariusz w wskazanej wersji. Sprawdź także zwykłą rejestrację i duplikat: naprawa komunikatu 503 nie powinna zamienić poprawnego 201 w błąd ani 409 w sukces. Potwierdzenie naprawy i regresja mają różne cele.
Źródła odczytano 2 października 2026 r. Własna weryfikacja objęła jedną automatyczną próbę 503 w Chromium 151.0.7922.34 i zapis trzech wyników; nie była oceną produkcyjnej rejestracji. Autor serwisu: Marcin Kozłowski. Materiał przygotowano z pomocą AI. Dalsza lekcja: projektowanie przypadków testowych.
Research i tekst: GPT-6.1 Sol, reasoning medium.