Techniki projektowania testów — czarna skrzynka
Techniki czarnoskrzynkowe pozwalają projektować skuteczne testy bez znajomości kodu. Poznaj podział na klasy równoważności, analizę wartości granicznych, tablice decyzyjne i testy przejść stanów.
📚 To jest Część 6 serii ISTQB Poziom Podstawowy. Poprzednie artykuły omawiały podstawy testowania, poziomy testów i typy testów.
1. Wprowadzenie — Projektowanie testów, nie tylko ich uruchamianie
Niemal na każdym zespole QA pojawia się w pewnym momencie ten sam wzorzec: testy pisane przez klikanie po aplikacji aż coś się zepsuje, napędzane intuicją i doświadczeniem, a nie systematycznym myśleniem.
Takie podejście — zwane testowaniem ad hoc — ma realną wartość. Intuicja doświadczonego testera wyłapuje rzeczy, których żaden plan testów by nie przewidział. Ale nie skaluje się. Daje nierówne pokrycie, wielokrotnie omija te same błędy i nie można go odtworzyć, przejrzeć ani przekazać innemu testerowi.
Techniki projektowania testów rozwiązują ten problem. Dają systematyczny sposób na wyprowadzanie przypadków testowych ze specyfikacji — bez polegania na przeczuciu i bez konieczności czytania choćby jednej linii kodu implementacji.
Na tym polega istota testowania czarnoskrzynkowego: traktujesz testowany system jak nieprzezroczystą skrzynkę. Wiesz, co wchodzi (dane wejściowe) i co powinno wychodzić (oczekiwane dane wyjściowe). Nie wiesz — i nie musisz wiedzieć — jak skrzynka działa wewnątrz.
ISTQB definiuje cztery główne techniki czarnoskrzynkowe na Poziomie Podstawowym:
- Podział na klasy równoważności (EP)
- Analiza wartości brzegowych (BVA)
- Tablice decyzyjne
- Testowanie przejść stanów
Jest też testowanie przypadków użycia, które omówimy pokrótce. Przyjrzyjmy się każdej technice z prawdziwymi przykładami.
2. Podział na klasy równoważności (ISTQB 4.2.1)
Koncepcja
Gdy system akceptuje zakres danych wejściowych, przetestowanie każdej możliwej wartości jest niepraktyczne. Pole wieku przyjmujące liczby całkowite od 0 do 120 ma 121 możliwych prawidłowych wartości — i tysiące nieprawidłowych. Nie da się wszystkich przetestować.
Podział na klasy równoważności (EP, ang. Equivalence Partitioning) opiera się na obserwacji, że dane wejściowe zachowujące się tak samo można pogrupować w klasy. Jeśli przetestowanie dowolnej wartości z danej klasy daje ten sam wynik, wystarczy przetestować tylko jedną wartość reprezentatywną z tej klasy.
Klasy mogą być prawidłowe (dane, które system powinien akceptować) lub nieprawidłowe (dane, które system powinien odrzucać).
Przykład
Scenariusz: Aplikacja ubezpieczeniowa przyjmuje klientów w wieku od 18 do 65 lat. Młodsi lub starsi wnioskodawcy są odrzucani.
| Klasa | Zakres | Prawidłowa? | Wartość reprezentatywna |
|---|---|---|---|
| Poniżej minimum | wiek < 18 | ❌ Nieprawidłowa | 10 |
| W zakresie | 18 ≤ wiek ≤ 65 | ✅ Prawidłowa | 40 |
| Powyżej maksimum | wiek > 65 | ❌ Nieprawidłowa | 80 |
Dzięki EP trzy przypadki testowe pokrywają wszystkie trzy klasy. Nie musisz testować wiek = 5, 6, 7, 8… — wszystkie należą do tej samej nieprawidłowej klasy i powinny dawać ten sam wynik “odrzucono”.
Kiedy stosować
EP sprawdza się najlepiej dla:
- Pól numerycznych z określonym zakresem (wiek, wynagrodzenie, ilość)
- Danych kategorycznych (kody statusu, kody krajów, typy płatności)
- Walidacji długości ciągów znaków
- Każdego scenariusza, w którym specyfikacja definiuje wyraźne zakresy prawidłowe i nieprawidłowe
:::tip[Wskazówka egzaminacyjna ISTQB] Kluczowa kwestia egzaminacyjna dotycząca podziału na klasy równoważności: redukuje liczbę przypadków testowych bez zmniejszania pokrycia — ponieważ wybierasz jednego reprezentanta z każdej klasy zamiast wyczerpująco testować wszystkie wartości. ISTQB wymaga też testowania zarówno klas prawidłowych, jak i nieprawidłowych. :::
3. Analiza wartości brzegowych (ISTQB 4.2.2)
Koncepcja
Doświadczenie pokazuje, że defekty skupiają się na krawędziach zakresów wejściowych, a nie w ich środku. Programista implementujący wiek >= 18 AND wiek <= 65 może przez pomyłkę napisać wiek > 18 (pomijając wartość graniczną 18) lub wiek <= 64 (pomijając wartość graniczną 65).
To klasyczny błąd “o jeden za dużo / o jeden za mało” (off by one) — tak powszechny, że ma własną nazwę.
Analiza wartości brzegowych (BVA, ang. Boundary Value Analysis) rozszerza EP, skupiając przypadki testowe na granicach każdej klasy: samej wartości granicznej i wartości tuż za nią.
ISTQB Poziom Podstawowy definiuje dwa warianty:
BVA 2-wartościowe: Testuj wartość graniczną i wartość tuż poza nią.
BVA 3-wartościowe: Testuj wartość tuż przed granicą, samą granicę i wartość tuż za nią.
Przykład
Używając tego samego scenariusza (wiek 18–65):
BVA 2-wartościowe:
| Granica | Wartości testowe |
|---|---|
| Dolna granica (18) | 17 (nieprawidłowa), 18 (prawidłowa) |
| Górna granica (65) | 65 (prawidłowa), 66 (nieprawidłowa) |
BVA 3-wartościowe:
| Granica | Wartości testowe |
|---|---|
| Dolna granica (18) | 17 (nieprawidłowa), 18 (prawidłowa), 19 (prawidłowa) |
| Górna granica (65) | 64 (prawidłowa), 65 (prawidłowa), 66 (nieprawidłowa) |
BVA 3-wartościowe daje większą pewność kosztem większej liczby przypadków testowych. ISTQB Poziom Podstawowy skupia się na BVA 2-wartościowym jako domyślnym wariancie.
Łączenie EP + BVA
W praktyce niemal zawsze używa się EP i BVA razem:
- Użyj EP do identyfikacji klas
- Użyj BVA do wyboru wartości testowych — wybierając z granic każdej klasy zamiast arbitralnych wartości ze środka
Ta kombinacja daje najlepsze pokrycie testów na jeden przypadek testowy.
:::tip[Wskazówka egzaminacyjna ISTQB]
Na pytaniach egzaminacyjnych o BVA zwróć uwagę, czy granica jest włączna, czy wyłączna. wiek >= 18 (włączna) oznacza, że 18 jest prawidłowe; wiek > 18 (wyłączna) oznacza, że 18 jest nieprawidłowe. Wartości brzegowe zmieniają się odpowiednio.
:::
4. Tablice decyzyjne (ISTQB 4.2.3)
Koncepcja
Niektóre systemy podejmują decyzje na podstawie kombinacji warunków. Jeden parametr wejściowy nie wystarczy — wynik zależy od tego, czy wiele warunków jest jednocześnie prawdziwych lub fałszywych.
Tablice decyzyjne modelują to wprost. Każda kolumna w tabeli reprezentuje jedną regułę (unikalną kombinację wartości warunków). Wiersze reprezentują warunki lub wynikające z nich działania.
Przykład
Scenariusz: Bank zatwierdza lub odrzuca wnioski kredytowe na podstawie dwóch warunków:
- Dochód > 50 000 zł rocznie
- Ocena kredytowa > 700
Przy 2 warunkach binarnych istnieją 4 możliwe reguły:
| Reguła 1 | Reguła 2 | Reguła 3 | Reguła 4 | |
|---|---|---|---|---|
| Dochód > 50 000 zł | ✅ Tak | ✅ Tak | ❌ Nie | ❌ Nie |
| Ocena kredytowa > 700 | ✅ Tak | ❌ Nie | ✅ Tak | ❌ Nie |
| → Kredyt zatwierdzony | ✅ Tak | ❌ Nie | ❌ Nie | ❌ Nie |
Tablica mówi: kredyt jest zatwierdzany tylko gdy oba warunki są spełnione. Każda reguła staje się jednym przypadkiem testowym — 4 przypadki testowe pokrywają każdą kombinację.
Dla n warunków binarnych pełna tablica ma 2ⁿ reguł. Przy 3 warunkach — 8 reguł; przy 4 — 16.
Tablice skrócone: Gdy niektóre warunki nie wpływają na wynik (np. kredyt jest zawsze odrzucany przy zbyt niskim dochodzie niezależnie od oceny kredytowej), można połączyć te reguły używając wartości “obojętne” (często zapisywanej jako –). Zmniejsza to liczbę przypadków testowych bez utraty pokrycia.
Kiedy stosować
Tablice decyzyjne są właściwym narzędziem gdy:
- Specyfikacja definiuje reguły biznesowe z wieloma warunkami
- Wynik zależy od kombinacji, a nie pojedynczych wartości
- Testujesz macierze cenowe, reguły kwalifikowalności, logikę rabatów lub reguły routingu
:::tip[Wskazówka egzaminacyjna ISTQB] Częste pytanie egzaminacyjne dotyczy liczby przypadków testowych wymaganych przez tablicę decyzyjną. Dla n warunków binarnych maksimum to 2ⁿ reguł. ISTQB oczekuje też, że rozpoznasz kiedy tablica skrócona jest właściwa. :::
5. Testowanie przejść stanów (ISTQB 4.2.4)
Koncepcja
Niektóre systemy zachowują się inaczej w zależności od aktualnego stanu. Te same dane wejściowe dają różne dane wyjściowe w zależności od tego, co działo się wcześniej. Klasyczny przykład: wysłanie formularza płatności działa za pierwszym razem, ale nie wtedy gdy sesja wygasła.
Testowanie przejść stanów modeluje to, definiując:
- Stany: wyraźne tryby, w których może znajdować się system
- Przejścia: przemieszczenia między stanami wywołane zdarzeniami
- Zdarzenia: dane wejściowe lub działania wywołujące przejścia
- Działania: dane wyjściowe produkowane podczas przejść
Przykład
System sygnalizacji świetlnej:
| Stan bieżący | Zdarzenie | Stan następny | Wyjście |
|---|---|---|---|
| Czerwony | Upłynął czas | Zielony | Pokaż zielone światło |
| Zielony | Upłynął czas | Żółty | Pokaż żółte światło |
| Żółty | Upłynął czas | Czerwony | Pokaż czerwone światło |
| Czerwony | Pojazd uprzywilejowany | Czerwony | Migaj czerwonym |
Ten system ma trzy normalne stany (Czerwony, Żółty, Zielony), trzy normalne przejścia i jedno przejście awaryjne. Każdy wiersz tabeli staje się przypadkiem testowym.
Kryteria pokrycia dla Poziomu Podstawowego:
- Pokrycie wszystkich stanów: każdy stan jest odwiedzany przez co najmniej jeden przypadek testowy
- Pokrycie wszystkich przejść: każde przejście jest wykonywane przez co najmniej jeden przypadek testowy (mocniejsze kryterium — obejmuje pokrycie wszystkich stanów)
Na Poziomie Podstawowym ISTQB skupia się na pokryciu wszystkich przejść jako standardowym kryterium.
Kiedy stosować
Testowanie przejść stanów ma zastosowanie zawsze gdy:
- System ma wyraźne stany (status konta: aktywne / zawieszone / zamknięte)
- Zachowanie zależy od poprzednich działań (3 nieudane próby logowania → konto zablokowane)
- Testujesz przepływy pracy, kreatory lub procesy wieloetapowe
- Testujesz implementacje protokołów (bankomat: włożenie karty → wprowadzenie PIN → transakcja → wylogowanie)
:::tip[Wskazówka egzaminacyjna ISTQB] ISTQB oczekuje, że będziesz potrafił narysować diagram przejść stanów i wyprowadzić z niego przypadki testowe. Skup się na osiągnięciu pokrycia wszystkich przejść — obejmuje ono pokrycie wszystkich stanów i jest standardowym kryterium Poziomu Podstawowego. :::
6. Testowanie przypadków użycia (ISTQB 4.2.5)
Testowanie przypadków użycia wyprowadza przypadki testowe z przypadków użycia lub historyjek użytkownika — opisów tego, jak użytkownik wchodzi w interakcję z systemem, aby osiągnąć cel.
Każdy przypadek użycia ma:
- Przepływ główny (ścieżka szczęśliwa — wszystko działa jak należy)
- Przepływy alternatywne (prawidłowe warianty, np. płatność kartą vs przelewem bankowym)
- Przepływy wyjątkowe (warunki błędu, np. płatność odrzucona)
Dla każdego przypadku użycia projektujesz przypadki testowe pokrywające wszystkie trzy typy przepływów. Zapewnia to, że testowanie odzwierciedla rzeczywiste scenariusze użytkownika, a nie izolowane jednostki funkcjonalne.
Testowanie przypadków użycia wypełnia lukę między wymaganiami a testami, co czyni je szczególnie wartościowym gdy kryteria akceptacji są wyrażone jako historyjki użytkownika — co jest standardem w zespołach Agile.
:::tip[Wskazówka egzaminacyjna ISTQB] Testowanie przypadków użycia jest szczególnie istotne dla testowania systemowego i testowania akceptacyjnego, gdzie skupiamy się na kompleksowych podróżach użytkownika, a nie na pojedynczych funkcjach. :::
7. Wybór odpowiedniej techniki
W praktyce rzadko kiedy używa się tylko jednej techniki. Wybór zależy od tego, jak wygląda specyfikacja i jakich błędów szukasz.
| Scenariusz | Zalecana technika |
|---|---|
| Dane numeryczne z określonym zakresem | EP + BVA |
| Dane kategoryczne (np. typ płatności) | EP |
| Decyzja zależy od wielu warunków | Tablice decyzyjne |
| System ma tryby lub stany | Testowanie przejść stanów |
| Testowanie kompleksowej podróży użytkownika | Testowanie przypadków użycia |
| Złożone reguły biznesowe z wieloma warunkami | Tablice decyzyjne |
| Przepływ pracy ze ścisłą kolejnością (kreator, kasa) | Przejścia stanów + Przypadki użycia |
| Wartości brzegowe w walidowanym polu | BVA |
Typowy przepływ pracy w praktyce:
- Zacznij od testowania przypadków użycia, aby zidentyfikować główne scenariusze
- Zastosuj EP i BVA do wszystkich pól wejściowych w tych scenariuszach
- Zastosuj tablice decyzyjne do złożonych reguł biznesowych z wieloma warunkami
- Zastosuj testowanie przejść stanów jeśli system ma wyraźne stany
8. Podsumowanie
Techniki czarnoskrzynkowe zamieniają projektowanie testów ze zgadywania w inżynierię. Dają systematyczny, powtarzalny proces wyprowadzania przypadków testowych bezpośrednio z wymagań — bez wiedzy o implementacji i z jasnymi kryteriami pokrycia.
Szybki przegląd:
| Technika | Odniesienie ISTQB | Kluczowa idea |
|---|---|---|
| Podział na klasy równoważności | 4.2.1 | Grupuj dane wejściowe według zachowania; testuj jeden na grupę |
| Analiza wartości brzegowych | 4.2.2 | Testuj na granicach klas i tuż za nimi |
| Tablice decyzyjne | 4.2.3 | Pokryj wszystkie kombinacje warunków |
| Testowanie przejść stanów | 4.2.4 | Pokryj wszystkie stany i przejścia |
| Testowanie przypadków użycia | 4.2.5 | Pokryj przepływy główne, alternatywne i wyjątkowe |
Ćwiczenie praktyczne: Weź kryteria akceptacji jednej historyjki z bieżącego sprintu. Zastosuj EP do identyfikacji klas wejściowych, następnie BVA do wyboru konkretnych wartości testowych. Zwróć uwagę, jak systematycznie możesz teraz uzasadnić, dlaczego każdy przypadek testowy istnieje i co pokrywa.
To jest Część 6 serii ISTQB Poziom Podstawowy.