Dobry przypadek testowy to najmniejsza samodzielna jednostka pracy testera: opisuje, co sprawdzamy, na jakich danych i jaki wynik uznajemy za poprawny. W praktyce u klientów widzę, że jakość testów rzadko rozbija się o brak narzędzi, częściej o niejasno spisane scenariusze, które da się zrozumieć na trzy różne sposoby. W tym artykule pokazuję, z czego składa się porządny przypadek testowy, daję gotowy przykład w formie tabeli oraz szablon do skopiowania, żebyś mógł zacząć od razu.
Co to jest przypadek testowy i po co go pisać
Przypadek testowy (ang. test case) to konkretna instrukcja: zestaw kroków i danych, które prowadzą do sprawdzenia jednego, jasno określonego zachowania systemu. Nie mylimy go ze scenariuszem testowym (który zwykle grupuje wiele przypadków) ani z planem testów, który opisuje strategię całego projektu.
Po co go spisywać, skoro część rzeczy da się przeklikać z głowy? Bo dobrze napisany przypadek daje trzy rzeczy naraz: powtarzalność (każdy wykona test tak samo), przekazywalność (nowa osoba w zespole nie zgaduje) i podstawę do automatyzacji. Gdy przychodzi moment, żeby część testów przenieść do kodu, czytelny przypadek manualny jest gotowym projektem skryptu, o wyborze między jednym a drugim piszę w tekście Testy manualne czy automatyczne.
Anatomia dobrego przypadku testowego: pola krok po kroku
Nie ma jednego obowiązującego standardu, ale te pola sprawdzają się niezależnie od projektu i narzędzia (Jira, TestRail, arkusz):
- ID: unikalny, stały identyfikator (np. TC-LOGIN-001). Służy do odwołań w zgłoszeniach błędów i raportach.
- Tytuł: jedno zdanie mówiące, co sprawdzamy. Dobry tytuł czyta się bez otwierania szczegółów.
- Warunki wstępne: stan systemu przed startem (istniejące konto, zalogowanie, dane w bazie).
- Kroki: numerowana, jednoznaczna sekwencja akcji. Jeden krok = jedna czynność.
- Dane testowe: konkretne wartości wejściowe (login, hasło, kwota), a nie „poprawne dane”.
- Oczekiwany rezultat: mierzalny efekt: co dokładnie ma się wydarzyć i gdzie to widać.
- Priorytet: wysoki/średni/niski, według ryzyka i częstości użycia funkcji.
Przykład przypadku testowego: logowanie
Poniżej pełny przykład dla scenariusza pozytywnego, poprawne logowanie do aplikacji. Zwróć uwagę, że każde pole jest konkretne i nie zostawia miejsca na interpretację.
| Pole | Wartość |
|---|---|
| ID | TC-LOGIN-001 |
| Tytuł | Logowanie poprawnymi danymi kieruje na pulpit użytkownika |
| Warunki wstępne | Istnieje aktywne konto (jan.kowalski@example.com); użytkownik jest wylogowany; strona logowania otwarta |
| Kroki | 1. Wpisz adres e-mail w pole „E-mail”. 2. Wpisz hasło w pole „Hasło”. 3. Kliknij przycisk „Zaloguj się”. |
| Dane testowe | E-mail: jan.kowalski@example.com · Hasło: Test1234! |
| Oczekiwany rezultat | Użytkownik zostaje przekierowany na /pulpit; w prawym górnym rogu widoczne imię „Jan”; brak komunikatu o błędzie |
| Priorytet | Wysoki |
Do kompletu warto dopisać przypadki negatywne (błędne hasło, puste pole, konto zablokowane), każdy jako osobny, atomowy rekord z własnym ID.
Dobre praktyki: atomowość, jednoznaczność, powtarzalność
Cztery zasady, do których wracam przy każdym przeglądzie zestawu testów:
- Atomowość: jeden przypadek sprawdza jedną rzecz. Jeśli test „przy okazji” weryfikuje trzy funkcje, po jego niepowodzeniu nie wiesz, co się zepsuło.
- Jednoznaczność: zamiast „sprawdź, czy działa” pisz „system wyświetla komunikat X w polu Y”. Oczekiwany rezultat musi być weryfikowalny bez dyskusji.
- Powtarzalność: ten sam przypadek daje ten sam wynik u każdego wykonawcy. Dlatego dane testowe są konkretne, a warunki wstępne wypisane.
- Niezależność: przypadek nie zakłada, że wcześniej wykonano inny (chyba że jawnie w warunkach wstępnych). Kolejność wykonywania nie może cię zaskoczyć.
Częste błędy, które psują testy
- Ogólnikowy rezultat: „powinno działać poprawnie”, nie da się jednoznacznie ocenić pass/fail.
- Brak danych testowych albo „dowolne poprawne dane”, kto inny wpisze co innego.
- Kroki zlepione w jedno zdanie, trudno wskazać, na którym etapie test padł.
- Pomijanie warunków wstępnych, test przechodzi u autora, u innych „nie da się odtworzyć”.
- Mieszanie wielu weryfikacji w jednym przypadku, spada czytelność i rośnie koszt późniejszej automatyzacji.
Szablon przypadku testowego do skopiowania
Skopiuj poniższą listę pól i wypełniaj ją dla każdego testu. Sprawdza się jako wiersz w arkuszu albo jako pola w TestRail czy Jirze. Jeśli dopiero układasz cały proces testowy, zacznij od szerszego kontekstu, mam o tym osobny tekst: Plan testów w projekcie, od czego zacząć.
- ID: [np. TC-MODUŁ-001]
- Tytuł: [co sprawdzamy, jedno zdanie]
- Warunki wstępne: [stan systemu i dane przed startem]
- Kroki: [1. … 2. … 3. …]
- Dane testowe: [konkretne wartości wejściowe]
- Oczekiwany rezultat: [mierzalny, weryfikowalny efekt]
- Priorytet: [wysoki / średni / niski]
Jak pomagam w tym w QA Sensei
Od 20 lat pracuję w IT, od siedmiu jako inżynier jakości i wiem, że dobrze spisane przypadki testowe to fundament, na którym opiera się reszta: raportowanie, regresja i późniejsza automatyzacja. Pomagam zespołom uporządkować zestawy testów, wprowadzić spójny szablon i priorytetyzację opartą na ryzyku, a następnie zdecydować, co zautomatyzować, testy interfejsu w Selenium lub Playwright, testy wydajności w JMeter, a co zostawić manualne. Pracuję zdalnie w całej Polsce, a w okolicach Wrocławia także u klienta. Więcej o zakresie znajdziesz w sekcji usług, a o samej współpracy w opisie procesu. Jeśli zastanawiasz się, czy testy zlecić na zewnątrz, pomocny będzie tekst Outsourcing QA, kiedy warto.