Gdy aplikacja działa zgodnie ze scenariuszem, a mimo to użytkownicy znajdują problemy, potrzebne jest testowanie mniej schematyczne. Testy eksploracyjne łączą poznawanie systemu, projektowanie przypadków i ich wykonywanie w tym samym momencie. Wyjaśniam, jak działa ta metoda, kiedy przynosi najlepsze efekty, jak prowadzić sesję oraz gdzie kończy się jej skuteczność.
Najważniejsze informacje o testowaniu eksploracyjnym
- Jednoczesne działanie oznacza, że tester poznaje produkt, wymyśla test i od razu go wykonuje.
- Sesja testowa powinna mieć jasno określony cel, zakres oraz limit czasu, zwykle od 60 do 120 minut.
- Największą wartość metoda daje przy niepełnej dokumentacji, nowych funkcjach i wysokim ryzyku błędów użytkowych.
- Nie zastępuje automatyzacji ani testów scenariuszowych, lecz uzupełnia je o obserwacje i nieoczywiste ścieżki.
- Dobra dokumentacja obejmuje wykonane działania, dane testowe, znalezione problemy i pomysły na dalszą eksplorację.
Na czym polega ta metoda i czym różni się od klasycznych testów
W klasycznym podejściu tester najpierw otrzymuje przypadki testowe, a później realizuje je według ustalonej kolejności. W podejściu eksploracyjnym plan nie znika, ale jest bardziej elastyczny. Tester zaczyna od celu, a kolejne działania dobiera na podstawie obserwacji systemu, własnej wiedzy i wyników poprzednich prób.
Przykład jest prosty. Zamiast wykonać wyłącznie scenariusz logowania poprawnym hasłem, sprawdzam także wielokrotne próby, wklejanie bardzo długiego tekstu, zmianę języka interfejsu, przerwanie połączenia i powrót do formularza po kilku minutach. Każde zachowanie aplikacji podpowiada mi, gdzie skierować uwagę dalej.
Według terminologii ISTQB jest to technika oparta na doświadczeniu, w której uczenie się, projektowanie i wykonywanie testów zachodzą równocześnie. Nie oznacza to przypadkowego klikania. Dobrze przeprowadzona sesja ma hipotezę, priorytet oraz kryterium zakończenia.
| Element | Test scenariuszowy | Podejście eksploracyjne |
|---|---|---|
| Plan | Gotowy przed wykonaniem testu | Rozwija się w trakcie pracy |
| Elastyczność | Ograniczona zakresem przypadku | Wysoka, zależna od obserwacji |
| Powtarzalność | Zwykle łatwa do odtworzenia | Wymaga dobrych notatek |
| Największa wartość | Kontrola znanych wymagań | Odkrywanie nieznanych problemów |
Najczęstszy błąd polega na utożsamianiu tej metody z testowaniem ad hoc. Różnica tkwi w intencji. Test ad hoc często kończy się na pojedynczym pomyśle, natomiast eksploracja powinna prowadzić do świadomego poszerzania wiedzy o produkcie.
Kiedy testowanie eksploracyjne ma największy sens
Najlepiej korzystam z tej techniki wtedy, gdy dokumentacja jest niepełna, funkcja dopiero powstaje albo produkt ma wiele możliwych zachowań zależnych od kontekstu. W takich warunkach przygotowanie kompletnego zestawu przypadków przed pierwszym uruchomieniem byłoby powolne i często pozorne.
Nowa funkcja i krótki termin
Przy świeżo dodanym module tester może szybko zorientować się, co działa, gdzie pojawiają się wyjątki i które pytania trzeba doprecyzować z zespołem. W ciągu jednej sesji da się zebrać materiał do późniejszych przypadków regresyjnych. To szczególnie przydatne w projektach zwinnych, gdzie wymagania dojrzewają razem z rozwiązaniem.
Użyteczność i doświadczenie użytkownika
Automatyczny test potwierdzi, że przycisk prowadzi do właściwego adresu, ale nie oceni dobrze, czy użytkownik rozumie komunikat albo czy proces nie jest niepotrzebnie zagmatwany. Podczas ręcznej eksploracji można obserwować logikę interfejsu, tempo pracy i reakcje na nietypowe zachowania.
Ryzyko i nieprzewidywalne kombinacje
W systemach płatniczych, panelach administracyjnych czy aplikacjach mobilnych problem często wynika z połączenia kilku warunków. Przykładem może być wygasła sesja, zmiana urządzenia i jednoczesne zapisanie formularza. Tego typu kombinacje trudno pokryć wyłącznie listą przewidywalnych przypadków.
Nie traktowałbym jednak tej metody jako uniwersalnego zamiennika. Wymagania prawne, krytyczne obliczenia i procesy finansowe potrzebują także powtarzalnych dowodów zgodności. Eksploracja może wskazać ryzyko, ale nie zawsze wystarczy do formalnego potwierdzenia poprawności.
Jak zaplanować skuteczną sesję krok po kroku
Najlepsze sesje są krótkie i konkretne. Sam zaczynam od zapisania misji w jednym zdaniu, na przykład „sprawdzić, czy nowy proces zwrotu jest zrozumiały i odporny na przerwanie”. Taki cel ogranicza chaos, ale nie odbiera testerowi swobody.
- Wybierz obszar, funkcję albo przepływ użytkownika, który ma największe ryzyko.
- Zapisz kartę sesji z misją, zakresem, wyłączeniami i przewidywanym czasem pracy.
- Przygotuj dane, konta testowe, urządzenia oraz warunki potrzebne do realistycznych prób.
- Eksploruj według hipotez, ale zmieniaj kierunek, gdy zachowanie systemu ujawni nowy trop.
- Notuj dowody, w tym kroki, dane wejściowe, zrzuty ekranu, logi i oczekiwany rezultat.
- Zakończ krótkim omówieniem i zdecyduj, które obserwacje zamienić w defekty lub stałe przypadki regresji.
Praktyczny limit to zwykle 60-120 minut na jedną sesję. Krótszy czas utrudnia wejście w temat, a znacznie dłuższy sprzyja utracie koncentracji. Przy większym obszarze lepiej zaplanować kilka sesji o różnych celach niż jedną całodniową wyprawę bez wyraźnych granic.
Przeczytaj również: Książka o testowaniu - wybierz pozycję, która naprawdę uczy
Pomysły na kierunek eksploracji
Tester nie musi zaczynać z pustą kartką. Pomagają tak zwane wycieczki testowe, czyli świadomie obrane sposoby patrzenia na produkt. Można skupić się na najczęściej używanych funkcjach, danych skrajnych, uprawnieniach, błędach sieci, szybkości reakcji albo podobieństwie interfejsu do oczekiwań użytkownika.
- Wycieczka granic sprawdza wartości minimalne, maksymalne, puste i nietypowo długie.
- Wycieczka użytkownika odtwarza realny cel, np. zakup, rejestrację lub zgłoszenie problemu.
- Wycieczka przerwań obejmuje odświeżenie strony, utratę sieci, zamknięcie aplikacji i powrót do procesu.
- Wycieczka uprawnień porównuje zachowanie kont o różnych rolach.
Ważne, by nie traktować tych list jak sztywnego scenariusza. Ich zadaniem jest uruchomienie myślenia, a nie zamknięcie testera w kolejności kroków.
Jak dokumentować wyniki, żeby eksploracja była mierzalna
Bez notatek nawet trafnie znaleziony błąd może być trudny do odtworzenia. Minimalny zapis powinien obejmować cel sesji, czas, środowisko, wykonane działania, obserwacje i znalezione defekty. Nie trzeba opisywać każdego kliknięcia, ale inny tester powinien zrozumieć, jak powstał problem.
W raporcie rozdzielam fakty od pomysłów. Faktem jest na przykład komunikat błędu po utracie połączenia. Pomysłem może być sprawdzenie, czy podobna sytuacja występuje podczas płatności. Takie rozróżnienie ułatwia priorytetyzację i planowanie kolejnych sesji.
| Co zapisać | Po co |
|---|---|
| Misja i zakres | Pokazuje, czego sesja miała dotyczyć |
| Czas rozpoczęcia i zakończenia | Ułatwia porównanie wysiłku i planowanie |
| Środowisko oraz dane | Pozwala odtworzyć warunki testu |
| Obserwacje i pytania | Wskazuje ryzyka, luki i dalsze kierunki |
| Defekty z dowodami | Przyspiesza analizę i naprawę problemu |
Po zakończeniu sesji przydaje się krótkie debriefing, czyli rozmowa podsumowująca z testerem, deweloperem albo właścicielem produktu. Pytam wtedy, czego się dowiedzieliśmy, jakie ryzyko wzrosło, a jakie zostało zmniejszone. To lepszy miernik wartości niż sama liczba wykonanych kroków.
W praktyce warto śledzić również liczbę unikalnych defektów, obszary pokryte sesjami oraz problemy, które później trafiły do regresji. Nie należy jednak rozliczać testera wyłącznie z liczby błędów. Brak defektu nie zawsze oznacza brak wartości, bo sesja może ujawnić niejasne wymaganie albo ryzykowną lukę w projekcie.
Najczęstsze błędy i sposoby ich uniknięcia
Pierwszym problemem jest brak celu. Hasło „sprawdź aplikację” jest zbyt szerokie, dlatego tester skacze między ekranami i po godzinie nie wiadomo, co faktycznie zostało zbadane. Lepsza jest misja obejmująca konkretny proces, ryzyko lub grupę użytkowników.
Drugim błędem jest całkowity brak dokumentacji. Eksploracja nie wymaga tworzenia wielostronicowych przypadków przed testem, ale wymaga zapisania śladów rozumowania i dowodów problemu. Bez tego zespół nie wie, czy defekt jest nowy, powtarzalny i jak go zweryfikować po poprawce.
Trzecia pułapka to testowanie wyłącznie według własnych przyzwyczajeń. Doświadczenie pomaga, lecz może też zawężać perspektywę. Dlatego rotuję dane, urządzenia, role użytkowników i punkty widzenia, a przy procesach biznesowych proszę o udział osoby, która zna codzienną pracę odbiorców.
Niepokoi mnie także oczekiwanie, że jedna sesja zastąpi cały proces jakościowy. Ta metoda nie gwarantuje kompletności, nie daje pełnej powtarzalności i nie wykryje problemów, których tester nie przewidzi. Jej siła leży gdzie indziej, w szybkim odkrywaniu nieznanych ryzyk i zadawaniu lepszych pytań.
Jak połączyć eksplorację z automatyzacją i regresją
Najrozsądniejszy model łączy kilka technik. Automatyzacja pilnuje stabilnych, często powtarzanych kontroli, testy scenariuszowe sprawdzają wymagania, a ręczna eksploracja szuka luk poza znanym zakresem. W takim układzie każda metoda robi to, w czym jest naprawdę mocna.
Gdy podczas sesji znajdę błąd, najpierw oceniam jego charakter. Jeśli dotyczy stałej reguły, warto dodać automatyczny test regresyjny. Jeśli wynika z niejasnego interfejsu albo nietypowej kombinacji zachowań, lepsze może być doprecyzowanie kryteriów akceptacji i zaplanowanie kolejnej sesji.
Dobrym rozwiązaniem jest wykonywanie eksploracji po zakończeniu podstawowych testów automatycznych, ale przed wydaniem funkcji. Tester nie traci wtedy czasu na problemy wykrywane już przez pipeline, a jednocześnie może skupić się na zachowaniu produktu w realnym użyciu.
Co zapamiętać przed pierwszą sesją
Najprostszy start nie wymaga specjalnego narzędzia. Wystarczą karta sesji, środowisko testowe, możliwość rejestrowania ekranu i osoba, która potrafi krytycznie obserwować produkt. Najważniejsze pytanie nie brzmi „ile przypadków wykonaliśmy?”, lecz „czego nowego dowiedzieliśmy się o ryzyku?”.
Jeżeli sesja ma jasny cel, ograniczony czas i rzetelne notatki, testowanie eksploracyjne staje się pełnoprawną techniką pracy, a nie improwizacją. Właśnie wtedy najlepiej uzupełnia automatyzację i scenariusze, pomagając znaleźć problemy, których wcześniej nikt nie umiał jeszcze opisać.
