W dobrze prowadzonym projekcie przypadek testowy nie jest listą przypadkowych kliknięć, lecz powtarzalnym sprawdzianem konkretnego wymagania. Poniżej pokazuję, jak powinien wyglądać użyteczny szablon, a także gotowe przykłady dla logowania, formularza, koszyka i API, które można łatwo dopasować do własnego systemu.
Dobry przypadek testowy prowadzi od warunków początkowych do jednoznacznego wyniku
- Jeden cel oznacza jeden przypadek testowy, który można niezależnie wykonać i ocenić.
- Oczekiwany rezultat powinien opisywać konkretną, obserwowalną reakcję aplikacji.
- Przypadki pozytywne, negatywne i brzegowe razem dają znacznie lepsze pokrycie niż sama ścieżka poprawna.
- Szablon powinien obejmować identyfikator, priorytet, warunki wstępne, dane, kroki i status.
- Zarządzanie testami wymaga powiązania przypadków z wymaganiami, defektami i wersją produktu.
Jak wygląda dobry przypadek testowy i po co ten format
Przypadek testowy opisuje konkretną próbę sprawdzenia systemu. Zawiera warunki początkowe, dane wejściowe, działania użytkownika oraz rezultat, który można jednoznacznie porównać z rzeczywistym zachowaniem aplikacji. Dzięki temu tester nie musi za każdym razem interpretować ogólnego polecenia w rodzaju „sprawdź logowanie”.
W praktyce rozróżniam trzy poziomy opisu. Scenariusz testowy mówi, co chcemy sprawdzić, na przykład „użytkownik może zalogować się do panelu”. Przypadki testowe rozbijają ten scenariusz na konkretne sytuacje, takie jak poprawne dane, błędne hasło, puste pole czy przekroczenie limitu prób.
| Element | Przykład | Dlaczego jest potrzebny |
|---|---|---|
| Identyfikator | AUTH-001 | Ułatwia śledzenie wyniku i powiązanie z defektem. |
| Tytuł | Logowanie poprawnymi danymi | Od razu pokazuje cel testu. |
| Warunki wstępne | Aktywne konto użytkownika istnieje. | Zapobiega niejasnościom przed rozpoczęciem testu. |
| Dane testowe | Adres e-mail i poprawne hasło | Pokazuje, na jakich danych wykonano sprawdzenie. |
| Kroki | Otwórz stronę, wpisz dane, wybierz „Zaloguj”. | Pozwala innej osobie powtórzyć test. |
| Oczekiwany rezultat | Użytkownik trafia do panelu i widzi swoje imię. | Definiuje warunek zaliczenia. |
| Status | Passed, Failed, Blocked | Pokazuje wynik wykonania w danym środowisku. |
Najczęstszy błąd widzę w polu oczekiwanego rezultatu. Zdanie „system działa poprawnie” niczego nie rozstrzyga. Znacznie lepiej napisać, że przycisk zostaje zablokowany, komunikat pojawia się pod polem, a dane nie są zapisane. Taki rezultat można sprawdzić bez dyskusji.
Szablon przypadku testowego do skopiowania
Nie każdy projekt potrzebuje kilkunastu pól. W małym zespole wystarczy lekki format, natomiast przy rozbudowanej regresji potrzebne są również informacje o wersji, środowisku, automatyzacji i powiązanym wymaganiu. Ja zaczynam od zestawu podstawowego, a dodatkowe kolumny dodaję dopiero wtedy, gdy faktycznie pomagają w pracy.
ID: AUTH-001
Tytuł: Logowanie poprawnymi danymi
Typ: Funkcjonalny
Priorytet: Wysoki
Powiązane wymaganie: US-104
Warunki wstępne:
- Konto jest aktywne.
- Użytkownik ma zweryfikowany adres e-mail.
Dane testowe:
- E-mail: anna@example.test
- Hasło: PoprawneHaslo!23
Kroki:
1. Otwórz stronę logowania.
2. Wpisz adres e-mail.
3. Wpisz hasło.
4. Kliknij przycisk „Zaloguj”.
Oczekiwany rezultat:
Użytkownik zostaje przekierowany do panelu konta,
a w nagłówku widzi swoje imię.
Rzeczywisty rezultat: [uzupełnić po wykonaniu]
Status: Not run
Środowisko: [uzupełnić]
Wersja aplikacji: [uzupełnić]
Defekt: [uzupełnić, jeśli wystąpił]Warto zachować jedną czynność na krok. Instrukcja „wpisz dane i zatwierdź formularz” utrudnia ustalenie, w którym miejscu pojawił się problem. Oddzielne kroki są szczególnie ważne przy testach wykonywanych przez różne osoby oraz przy późniejszej automatyzacji.
Dobry przypadek powinien być niezależny, powtarzalny i możliwie odporny na drobne zmiany interfejsu. Nie opisuję więc koloru przycisku, jeśli nie jest on przedmiotem testu. Skupiam się na zachowaniu, które ma znaczenie dla użytkownika lub wymagania.
Przykłady testów logowania z pozytywną i negatywną ścieżką
Logowanie jest dobrym przykładem, ponieważ łączy prostą ścieżkę poprawną z walidacją, bezpieczeństwem i obsługą błędów. Poniższe przypadki pokazują, jak z jednego wymagania zbudować mały, ale sensowny zestaw.
| ID | Cel | Dane i działanie | Oczekiwany rezultat | Priorytet |
|---|---|---|---|---|
| AUTH-001 | Poprawne logowanie | Aktywny e-mail i prawidłowe hasło | Przejście do panelu użytkownika, utworzenie sesji | Wysoki |
| AUTH-002 | Błędne hasło | Prawidłowy e-mail i nieprawidłowe hasło | Komunikat o nieprawidłowych danych, brak logowania | Wysoki |
| AUTH-003 | Puste pola | Wysłanie formularza bez danych | Walidacja wskazuje wymagane pola, żądanie nie jest wysłane | Wysoki |
| AUTH-004 | Nieprawidłowy format e-maila | Wartość „anna@” | Komunikat o błędnym formacie adresu | Średni |
| AUTH-005 | Limit nieudanych prób | Kolejne nieudane logowania zgodnie z regułą produktu | Konto lub logowanie zostaje czasowo ograniczone, a użytkownik widzi jasny komunikat | Wysoki |
W przypadku limitu prób nie wpisywałbym automatycznie liczby „5” ani „15 minut”, jeśli wymaganie jej nie definiuje. Test musi wynikać z ustalonej reguły biznesowej, a nie z przyzwyczajenia testera. Jeżeli produkt zakłada blokadę po pięciu błędach na 15 minut, wtedy warto stworzyć osobne przypadki dla próby numer 4, 5 i 6.
Przy testach bezpieczeństwa sprawdzam także, czy komunikat nie zdradza, który element jest błędny. Informacja „konto o takim adresie istnieje, ale hasło jest złe” może ułatwiać rozpoznawanie użytkowników. Bezpieczniejszy rezultat to neutralny komunikat o nieprawidłowym adresie lub haśle.
Przykłady dla formularza, koszyka i wartości granicznych
Najwięcej defektów nie pojawia się przy typowych danych, lecz na granicach reguł. Jeżeli pole akceptuje od 8 do 64 znaków, nie wystarczy sprawdzić wartości 12. Testuję co najmniej 7, 8, 64 i 65 znaków, a osobno uwzględniam pustą wartość oraz znaki nietypowe.
Formularz rejestracyjny
| Przypadek | Dane | Oczekiwany rezultat |
|---|---|---|
| Poprawne dane | Imię, poprawny e-mail, hasło 12 znaków, zaakceptowany regulamin | Konto zostaje utworzone, a użytkownik otrzymuje informację o aktywacji. |
| Brak zgody | Wszystkie dane poprawne, checkbox regulaminu niezaznaczony | Formularz nie zostaje wysłany, a zgoda jest wskazana jako wymagana. |
| Duplikat adresu | E-mail przypisany do istniejącego konta | System nie tworzy drugiego konta i pokazuje zrozumiały komunikat. |
| Granica długości | Hasło o długości 7, 8, 64 i 65 znaków | Akceptowane są wartości zgodne z regułą, a pozostałe są odrzucane. |
Przeczytaj również: HP QC - Mity i fakty o zarządzaniu testami. Czy warto?
Koszyk zakupowy
W koszyku sprawdzam nie tylko dodanie produktu. Równie ważne są zmiana ilości, usunięcie pozycji, przeliczenie ceny i zachowanie po odświeżeniu strony. Każdy z tych elementów może działać poprawnie osobno, a mimo to zawodzić w całym przepływie.
- Dodanie dostępnego produktu zwiększa liczbę pozycji i aktualizuje sumę.
- Zmiana ilości z 1 na 2 przelicza wartość produktu oraz całego koszyka.
- Próba wpisania ilości 0 lub wartości ujemnej jest odrzucona.
- Usunięcie ostatniego produktu pokazuje pusty koszyk i nie nalicza dostawy.
- Odświeżenie strony zachowuje koszyk, jeśli takie zachowanie przewiduje wymaganie.
- Produkt wyprzedany nie może zostać zamówiony mimo wcześniejszego dodania do koszyka.
Te przykłady dobrze pokazują różnicę między testem funkcjonalnym a przypadkowym klikaniem. Każdy przypadek odpowiada na jedno pytanie i ma jasny warunek zaliczenia. Dzięki temu wynik można później wykorzystać w regresji albo zautomatyzować.
Jak opisać przypadek testowy API
W testach API interfejs graficzny nie jest potrzebny, ale zasada pozostaje ta sama. Trzeba określić żądanie, dane wejściowe, warunki, oczekiwany kod odpowiedzi oraz najważniejsze pola w odpowiedzi.
| Element | Przykład |
|---|---|
| Cel | Utworzenie nowego zamówienia dla zalogowanego użytkownika |
| Warunek wstępny | Istnieje aktywny token i dostępny produkt o identyfikatorze 782. |
| Żądanie | Metoda POST, poprawny token, lista produktów i adres dostawy |
| Oczekiwany status | Kod 201 |
| Oczekiwana odpowiedź | Odpowiedź zawiera identyfikator zamówienia, status „created” i poprawną sumę. |
| Wariant negatywny | Brak tokenu lub niedostępny produkt |
| Rezultat negatywny | Kod 401 albo 409 zgodnie z kontraktem API, bez utworzenia zamówienia. |
W tym przypadku nie ograniczam się do sprawdzenia kodu 200 lub 201. Kontroluję również strukturę odpowiedzi, typy danych, reguły biznesowe i brak skutków ubocznych. Przy nieudanym żądaniu zamówienie nie powinno zostać zapisane, nawet jeśli odpowiedź błędu wygląda poprawnie.
Jak zarządzać przypadkami, żeby nie zamieniły się w dokumentację bez wartości
Duża liczba przypadków testowych nie oznacza automatycznie dobrego pokrycia. Zestaw 300 niemal identycznych testów może być mniej użyteczny niż 40 dobrze dobranych przypadków obejmujących główne ścieżki, błędy i granice.
Każdy przypadek warto powiązać z konkretnym wymaganiem lub kryterium akceptacji. Taka identyfikowalność pozwala szybko odpowiedzieć, które funkcje sprawdzono po zmianie i gdzie powstaje luka. Pomaga też ograniczyć testy osierocone, czyli takie, których nikt już nie potrafi przypisać do działającej funkcji.
- Oznacz typ testu, na przykład funkcjonalny, regresyjny, integracyjny lub bezpieczeństwa.
- Ustal priorytet, aby w krótkim oknie testowym uruchomić najważniejsze przypadki jako pierwsze.
- Dodaj wersję aplikacji i środowisko, ponieważ wynik może zależeć od konfiguracji.
- Po zmianie wymagania przejrzyj powiązane przypadki, zamiast tylko dopisywać nowe.
- W przypadku niepowodzenia zapisz rzeczywisty rezultat, dane, logi i identyfikator defektu.
- Oznacz przypadki automatyzowane, ale nie zakładaj, że automatyzacja zastępuje testy eksploracyjne.
Reguła priorytetyzacji jest prosta. Wysoki priorytet dostają funkcje, których awaria blokuje użytkownika, płatność, bezpieczeństwo lub główny proces biznesowy. Testy kosmetyczne i rzadko używane warianty mogą poczekać, szczególnie gdy zespół pracuje pod presją czasu.
Nie aktualizowałbym każdego kroku po najmniejszej zmianie interfejsu. Dokumentacja powinna być wystarczająco szczegółowa, ale nie tak krucha, by zmiana etykiety przycisku wymagała przebudowy całej regresji. Opisuj zachowanie i dane, a szczegóły wizualne dodawaj tylko wtedy, gdy są częścią wymagania.
Co odróżnia użyteczny test od pozornie dokładnego
Najgorsze przypadki testowe często wyglądają profesjonalnie, bo mają wiele pól i długi opis. Problem pojawia się dopiero podczas wykonania, gdy tester nie wie, jaki rezultat uznać za poprawny albo musi samodzielnie uzupełnić brakujące dane.
| Słaby zapis | Lepszy zapis |
|---|---|
| Sprawdź formularz logowania. | Przy pustym haśle formularz pokazuje komunikat „Hasło jest wymagane” i nie wysyła żądania. |
| System działa poprawnie. | Po zapisaniu formularza rekord pojawia się na liście z właściwym numerem i statusem „Aktywny”. |
| Wpisz poprawne dane. | Użyj aktywnego konta testowego QA-17 i hasła określonego w danych środowiska testowego. |
| Sprawdź różne wartości. | Przetestuj wartości 7, 8, 64 i 65 znaków dla pola z limitem od 8 do 64 znaków. |
Unikam też testów, które zależą od siebie bez wyraźnej potrzeby. Jeżeli przypadek B wymaga wcześniejszego przejścia przypadku A, awaria A może zablokować dużą część zestawu. Lepiej przygotować niezależne dane lub jasno oznaczyć zależność, aby wynik nie został błędnie zinterpretowany.
Przed dodaniem przypadku zadaję sobie trzy pytania. Jakie wymaganie sprawdzam? Co dokładnie musi się wydarzyć, aby test został zaliczony? Czy inna osoba wykona go bez ustnej instrukcji? Jeśli na któreś pytanie nie mam dobrej odpowiedzi, przypadek wymaga dopracowania.
Od przykładu do zestawu, który naprawdę wspiera wydanie
Najlepszy punkt startowy to jeden krytyczny przepływ, na przykład logowanie albo zakup. Rozpisuję dla niego ścieżkę poprawną, błędną i brzegową, a później dodaję przypadki integracyjne oraz regresyjne. Taki zestaw jest mały, ale szybko pokazuje, czy przyjęty format działa w praktyce.
Nie chodzi o to, by opisać każdą możliwą kombinację danych. Chodzi o świadome pokrycie ryzyka i pozostawienie po sobie czytelnego śladu decyzji testowych. Dobrze napisany przypadek pozwala szybciej wykryć defekt, łatwiej odtworzyć problem i bez zbędnych pytań ocenić gotowość funkcji do wydania.
