Dotychczas poznaliśmy techniki czarnoskrzynkowe, bazujące na specyfikacji, oraz białoskrzynkowe, zaglądające do kodu.

Istnieje jednak trzecia, równie ważna kategoria technik projektowania testów – techniki oparte na doświadczeniu (experience-based techniques).

Jak sama nazwa wskazuje, opierają się one na wiedzy, umiejętnościach i intuicji testera oraz innych interesariuszy.

Te techniki wykorzystują ludzką zdolność do przewidywania problemów, eksploracji systemu i systematycznego sprawdzania znanych obszarów ryzyka.

Są szczególnie cenne, gdy dokumentacja jest niekompletna, nieaktualna lub po prostu nie istnieje, a także gdy mamy ograniczony czas na testy.

Sylabus ISTQB Foundation Level v4.0 w sekcji 4.4 (FL-4.4.1 K2, FL-4.4.2 K2, FL-4.4.3 K2) przedstawia trzy popularne techniki oparte na doświadczeniu:

1. Zgadywanie błędów (Error Guessing)
2. Testowanie eksploracyjne (Exploratory Testing)
3. Testowanie w oparciu o listę kontrolną (Checklist-Based Testing)

W tej lekcji przyjrzymy się bliżej każdej z tych technik, zrozumiemy ich założenia, sposób stosowania oraz sytuacje, w których okazują się najbardziej przydatne.

1. Zgadywanie Błędów (Error Guessing)

Cel: Przewidywanie i celowe wyszukiwanie błędów, defektów i potencjalnych awarii na podstawie wiedzy i doświadczenia testera.

Założenie: Doświadczeni testerzy, programiści i inni specjaliści posiadają wiedzę o typowych problemach, które pojawiają się w oprogramowaniu.

Mogą wykorzystać tę wiedzę do "zgadnięcia", gdzie najprawdopodobniej kryją się błędy i zaprojektowania testów, które je ujawnią.

Na czym bazuje zgadywanie błędów?

• Wiedza o aplikacji: Jak system działał w przeszłości, gdzie wcześniej znajdowano błędy.
• Wiedza o typowych błędach programistycznych: Jakie pomyłki często popełniają programiści (np. obsługa wartości null, błędy off-by-one w pętlach, niepoprawna obsługa typów danych, problemy z zarządzaniem pamięcią).
• Wiedza o podobnych systemach: Jakie awarie występowały w innych, podobnych aplikacjach lub modułach.
• Wiedza o środowisku: Jakie problemy mogą wynikać z interakcji z systemem operacyjnym, przeglądarką, bazą danych czy innymi systemami.
• Wiedza o użytkownikach: Jakie nietypowe działania mogą podejmować użytkownicy.

Jak stosować?

1. Burza mózgów / Analiza: Zastanów się (indywidualnie lub w zespole), jakie błędy mogą wystąpić w testowanym obszarze. Pomyśl o danych wejściowych, wyjściowych, logice, obliczeniach, interfejsach, zarządzaniu danymi.
2. Stworzenie listy potencjalnych błędów: Zanotuj zidentyfikowane potencjalne problemy. Może to być nieformalna lista lub bardziej ustrukturyzowana, jak w przypadku "ataków usterek" (fault attacks).
3. Projektowanie testów: Dla każdego potencjalnego błędu z listy zaprojektuj jeden lub więcej przypadków testowych, które mają na celu sprowokowanie tego błędu lub wykazanie jego braku.

Przykład: Testowanie formularza rejestracji.

• Potencjalne błędy (zgadywanie):
  • Wprowadzenie bardzo długiego imienia/nazwiska.
  • Użycie znaków specjalnych w polach tekstowych.
  • Wprowadzenie spacji na początku/końcu adresu e-mail.
  • Próba rejestracji z już istniejącym adresem e-mail.
  • Wprowadzenie hasła niespełniającego wymagań złożoności.
  • Niezaznaczenie obowiązkowej zgody.
  • Dwukrotne kliknięcie przycisku "Zarejestruj".
  • Wprowadzenie daty urodzenia z przyszłości.
• Przykładowe testy: Zaprojektuj testy dla każdego z powyższych scenariuszy.

Ataki usterek (Fault Attacks): Jest to bardziej metodyczne podejście do zgadywania błędów.

Polega na stworzeniu (lub wykorzystaniu istniejącej) listy typowych błędów programistycznych lub wzorców awarii (np. lista OWASP Top 10 dla bezpieczeństwa webowego) i systematycznym projektowaniu testów atakujących te potencjalne słabości.

Wartość i ograniczenia:

• Wartość: Może być bardzo skuteczne w szybkim znajdowaniu defektów, szczególnie tych typowych lub pomijanych przez bardziej formalne techniki. Dobrze uzupełnia inne podejścia.
• Ograniczenia: Skuteczność silnie zależy od doświadczenia i umiejętności testera. Jest to technika mało systematyczna i trudna do zmierzenia pod kątem pokrycia. Istnieje ryzyko pominięcia nietypowych błędów, jeśli tester nie ma odpowiedniej wiedzy.

2. Testowanie Eksploracyjne (Exploratory Testing)

Cel: Równoczesne uczenie się systemu, projektowanie testów, wykonywanie testów i ocena wyników w dynamiczny, interaktywny sposób.

Założenie: Testowanie nie jest tylko wykonywaniem z góry zdefiniowanych kroków, ale procesem ciągłego odkrywania i badania.

Tester aktywnie eksploruje aplikację, a zdobyta wiedza natychmiast wpływa na kolejne podejmowane działania testowe.

Kluczowe cechy:

• Równoczesność: Projektowanie, wykonywanie i uczenie się dzieją się niemal jednocześnie.
• Interaktywność: Tester na bieżąco reaguje na zachowanie systemu i dostosowuje swoje działania.
• Brak predefiniowanych skryptów: Testy nie są szczegółowo opisane krok po kroku przed rozpoczęciem sesji.
• Skupienie na celu (misji): Zamiast sztywnych kroków, tester może mieć określony cel do zbadania (np. "Sprawdź funkcjonalność koszyka zakupowego") lub obszar do eksploracji.
• Dokumentacja w trakcie lub po: Wyniki, obserwacje i znalezione problemy są dokumentowane podczas sesji eksploracyjnej lub tuż po niej.

Jak stosować?

Testowanie eksploracyjne nie oznacza chaotycznego klikania.

Często stosuje się ustrukturyzowane podejścia, takie jak testowanie oparte na sesjach (Session-Based Test Management - SBTM):

1. Zdefiniuj misję (cel sesji): Określ, co ma być głównym celem danej sesji testowej (np. "Przetestować proces resetowania hasła", "Zbadać obsługę nieprawidłowych danych w formularzu X").
2. Określ czas trwania sesji (Timeboxing): Ustal limit czasowy dla sesji (np. 60-120 minut), aby zapewnić skupienie.
3. Wykonaj sesję eksploracyjną: Tester eksploruje aplikację, mając na uwadze misję. Notuje swoje działania, obserwacje, pomysły na dalsze testy i znalezione problemy (np. w formie notatek, map myśli, nagrań ekranu).
4. Raportowanie i podsumowanie (Debriefing): Po zakończeniu sesji tester podsumowuje wyniki, dokumentuje znalezione defekty i omawia je z zespołem (np. z innym testerem, menedżerem testów).

Karty eksploracyjne (Test Charters): Mogą służyć jako przewodnik dla sesji, sugerując, co testować, jakimi metodami i na co zwracać uwagę, ale bez narzucania sztywnych kroków.

Wartość i ograniczenia:

• Wartość: Bardzo efektywne w znajdowaniu nieoczekiwanych błędów i problemów z użytecznością. Pozwala szybko poznać system i jego słabe punkty. Angażuje testera i wykorzystuje jego kreatywność. Świetne przy ograniczonej dokumentacji lub czasie.
• Ograniczenia: Trudniejsze do zarządzania i raportowania niż testy skryptowe. Powtarzalność testów może być problematyczna. Skuteczność mocno zależy od umiejętności i doświadczenia testera. Wymaga dyscypliny w notowaniu i raportowaniu.

3. Testowanie w Oparciu o Listę Kontrolną (Checklist-Based Testing)

Cel: Systematyczne weryfikowanie określonych elementów, warunków lub cech za pomocą przygotowanej listy kontrolnej (checklisty).

Założenie: Doświadczenie testerów, programistów lub analityków pozwala stworzyć listę ważnych aspektów do sprawdzenia. Lista ta służy jako przewodnik podczas testowania, zapewniając, że nic istotnego nie zostanie pominięte.

Jak stosować?

1. Stwórz lub pozyskaj listę kontrolną: Lista może być stworzona na podstawie:
   • Wymagań funkcjonalnych lub niefunkcjonalnych.
   • Doświadczenia z poprzednich projektów lub podobnych systemów.
   • Standardów jakości, norm branżowych lub wytycznych (np. dotyczących dostępności WCAG).
   • Analizy ryzyka (najważniejsze obszary do sprawdzenia).
   Lista powinna zawierać konkretne punkty do zweryfikowania (np. "Czy pole e-mail akceptuje format x@y.z?", "Czy komunikat błędu jest zrozumiały?", "Czy przyciski mają odpowiedni kontrast?").
2. Wykonaj testy zgodnie z listą: Przejdź przez kolejne punkty listy kontrolnej, wykonując odpowiednie testy i zaznaczając status każdego punktu (np. Zaliczone, Niezaliczone, Nie dotyczy).
3. Zanotuj wyniki i defekty: Udokumentuj wyniki testów dla każdego punktu i zgłoś znalezione defekty.

Przykład: Fragment listy kontrolnej dla strony logowania.

• [ ] Czy obecne są pola Login i Hasło?
• [ ] Czy obecny jest przycisk "Zaloguj"?
• [ ] Czy działa link "Zapomniałem hasła"?
• [ ] Czy logowanie z poprawnymi danymi przenosi do panelu użytkownika?
• [ ] Czy logowanie z niepoprawnym hasłem wyświetla błąd?
• [ ] Czy logowanie z nieistniejącym loginem wyświetla błąd?
• [ ] Czy pole hasła maskuje wpisywane znaki?
• [ ] Czy komunikaty błędów są jasne i nie ujawniają zbyt wiele informacji?

Wartość i ograniczenia:

• Wartość: Zapewnia systematyczne pokrycie zdefiniowanych aspektów. Łatwe do stosowania i zarządzania. Dobre jako uzupełnienie innych technik lub gdy wymagane jest szybkie sprawdzenie kluczowych funkcjonalności.
• Ograniczenia: Skuteczność zależy od jakości i kompletności listy kontrolnej. Sama lista może stać się nieaktualna. Testowanie ogranicza się tylko do punktów na liście, co może prowadzić do pominięcia innych problemów. Nie zachęca do głębszej eksploracji.

Podsumowanie

Techniki oparte na doświadczeniu są nieocenionym narzędziem w pracy testera.

Zgadywanie błędów pozwala wykorzystać intuicję i wiedzę o typowych problemach.

Testowanie eksploracyjne umożliwia dynamiczne odkrywanie systemu i znajdowanie nieoczywistych defektów.

Testowanie w oparciu o listę kontrolną zapewnia systematyczne sprawdzenie kluczowych aspektów.

Najczęściej techniki te stosuje się jako uzupełnienie technik czarno- i białoskrzynkowych, aby zapewnić jak najszersze i najefektywniejsze pokrycie testowe.