Po co pisać przypadki testowe
Przypadek testowy to zapis jednego sprawdzenia: w jakim stanie zaczynasz, co robisz i czego oczekujesz. Dzięki niemu test może wykonać ktoś inny, możesz go powtórzyć przy regresji, a po czasie wiadomo, co zostało sprawdzone.
To trzecia część serii “Testowanie od podstaw”. Teorię, na której opierają się techniki z tego wpisu, opisuję w poprzedniej części.
Elementy przypadku testowego
| element | po co |
|---|---|
| identyfikator | żeby dało się go wskazać w raporcie i zgłoszeniu |
| tytuł | co sprawdzamy, w jednym zdaniu |
| warunki wstępne | stan systemu przed testem: konto, uprawnienia, dane |
| dane testowe | konkretne wartości, nie “jakieś dane” |
| kroki | ponumerowane akcje |
| oczekiwany wynik | co ma się stać; bez tego nie wiadomo, czy test przeszedł |
| powiązanie | wymaganie lub historyjka, której dotyczy |
| priorytet | które testy wykonać, gdy brakuje czasu |
Przykład
Wymaganie: przy rejestracji użytkownik podaje wiek. Konto mogą założyć osoby w wieku od 18 do 65 lat.
ID: REJ-07
Tytuł: Rejestracja odrzuca wiek poniżej 18 lat
Wymaganie: US-112, rejestracja konta
Priorytet: wysoki
Warunki wstępne: użytkownik niezalogowany, formularz rejestracji otwarty
Dane: e-mail [email protected], hasło Test!2026, wiek 17
Kroki:
1. Wypełnij e-mail i hasło.
2. W polu "Wiek" wpisz 17.
3. Kliknij "Załóż konto".
Oczekiwany wynik:
- konto nie zostaje utworzone;
- pod polem "Wiek" widać komunikat o minimalnym wieku 18 lat;
- wpisane dane pozostają w formularzu.Zwróć uwagę na trzy rzeczy. Tytuł mówi, co jest sprawdzane. Dane są konkretne. Oczekiwany wynik ma kilka punktów, bo “nie zakłada konta” to za mało: formularz, który czyści wszystkie pola po błędzie, też jest problemem.
Klasy równoważności
Ile wartości wieku warto sprawdzić? Wszystkich się nie da, a losowe wybieranie nic nie daje. Technika klas równoważności dzieli dane na grupy, które system powinien traktować tak samo:
| klasa | przykład | oczekiwany wynik |
|---|---|---|
| poniżej 18 | 10 | odrzucony |
| od 18 do 65 | 30 | przyjęty |
| powyżej 65 | 80 | odrzucony |
| nie liczba | abc | odrzucony |
| puste pole | (brak) | odrzucony |
Z każdej klasy bierzesz jedną wartość. Pięć testów zamiast kilkudziesięciu, a każdy sprawdza coś innego.
Wartości brzegowe
Najwięcej błędów kryje się na granicach. Programista napisał wiek > 18 zamiast wiek >= 18 i osiemnastolatek nie może się zarejestrować. Dlatego do klas dokładasz wartości na granicach i tuż za nimi:
| wartość | dlaczego | oczekiwany wynik |
|---|---|---|
| 17 | tuż pod dolną granicą | odrzucony |
| 18 | dolna granica | przyjęty |
| 65 | górna granica | przyjęty |
| 66 | tuż nad górną granicą | odrzucony |
Zanim zaczniesz testować, upewnij się, że granice są jasne. “Od 18 do 65” może znaczyć “do 65 włącznie” albo “przed 65. urodzinami”. Takie pytanie zadane na etapie wymagań oszczędza zgłoszenie defektu, który okaże się nieporozumieniem.
Tablica decyzyjna
Gdy wynik zależy od kilku warunków naraz, pomaga tablica decyzyjna. Przykład: darmowa dostawa przysługuje klientom z kartą stałego klienta albo przy zamówieniu od 200 zł.
| karta stałego klienta | zamówienie od 200 zł | darmowa dostawa |
|---|---|---|
| tak | tak | tak |
| tak | nie | tak |
| nie | tak | tak |
| nie | nie | nie |
Cztery kombinacje, cztery przypadki. Przy trzech warunkach byłoby ich osiem, więc tablica szybko pokazuje, czy jakaś kombinacja nie została pominięta w wymaganiach.
Najczęstsze błędy
- Brak oczekiwanego wyniku. Kroki bez wyniku to instrukcja obsługi, nie test.
- Kilka sprawdzeń w jednym przypadku. Gdy test nie przejdzie, nie wiadomo, która część zawiodła.
- Ogólne dane. “Wpisz poprawny e-mail” każdy zrozumie inaczej.
- Zależność od innych testów. Przypadek, który działa tylko po wykonaniu poprzedniego, psuje się przy zmianie kolejności.
- Opisywanie interfejsu zamiast zachowania. “Kliknij niebieski przycisk w prawym górnym rogu” przestaje być prawdą po pierwszym redesignie.
Przypadek testowy czy lista kontrolna
Nie każdy test potrzebuje pełnego opisu. W stabilnym produkcie i doświadczonym zespole często wystarczy lista kontrolna, np. “rejestracja: granice wieku, zajęty e-mail, słabe hasło”. Pełne przypadki opłacają się tam, gdzie test wykonują różne osoby, gdzie są wymogi audytu albo gdzie przypadek ma potem trafić do automatyzacji.
Przypadki testowe trzyma się zwykle w narzędziu do zarządzania testami (TestRail, Xray, Zephyr) albo, w małych projektach, w arkuszu. Na start wystarczy arkusz.
Co dalej
Gdy przypadek testowy nie przejdzie, trzeba zgłosić defekt, i to jest kolejna część serii. Jeśli przygotowujesz się do rozmowy, techniki z tego wpisu pojawiają się w pytaniach rekrutacyjnych w dziale o projektowaniu testów.
Seria “Testowanie od podstaw”
- Czym zajmuje się tester i jak zacząć
- Teoria testowania w pigułce
- Jak napisać przypadek testowy (ten wpis)
- Jak zgłaszać defekty
- Testowanie API od podstaw
- Pierwsze kroki w automatyzacji testów