Exploratory Testing — jak robić to profesjonalnie

Exploratory testing to nie losowe klikanie. Poznaj chartery testowe, session-based testing, jak dokumentować odkrycia i kiedy ten rodzaj testów daje największą wartość.

#exploratory-testing #testowanie #qa #projektowanie-testow

“Po prostu poklikaj i zobaczymy co się posypie.”

Jeśli tak opisuje się exploratory testing w Twoim zespole, jest robione źle — a dokładniej, nie jest robione wcale. To, co się robi, to testowanie ad hoc: nieustrukturyzowane, nieudokumentowane, niemożliwe do powtórzenia.

Exploratory testing wykonywane profesjonalnie to jedna z najbardziej zaawansowanych umiejętności w inżynierii jakości oprogramowania. To technika, która znajduje bugi, których Twoje testy oskryptowane nigdy nie znajdą, bo testy oskryptowane mogą tylko weryfikować to, co przewidziałeś. Exploratory testing znajduje to, czego nie przewidziałeś.

Czym naprawdę jest exploratory testing

Elisabeth Hendrickson, jedna z pionierów profesjonalnego exploratory testingu, definiuje go jako:

Jednoczesne uczenie się, projektowanie testów i wykonywanie.

Każde z tych trzech słów ma znaczenie:

  • Uczenie się — budujesz swoje rozumienie systemu w trakcie testowania. Nie testujesz z kompletnym modelem mentalnym; budujesz go podczas sesji.
  • Projektowanie — w czasie rzeczywistym decydujesz, co testować dalej, na podstawie tego, co właśnie znalazłeś. Projektowanie i wykonywanie testów są przeplatane.
  • Wykonywanie — faktycznie uruchamiasz testy, nie tylko o nich myślisz.

Porównaj to z testowaniem oskryptowanym: projektowanie odbywa się najpierw (przypadki testowe), wykonanie — później (uruchomienie przypadków). Wiedza, którą masz podczas projektowania, jest niepełna — co oznacza, że przypadki zawsze będą miały luki.

Exploratory testing wypełnia te luki.

Dlaczego testy oskryptowane nie wystarczą

Testy oskryptowane (automatyczne lub manualne) mogą tylko weryfikować zachowanie, które przewidziałeś podczas ich pisania. Doskonale nadają się do wyłapywania regresji i weryfikowania znanych wymagań.

Ale systemy oprogramowania psują się w nieoczekiwany sposób. Użytkownik z niezwykłymi danymi, przypadek brzegowy w formatowaniu danych, kombinacja funkcji, których nikt nie zaprojektował razem, wyścig, który pojawia się tylko pod określonym obciążeniem — to bugi, które trafiają na produkcję mimo zielonej suity testów.

Exploratory testing jest specyficznie zaprojektowany dla tych trybów awarii. Tester podchodzi do systemu jak inteligentny przeciwnik: “Jak mogę sprawić, żeby to się posypało w sposób, którego programista nie przewidział?”

Chartery testowe — struktura bez skryptów

Najważniejsza technika w profesjonalnym exploratory testingu to charter testowy (test charter). Charter zapewnia kierunek i zakres sesji bez przepisywania dokładnych kroków.

Standardowy format:

Eksploruj [obszar docelowy] używając [zasobów/narzędzi/technik] żeby odkryć [informacje/ryzyka]

Przykłady

"Eksploruj przepływ checkout jako gość na Safari mobilnym,
 żeby odkryć punkty tarcia i stany błędów"

"Eksploruj stronę ustawień użytkownika przy symulowanej wolnej sieci (3G),
 żeby odkryć problemy z ładowaniem, timeoutem i częściowym zapisem"

"Eksploruj funkcję uploadu pliku CSV z niezwykłymi formatami plików,
 kodowaniami i treścią brzegową, żeby odkryć luki w walidacji i
 problemy bezpieczeństwa"

"Eksploruj zachowanie rate limiting API przy szybkich, powtarzających się
 żądaniach, żeby odkryć obsługę błędów, czas odtworzenia i jakość komunikatów"

Zwróć uwagę, co charter robi, a czego nie robi:

  • ✅ Definiuje obszar skupienia
  • ✅ Określa podejście lub zasób
  • ✅ Stwierdza, jakich informacji szukamy
  • ❌ NIE mówi, jakie kroki podjąć
  • ❌ NIE określa, jaki jest oczekiwany wynik

Tester decyduje o krokach w czasie rzeczywistym na podstawie obserwacji. O to chodzi.

Session-Based Testing (SBTM)

Session-Based Test Management (SBTM) to framework, który nadaje exploratory testingowi mierzalność i reportowalność. Został opracowany przez Jonathana i Jamesa Bacha, żeby odpowiedzieć na najczęstszy zarzut wobec exploratory testingu: “Nie możesz zarządzać tym, czego nie możesz zmierzyć.”

Struktura sesji

Każda sesja SBTM ma cztery elementy:

  1. Charter — kierunek sesji (patrz wyżej)
  2. Timebox — stały czas trwania, zazwyczaj 60–90 minut, bez przerywania
  3. Notatki — bieżący zapis tego, co robiłeś i co znalazłeś
  4. Debrief — krótka rozmowa z interesariuszem o wynikach

Timebox jest kluczowy. Sesje bez limitów czasowych mają tendencję do dryfowania. 90-minutowa skupiona sesja z jasnym charterem jest warta więcej niż cztery godziny niekierowanego klikania.

Arkusz sesji SBTM

Szablon do bezpośredniego użycia:

=========================================
ARKUSZ SESJI TESTOWEJ
=========================================
Charter:    [Eksploruj X używając Y żeby odkryć Z]
Tester:     [Imię i nazwisko]
Data:       [RRRR-MM-DD]
Godzina start.: [GG:MM]
Czas trwania: [minuty]
Build/wersja: [np. v2.3.1-staging]

-----------------------------------------
NOTATKI TESTOWE (narracja)
-----------------------------------------
[Bieżące notatki o tym, co próbowałeś i co zaobserwowałeś]

GG:MM - Przeszedłem do checkout jako gość
GG:MM - Wpisałem dane karty z datą ważności w przeszłości → błąd wyświetlony ✓
GG:MM - Pozostawiłem pole numeru karty puste, wyslałem → brak błędu walidacji ← BUG?
GG:MM - Odświeżyłem w trakcie checkout → koszyk zachowany ✓
GG:MM - Próbowałem checkout z aktywnym VPN → dziwny redirect na /en-us/

-----------------------------------------
ZNALEZIONE PROBLEMY
-----------------------------------------
1. Puste pole numeru karty pozwala na wysłanie formularza
   Kroki: Checkout gość → Pomiń numer karty → Kliknij "Zapłać"
   Oczekiwane: Błąd walidacji dla pustego wymaganego pola
   Faktyczne: Formularz wysyłany, wyświetla generyczny błąd API
   Priorytet: Wysoki
   Zrzut ekranu: [link]

2. Aktywny VPN powoduje redirect na /en-us/
   Kroki: Włącz VPN (serwer USA) → Próba checkout
   Oczekiwane: Normalny przepływ checkout
   Faktyczne: Redirect na angielską wersję w trakcie procesu, koszyk utracony
   Priorytet: Średni

-----------------------------------------
PYTANIA / DZIAŁANIA DALSZE
-----------------------------------------
- Czy jest walidacja numeru karty po stronie serwera? (zapytaj programistę)
- Czy redirect przez VPN jest zamierzony? (zapytaj PO)
- Co się dzieje z uwierzytelnianiem 3DS na mobilnym?

-----------------------------------------
POMYSŁY NA KOLEJNĄ SESJĘ
-----------------------------------------
- Eksploruj ten sam przepływ checkout zalogowanego użytkownika
- Eksploruj stany błędów płatności z różnymi typami kart
- Eksploruj specyficznie Safari mobilne (inne zachowanie klawiatury)

-----------------------------------------
METRYKI
-----------------------------------------
Czas sesji: 75 minut
Pokrycie chartera: ~70% (zabrakło czasu na testy mobilne)
Znalezione bugi: 2
Zadane pytania: 3
=========================================

Metryki z SBTM

Session-based testing produkuje mierzalne wyniki:

  • Współczynnik bugów na sesję — ile problemów na sesję? Przydatne do porównywania obszarów produktu.
  • Pokrycie chartera — jaki procent chartera udało się zrealizować w timeboxie?
  • Liczba sesji na funkcję — śledzi inwestycję w jakość testowania.
  • Obszary możliwości — powtarzające się typy pytań wskazują luki w projekcie.

W ten sposób exploratory testing staje się widoczny dla managementu: nie przez konwersję na przypadki testowe, ale przez śledzenie wyników sesji.

Jak robić dobre notatki podczas sesji

Robienie notatek to umiejętność, która wymaga praktyki. Złe notatki sprawiają, że sesje są niemożliwe do powtórzenia; dobre sprawiają, że bugi są łatwe do odtworzenia.

Praktyczne wskazówki:

  • Dodawaj znaczniki czasu do notatek — podziękujesz sobie przy próbie odtworzenia buga
  • Notuj to, czego oczekiwałeś, nie tylko to, co się stało
  • Zrób zrzut ekranu lub nagraj wideo natychmiast po zauważeniu czegoś podejrzanego
  • Nie przerywaj sesji, żeby głębiej zbadać odkrycie — zanotuj je i kontynuuj
  • Rozróżniaj: potwierdzony bug / obserwacja / pytanie / pomysł

Narzędzia: Zwykły plik .md, Notion, OneNote, Confluence — cokolwiek nie przerywa flow. Narzędzie nie ma znaczenia; dyscyplina pisania — owszem.

Kiedy exploratory testing daje największą wartość

SytuacjaDlaczego exploratory testing pomaga
Nowa funkcja właśnie wydana na stagingPierwsza prawdziwa interakcja z funkcją jako całością; testy oskryptowane testowały tylko części
Po dużym refaktorzeEksploracja regresji — znajdź emergentne interakcje między starym i nowym kodem
Obszary wysokiego ryzyka z planowania sprintuZainwestuj czas sesji proporcjonalnie do ryzyka
Tuż przed dużym wydaniemOstateczne sprawdzenie krytycznych ścieżek; świeże spojrzenie
Po incydencie produkcyjnymZnajdź powiązane problemy zanim użytkownicy je znajdą
Wnioski z retrospektywy”Użytkownicy zgłaszali, że X jest mylące” → dedykowana sesja eksploracyjna

Częste błędy

Brak chartera → brak kierunku → brak wartości. Rozpoczęcie sesji z “eksploruj stronę checkout” jest prawie tak złe jak brak chartera. Bądź konkretny w kwestii tego, jakich informacji szukasz.

Brak timeboxu → sesje się przeciągają albo są pomijane. Jeśli exploratory testing jest zaplanowane jako “kiedy będzie czas,” nigdy nie nastąpi. Zarezerwuj czas w kalendarzu sprintu.

Brak notatek → odkrycia znikają. Bez notatek bugi znalezione podczas eksploracji są zgłaszane nieformalnie i często zapominane. Wszystko musi być zapisane.

Brak debriefingu → odkrycia nie docierają do zespołu. Arkusz sesji jest przydatny tylko wtedy, gdy ktoś go przeczyta. Dziesięciominutowy debrief z programistą lub PO po każdej sesji zamyka pętlę.

Traktowanie go jako “wolnego czasu.” Exploratory testing to ustrukturyzowana, profesjonalna praca, a nie przerwa od pisania przypadków testowych. Zacharteruj go, umieść w timeboxie, udokumentuj.

Zasada 60 minut

Jeśli przez 60 minut nic ciekawego nie znalazłeś, prawdziwe są jedna z dwóch rzeczy: albo Twój charter jest zbyt mglisty, albo obszar jest bardziej stabilny niż oczekiwano. W każdym przypadku — zatrzymaj się, zrób debrief i popraw charter na następną sesję.

Nie kontynuuj nieproduktywnej sesji w nadziei, że coś się pojawi. Timebox, debrief, adaptacja.

Podsumowanie

Exploratory testing to dyscyplina — nie wypadek, nie fallback, nie “losowe klikanie.” Wykonywany profesjonalnie, z charterami, timeboxami i dokumentacją, jest najwyżej rentowną aktywnością testową dostępną inżynierowi QA.

Znajduje bugi, których automatyczne testy nigdy nie znajdą, bo wnosi ludzką inteligencję, doświadczenie i ciekawość do systemu — nie z góry określony skrypt.

Zacznij w tym sprincie: Napisz jeden charter dla najbardziej ryzykownej funkcji aktualnie w testach. Przeprowadź jedną 60-minutową sesję. Opisz wyniki. Podziel się nimi na następnym standupie. Tak to się zaczyna.

To jest szósty i ostatni artykuł z serii Seria 1 — QA Ogólne. Seria 2 — ISTQB Foundation Level — zaczyna się za tydzień.