Techniki projektowania testów oparte na doświadczeniu
Testowanie oparte na doświadczeniu to nie zgadywanie — to ustrukturyzowana intuicja. Poznaj exploratory testing, error guessing i testowanie oparte na checklistach.
Seria ISTQB Foundation Level — część 8 z 10 Ta seria omawia wszystkie kluczowe tematy sylabusa ISTQB CTFL. Zacznij od części 1 lub przejdź bezpośrednio do interesującego cię działu.
1. Trzeci wymiar projektowania testów
Kiedy większość testerów myśli o projektowaniu testów, myśli o specyfikacjach. Techniki czarnoskrzynkowe, takie jak podział na klasy równoważności czy analiza wartości granicznych, wywodzą testy z wymagań. Techniki białoskrzynkowe, takie jak pokrycie instrukcji, wywodzą testy ze struktury kodu. Obie są systematyczne i powtarzalne — ale żadna z nich nie oddaje tego, co doświadczony tester wie z intuicji.
Tę lukę wypełniają właśnie techniki oparte na doświadczeniu.
| Wymiar | Sterowany przez | Przykładowa technika |
|---|---|---|
| Czarnoskrzynkowy | Wymagania, specyfikacje | Podział na klasy równoważności, tablice decyzyjne |
| Białoskrzynkowy | Struktura kodu, przepływ sterowania | Pokrycie instrukcji, pokrycie gałęzi |
| Oparty na doświadczeniu | Wiedza testera, intuicja, historia | Testowanie eksploracyjne, zgadywanie błędów, listy kontrolne |
Wszystkie trzy wymiary wzajemnie się uzupełniają. Dojrzałe podejście do testowania używa ich wszystkich. Techniki oparte na doświadczeniu wnoszą największą wartość tam, gdzie wymagania są niekompletne, kod jest złożony lub zespół napotkał podobne błędy w przeszłości.
2. Testowanie eksploracyjne (ISTQB 4.4.3)
Czym jest
Definicja ISTQB: „Technika testowania oparta na doświadczeniu, w której tester jednocześnie poznaje testowany obiekt, projektuje, wykonuje i ocenia testy.”
Ta jednoczesność jest kluczową różnicą w porównaniu ze skryptowanym testowaniem. Nie piszesz przypadku testowego, a potem wykonujesz go później. Zamiast tego nauka, projektowanie i wykonanie odbywają się w jednym ciągłym akcie. Podążasz za tym, co znajdziesz. Każda obserwacja kształtuje kolejny test.
To nie jest testowanie ad-hoc. Testowanie ad-hoc pozbawione jest struktury i daje wyniki, które trudno odtworzyć lub zaraportować. Testowanie eksploracyjne jest zdyscyplinowane.
Testowanie eksploracyjne oparte na sesjach
Najpowszechniej stosowaną strukturą testowania eksploracyjnego jest model sesji:
- Misja (Charter) — ukierunkowane stwierdzenie misji definiujące co eksplorować i opcjonalnie czego szukać. Przykład: „Eksploruj edycję profilu użytkownika przy równoległych sesjach, szukając problemów z integralnością danych.”
- Timebox — stały czas trwania, zazwyczaj 60–90 minut. To utrzymuje sesje skupione i zapobiega niekończącemu się błądzeniu.
- Podsumowanie (Debrief) — krótki przegląd po sesji: co objęto, co znaleziono, otwarte pytania i obszary wymagające dalszego badania.
Sesje produkują notatki, nie formalne przypadki testowe. Wynikiem jest raport z sesji: czas spędzony na testowaniu, badaniu i konfiguracji, znalezione defekty oraz pokrycie osiągnięte względem misji.
Kiedy testowanie eksploracyjne wnosi największą wartość
- Nowe lub słabo udokumentowane funkcje — gdy specyfikacje są skąpe, testowanie eksploracyjne ujawnia problemy, które skryptowane testy by pominęły.
- Obszary wysokiego ryzyka — przed głównym wydaniem skupione sesje na najbardziej ryzykownych modułach tworzą siatkę bezpieczeństwa.
- Po incydencie lub defekcie produkcyjnym — użyj błędu jako misji do eksploracji otaczającego obszaru.
- Walidacja luk w automatyzacji — testowanie eksploracyjne wychwytuje to, czego nie pokrywa twój zautomatyzowany pakiet.
Uwaga egzaminacyjna ISTQB
Częsta pułapka: ISTQB klasyfikuje testowanie eksploracyjne jako technikę opartą na doświadczeniu, a nie technikę czarnoskrzynkową — nawet jeśli nie wymaga dostępu do kodu źródłowego. Nie daj się temu zmylić na egzaminie.
3. Zgadywanie błędów (ISTQB 4.4.1)
Czym jest
Zgadywanie błędów oznacza przewidywanie, gdzie prawdopodobnie istnieją defekty, na podstawie:
- Osobistego doświadczenia testera z przeszłymi defektami
- Znanych nawyków programistów i typowych błędów implementacyjnych
- Historycznych danych o błędach z projektu lub podobnych projektów
- Typowych trybów awarii dla używanego stosu technologicznego
W przeciwieństwie do testowania eksploracyjnego, zgadywanie błędów zaczyna się od hipotezy: „Myślę, że ta funkcja prawdopodobnie zawodzi, gdy dane wejściowe są null.” Projektujesz testy, aby potwierdzić lub obalić tę hipotezę.
Bogate źródła dla zgadywania błędów
| Źródło | Przykłady |
|---|---|
| Przypadki graniczne | pusty ciąg, null, 0, liczby ujemne, max int, znaki specjalne (<, ', \0) |
| Naruszenia granic | jeden poniżej/powyżej udokumentowanych limitów, dokładne wartości graniczne |
| Punkty integracji | niezgodność wersji API, obsługa timeoutów, nieprawidłowo sformułowane odpowiedzi |
| Współbieżność | równoczesne aktualizacje tego samego rekordu, wyścigi, zakleszczenia |
| Przejścia stanów | operacje wykonywane w nieoczekiwanej kolejności, ponowne wysłanie ukończonego formularza |
| Bezpieczeństwo | SQL injection, XSS, path traversal, manipulacja JWT |
| Historyczne błędy | defekty zalogowane w twoim systemie śledzenia dla tego lub podobnych systemów |
Atak na błędy (Fault Attack): ustrukturyzowane zgadywanie błędów
Doraźne zgadywanie błędów jest przydatne. Atak na błędy czyni je systematycznym. Przed testowaniem komponentu utwórz pisemną listę potencjalnych usterek, a następnie zaprojektuj konkretne testy atakujące każdą z nich.
Przykład — atak na błędy dla formularza logowania:
| Hipoteza o usterce | Test |
|---|---|
| Pusta nazwa użytkownika jest akceptowana | Wyślij z username = "" |
| Pole hasła wyświetla tekst jawny w DOM | Sprawdź element po wpisaniu hasła |
| Brak blokady konta po nieudanych próbach | Wykonaj 20 szybkich nieudanych logowań |
| SQL injection w nazwie użytkownika | Wpisz ' OR '1'='1 jako nazwę użytkownika |
| Token sesji nie jest unieważniany przy wylogowaniu | Przechwyć token, wyloguj się, odtwórz token |
| „Zapamiętaj mnie” przechowuje hasło w jawnym ciasteczku | Sprawdź ciasteczko po zaznaczeniu „Zapamiętaj mnie” |
| Równoległe logowanie tworzy zduplikowane sesje | Zaloguj się z dwóch przeglądarek jednocześnie |
:::tip[Od zgadywania błędów do ataku na błędy] Zgadywanie błędów staje się znacznie potężniejsze, gdy zostanie sformalizowane w listę ataku na błędy. Zapisanie hipotez przed testowaniem zmusza do precyzji w założeniach, tworzy lekki rejestr testów i ułatwia dzielenie się wiedzą z członkami zespołu. :::
4. Testowanie oparte na listach kontrolnych (ISTQB 4.4.2)
Czym jest
Testowanie oparte na listach kontrolnych oznacza wykonywanie testów względem wstępnie zdefiniowanej listy pozycji do sprawdzenia. Każda pozycja reprezentuje warunek, zachowanie lub atrybut jakości do zweryfikowania.
W przeciwieństwie do przypadków testowych, pozycje na listach kontrolnych są celowo zwięzłe. Przypominają testerowi co sprawdzić, bez skryptowania jak to zrobić. To pozostawia miejsce na stosowanie przez doświadczonych testerów własnego osądu.
Typy list kontrolnych
| Typ | Co obejmuje |
|---|---|
| Lista funkcjonalna | Kluczowe zachowania widoczne dla użytkownika dla funkcji lub modułu |
| Lista przekrojowa | Zagadnienia dotyczące każdej funkcji: komunikaty o błędach, stany ładowania, stany puste, responsywność mobilna, dostępność |
| Lista regresyjna | Najważniejsze biznesowo przepływy do weryfikacji po każdej zmianie |
| Lista wydania | Bramy przed wydaniem: testy smoke, benchmarki wydajności, skany bezpieczeństwa, zaktualizowana dokumentacja |
Zalety
- Niski narzut — pisanie i wykonywanie listy kontrolnej jest szybsze niż utrzymywanie pełnych skryptów testowych.
- Możliwość udostępnienia — listę przekrojową można dać programistom do samodzielnej weryfikacji przed przeglądem kodu.
- Dobra do zagadnień niefunkcjonalnych — sprawdzenia dostępności, wydajności i bezpieczeństwa naturalnie przekładają się na listy kontrolne.
- Zachęca do spójności — każdy tester pokrywa ten sam obszar.
Wady i ryzyka
- Mechaniczne odhaczanie — testerzy mogą odhaczać pozycje bez rzeczywistej ich weryfikacji.
- Starzenie się — lista kontrolna napisana dla v1 może pomijać ważne nowe zachowania w v3.
- Iluzja pokrycia — krótka lista kontrolna może dawać fałszywe poczucie bezpieczeństwa.
Najlepsza praktyka
Przeglądaj i aktualizuj listy kontrolne po każdym poważnym incydencie lub defekcie produkcyjnym. Jeśli błąd uciekł testowaniu, dodaj pozycję na liście kontrolnej, aby go wychwycić następnym razem.
5. Porównanie: kiedy używać każdej techniki
| Technika | Najlepsza do | Kluczowe ryzyko |
|---|---|---|
| Testowanie eksploracyjne | Nowe funkcje, badanie oparte na ryzyku, obszary ze słabą specyfikacją | Sesje zbyt mało skupione; notatki zbyt skąpe do odtworzenia |
| Zgadywanie błędów | Znane obszary wysokiego ryzyka, integracje, kod wrażliwy bezpieczeństwowo | Pomija nieznane niewiadome; polega na indywidualnym doświadczeniu |
| Testowanie oparte na listach kontrolnych | Regresja, zagadnienia przekrojowe, sprawdzenia niefunkcjonalne | Mechaniczne podejście; listy kontrolne się starzeją |
W praktyce trzy techniki wzajemnie się wzmacniają. Lista ataku na błędy jest wyspecjalizowaną listą kontrolną. Misja testowania eksploracyjnego może być zasianiem przez zgadywanie błędów. Używaj ich razem, zamiast wybierać tylko jedną.
6. Budowanie bazy doświadczeń
Techniki oparte na doświadczeniu są tak dobre, jak twoje doświadczenie. Celowe budowanie tej bazy procentuje przez całą karierę.
Osobisty dziennik defektów — prowadź bieżącą listę każdego interesującego defektu, który znalazłeś, w tym co go spowodowało i gdzie go znalazłeś. Przeglądaj ją przed rozpoczęciem nowych zadań testowych.
Studiuj postmortem — gdy nastąpi incydent produkcyjny, uważnie przeczytaj postmortem. Co zawiodło? Co pominięto w testowaniu? Co by to wykryło?
Czytaj doradztwa bezpieczeństwa — bazy CVE, OWASP Top 10 i biuletyny bezpieczeństwa dostawców opisują rzeczywiste tryby awarii. To hipotezy błędów podane na tacy.
Testuj w parach ze starszymi testerami — obserwuj, jak myślą doświadczeni testerzy. Pytania, które zadają i obszary, które badają, są produktem lat skumulowanego zgadywania błędów.
Przeglądaj systemy śledzenia błędów — szukaj wzorców w historycznym rejestrze problemów organizacji. Które moduły mają najwięcej defektów? Którzy programiści popełniają najwięcej błędów off-by-one? Te dane kształtują twoją następną listę ataku na błędy.
7. Podsumowanie
Techniki oparte na doświadczeniu stanowią trzeci filar projektowania testów — nie rezerwę na wypadek braku pomysłów, lecz ustrukturyzowany sposób stosowania zgromadzonej wiedzy.
- Testowanie eksploracyjne to zdyscyplinowane, oparte na sesjach badanie prowadzone przez misję.
- Zgadywanie błędów / atak na błędy to testowanie oparte na hipotezach, zbudowane na tym, co poszło nie tak w przeszłości.
- Testowanie oparte na listach kontrolnych to szybkie, możliwe do udostępnienia pokrycie znanych ważnych obszarów.
Żadna z tych technik nie zastępuje technik czarnoskrzynkowych ani białoskrzynkowych. Wszystkie razem sprawiają, że twoje zestawy testów są mądrzejsze.
Zadanie do wykonania przed kolejną sesją testową: Poświęć 15 minut na napisanie listy ataku na błędy dla funkcji, którą zaraz będziesz testować. Zacznij od przypadków granicznych, potem pomyśl o punktach integracji, a następnie sprawdź trzy ostatnie błędy znalezione w tym obszarze. Znajdziesz więcej defektów — i zrobisz to szybciej.
Następna część — Część 9: Zarządzanie testami: planowanie, estymacja i metryki