Testy eksploracyjne: poprowadź sesję według ryzyka

Masz pół godziny na sprawdzenie formularza. Możesz kolejno wpisywać przypadkowe dane albo zacząć od pytania: „Czy aplikacja mówi prawdę o wyniku rejestracji?”. Drugie podejście nadaje próbom kierunek. Wynik pierwszego testu pomaga wybrać następny, a notatki pozwalają później wyjaśnić, co sprawdzono i czego jeszcze nie wiadomo.

W tej lekcji przygotujesz krótką sesję eksploracyjną dla formularza demonstracyjnego. Sesja oznacza ograniczony czas na badanie określonego celu i zapis jego rezultatów. Nie jest obietnicą znalezienia każdego defektu. Potrzebujesz podstaw obsługi formularza oraz Network. Wszystkie dane są syntetyczne, a konta istnieją jedynie w pamięci lokalnego serwera.

1. Eksploracja ma cel i ślad wykonania

W testowaniu eksploracyjnym projektujesz próby, wykonujesz je i oceniasz podczas poznawania obiektu. Krótka definicja oraz wykorzystanie sesji z celem i ograniczeniem czasu występują w ISTQB CTFL v4.0.1, sekcja 4.4.2. Kolejność prób może się zmieniać, ale powinna wynikać z obserwacji, nie z utraty koncentracji.

Nie musisz wybierać między eksploracją a wcześniej zapisanymi przypadkami. Gotowa próba poprawnej rejestracji może ustalić punkt odniesienia, a wartości graniczne pomóc zbadać odkryte podejrzenie. Eksploracja korzysta z takich narzędzi wtedy, gdy odpowiadają na aktualne pytanie.

Plan „przetestuję cały formularz” jest zbyt szeroki na pół godziny. Cel „porównam komunikat rejestracji z API i stanem kont dla sukcesu, konfliktu i awarii” pozwala rozpoznać zarówno wykonane sprawdzenia, jak i granicę sesji. Po jej zakończeniu można wskazać, że długość hasła i dostępność pozostały do osobnego badania.

2. Zapisz kartę sesji przed startem

Karta sesji, nazywana też charterem, jest krótką instrukcją kierującą badaniem. Poniższy wzór jest autorskim sposobem organizacji ćwiczenia, a nie obowiązkowym formatem narzędzia:

Cel: porównać wynik UI, API i stan kont w rejestracji.
Obszar: formularz demo v1.0 i lokalne /api/register oraz /api/state.
Ryzyko: fałszywe potwierdzenie zakończenia operacji.
Zasoby: przeglądarka, Network, syntetyczne dane, wymagania labu.
Próby początkowe: poprawne dane, duplikat, tryb 503.
Czas: 20 minut badania + 10 minut uporządkowania wyników.
Poza zakresem: logowanie, aktywacja pocztą, obciążenie, audyt WCAG.
Rezultat: notatka pokrycia, dowody, zgłoszenia i kolejne pytania.

Ten podział czasu jest propozycją ćwiczenia. Nie opisuje wykonanej trzydziestominutowej sesji autora. Ustaw własny licznik i zapisz rzeczywisty początek oraz koniec. Przerwa na naprawę środowiska nie powinna znikać z notatki ani być przedstawiana jako badanie produktu.

Zapisz także warunki: adres lokalny, wersję przeglądarki, stan po resecie i ustawienie sieci. Sesja prowadzona po przypadkowym pozostawieniu Offline może badać coś zupełnie innego niż zaplanowane 503. Przed każdą niezależną próbą sprawdź, które ustawienia zachowujesz celowo, a które przywracasz.

3. Wybierz obszar na podstawie skutku problemu

Ryzyko produktu dotyczy możliwości niepożądanego zachowania i jego wpływu. W ćwiczeniu możesz porównać trzy pytania: czy dane niespełniające reguł są przyjmowane, czy UI błędnie potwierdza operację oraz czy formularz zachowuje wybór marketingu. Każde ma inny warunek i sposób oceny.

Nie zaczynaj od kolorów przycisku tylko dlatego, że łatwo je obejrzeć. Jeżeli celem produktu jest niezawodne utworzenie konta, prawdziwość wyniku ma duże znaczenie. W innym kontekście niedostępny przycisk może blokować całą ścieżkę dla części użytkowników i wymagać pierwszeństwa. Kolejność wynika z produktu i użytkowników, nie z uniwersalnej listy.

To przykładowa analiza dla demo. Nie oceniamy na jej podstawie produkcyjnej ochrony haseł ani zgodności prawnej zgód. Nie ma prawdziwych kont, odbiorców wiadomości czy utrwalonych haseł. Nazwij ten zakres, zamiast dopisywać efekt, którego laboratorium nie może pokazać.

4. Używaj ocen liczbowych jako pomocy do rozmowy

Możesz zapisać wpływ oraz prawdopodobieństwo w prostej skali 1–3. Zdefiniuj znaczenie skali przed przypisaniem wartości: wpływ 1 oznacza drobną niedogodność, 2 utrudnienie z obejściem, 3 niemożność zakończenia zadania albo mylący wynik kluczowej operacji. Prawdopodobieństwo dotyczy wystąpienia warunku w określonym kontekście; bez danych będzie tylko hipotezą.

Iloczyn wpływ × prawdopodobieństwo jest umownym wskaźnikiem pomocniczym. Wartości 3 × 2 = 6 i 2 × 3 = 6 nie opisują tego samego problemu. Skale porządkowe nie stają się dokładnym modelem ekonomicznym przez mnożenie. Nie podawaj „ryzyka 66%” na podstawie punktów 6 z 9.

W lokalnym ćwiczeniu przełącznik 503 pozwala wymusić warunek, ale nie mówi, jak często występują awarie prawdziwego serwisu. Wpływ fałszywego sukcesu możesz opisać na podstawie zachowania, a częstość wymagałaby danych operacyjnych. Zapis „prawdopodobieństwo do ustalenia” jest bardziej uczciwy niż pozornie precyzyjna liczba.

Wynik próby steruje kolejnym krokiem. Notatka przechowuje powód decyzji i granice wniosku.

5. Przeprowadź początek sesji krok po kroku

Uruchom node tools/serwer-lekcji.cjs i otwórz http://127.0.0.1:8787/content/cwiczenia/formularz-rejestracji/lab.html. Kliknij reset, ustaw No throttling i zwykły tryb serwera. Użyj sesja@example.com, identycznych haseł abcdefghijkl, zaznaczonego regulaminu i wyłączonego marketingu. Otwórz Network przed wysłaniem i wyczyść stare wpisy.

Pierwsza próba ustala punkt odniesienia. Po wysłaniu sprawdź komunikat, POST /api/register i stan kont. Oczekujesz 201 oraz obecności adresu. Następnie wyślij identyczny adres bez resetu: teraz warunkiem jest duplikat, więc oczekujesz 409 i braku dodatkowego konta. Ten sam zestaw danych ma inny wynik oczekiwany w innym stanie.

Po resecie włącz 503 i użyj poprawnych danych. Sprawdź trzy warstwy. Defekt demonstracji polega na sukcesie UI przy odpowiedzi 503 i braku konta. W weryfikacji lekcji rzeczywiście odtworzono ten przebieg automatycznie, używając adresu raport@example.com; nie była to pełna sesja z pomiarem dwudziestu minut.

Gdy zobaczysz sprzeczność, nie skacz od razu do dziesięciu kolejnych funkcji. Zapisz kroki i dowody. Powtórz próbę po resecie, jeżeli pozwala na to czas sesji. Dopiero później wybierz następne pytanie, na przykład czy zwykły tryb nadal działa albo czy fałszywy sukces dotyczy także konfliktu. Jedna obserwacja prowadzi do hipotezy, a kolejna próba ją sprawdza.

6. Rozdziel eksplorację od niekontrolowanej zmiany danych

Jeśli jednocześnie zmienisz hasło, e-mail, regulamin, tryb awarii i sieć, trudno będzie wyjaśnić wynik. W początkowym zawężaniu zmieniaj jeden istotny warunek. Po ustaleniu jego roli możesz celowo sprawdzić kombinację, ale zapisz pytanie, które ta kombinacja ma rozstrzygnąć.

Przykład: po fałszywym sukcesie 503 chcesz ustalić, czy konto mogło powstać mimo komunikatu API. Odczyt stanu odpowiada na to pytanie w zakresie RAM demo. Następnie możesz zbadać, czy ponowienie po wyłączeniu awarii tworzy konto. Nie wyciągaj wniosku o trwałej bazie albo aktywacji e-mail, których lab nie ma.

Jeśli odkryjesz brak walidacji powtórzenia, zapisz nowy wątek. Możesz poświęcić mu część pozostałego czasu, jeśli wiąże się z celem, albo utworzyć kolejną kartę sesji. Posiadanie interesującego odkrycia nie wymaga porzucenia pierwotnego celu bez śladu. W podsumowaniu wyjaśnij zmianę zakresu i wynikającą z niej lukę.

7. Prowadź notatkę, którą można wykorzystać po sesji

Przy każdej istotnej próbie zapisuj ID, pytanie, dane i stan, obserwację oraz następny krok. Wystarczy krótki zapis: „E03: 503; poprawne dane; UI sukces; API 503; konto brak; zebrać raport”. Zachowaj jednak dokładne dane w miejscu pozwalającym odtworzyć próbę. Sam skrót „503 źle” nie wystarczy drugiej osobie.

Oddziel obserwację, hipotezę i pytanie. Obserwacja: brak adresu w stanie. Hipoteza: UI błędnie ocenia status. Pytanie: czy kod obsługuje inne błędy podobnie? Hipotezy mogą okazać się fałszywe; nie przenoś ich automatycznie do wyników rzeczywistych raportu.

Zapisuj również wyniki zgodne z wymaganiem. Bez nich odbiorca może pomyśleć, że cała rejestracja jest niewykonalna. Informacja o poprawnym 201 oraz poprawnym odrzuceniu duplikatu zawęża problem do określonego warunku. Niezbadane obszary zapisuj równie jasno: „Offline nie sprawdzono”, „obsługa klawiaturą poza zakresem”.

W Network rejestrowanie musi być aktywne, a filtry nie mogą ukrywać wywołania. Jeśli nie widzisz wpisu, najpierw sprawdź zapis i filtr; dopiero potem wnioskuj o braku wysłania. Mechanizm rejestrowania i szczegóły żądań opisuje Chrome DevTools Network.

8. Zakończ sesję bilansem wiedzy

Po upływie czasu zatrzymaj nowe wątki i uporządkuj wyniki. Zapisz obszary wykonanych prób, znalezione niezgodności, pytania do wyjaśnienia, przeszkody oraz proponowany dalszy zakres. Lista defektów bez informacji o pokryciu nie mówi, czego dowiedziałeś się o produkcie.

Nie oceniaj sesji wyłącznie liczbą błędów. Trzy dobrze udokumentowane wyniki poprawne mogą ograniczyć ważną niepewność. Jeden błąd może ujawnić duży problem. Dziesięć powtórzeń tego samego defektu nie staje się dziesięcioma nowymi odkryciami. W raporcie zachowaj proporcję między problemami i zbadanym zakresem.

Jeśli funkcja blokuje dalsze testowanie, nazwij blokadę. Nie przedstawiaj obszarów za nią jako poprawnych. Jeżeli czas zużyło przygotowanie środowiska, zapisz rzeczywisty czas badania. Kolejna osoba potrzebuje tych informacji, aby ocenić, czy warto przedłużyć sesję, naprawić lab czy wybrać inny obszar.

9. Zadanie i przykładowe rozwiązanie

Przeprowadź własną sesję według karty z sekcji 2. Zapisz trzy próby początkowe, jeden kolejny krok wynikający z obserwacji oraz jedną rzecz świadomie pominiętą. Przygotuj zgłoszenie znalezionej niezgodności według lekcji o raportowaniu i checklisty. Dostępna jest też wersja PDF.

Przykładowy tok rozwiązania: poprawna rejestracja daje punkt odniesienia; duplikat pozwala porównać oczekiwany błąd biznesowy; 503 ujawnia fałszywy sukces. Następnym pytaniem może być „Czy ponowienie po wyłączeniu 503 pozwala rzeczywiście utworzyć konto?”. Użyj stanu bez utworzonego adresu i zanotuj, że była to świadoma kontynuacja, a nie niezależny test po resecie.

Podsumowanie nie powinno brzmieć „formularz przetestowany”. Trafniejszy zapis: „Sprawdzono zwykłą rejestrację, konflikt adresu i awarię 503; odkryto sprzeczność UI/API/stanu przy awarii. Nie oceniono granic hasła, dostępności, wydajności i bezpieczeństwa”. Własne wyniki i czas uzupełnij zgodnie z rzeczywistą sesją, nawet jeśli różnią się od tego wzoru.

Źródła odczytano 2 października 2026 r. Karta, podział czasu i skala punktowa są zaleceniami dydaktycznymi dla tej demonstracji. Potwierdzono jedną próbę 503 w Chromium 151.0.7922.34; nie deklarujemy wykonania całej opisanej sesji. Autor serwisu: Marcin Kozłowski. Research i tekst powstały z pomocą AI; materiał.