Definicja

Przypadek testowy to precyzyjny zestaw warunków, kroków i danych testowych, opracowany w celu zweryfikowania, czy konkretna funkcja systemu działa zgodnie z założeniami. O ile Scenariusz testowy określa co testujemy, przypadek testowy definiuje dokładnie jak to robimy, nie pozostawiając miejsca na domysły testera.

Struktura Przypadku Testowego

Profesjonalnie przygotowany przypadek testowy powinien zawierać następujące elementy:

  1. ID i Nazwa: Unikalny identyfikator i krótki opis celu (np. TC_001: Logowanie poprawnymi danymi).
  2. Warunki wstępne (Preconditions): Stan systemu przed testem (np. „Użytkownik posiada aktywne konto”).
  3. Kroki (Steps): Ponumerowana lista akcji do wykonania (np. „1. Wpisz e-mail… 2. Kliknij przycisk…”).
  4. Dane testowe (Test Data): Konkretne wartości użyte w teście (np. login: test@wp.pl, hasło: S3cur3!).
  5. Oczekiwany rezultat (Expected Result): Co powinno się stać (np. „System wyświetla Dashboard”).
  6. Rezultat rzeczywisty (Actual Result): Pole wypełniane po wykonaniu testu (kluczowe przy raportowaniu błędów).
  7. Status: Wynik (Pass/Fail/Blocked).

Różnice: Scenariusz vs Przypadek Testowy

Wielu analityków i testerów myli te pojęcia, dlatego warto zestawić je obok siebie:

Cecha Scenariusz Testowy Przypadek Testowy
Poziom Wysoki (biznesowy). Niski (operacyjny).
Pytanie Co sprawdzić? Jak to sprawdzić (krok po kroku)?
Przykład Sprawdź procedurę zakupu. 1. Dodaj produkt X do koszyka… 2. Wybierz InPost…
Odbiorca PO, Interesariusze, Managerowie. Testerzy, Deweloperzy (przy naprawie bugów).

Przypadek testowy w procesie Agile

W zwinnym wytwarzaniu oprogramowania rzadko tworzy się setki stron dokumentacji testowej przed startem prac. Stosuje się za to:

  • Test-Driven Development (TDD): Deweloper pisze przypadek testowy (w kodzie) przed napisaniem samej funkcji.
  • Acceptance Criteria (AC) jako baza: Każde kryterium akceptacji z User Story jest bezpośrednim źródłem dla przypadków testowych.
  • Automatyzacja: Dobrze opisane przypadki testowe są podstawą do pisania skryptów automatycznych (np. w Selenium lub Cypress).

Dobre praktyki tworzenia (INVEST w testach)

Dobre przypadki testowe powinny cechować się:

  • Precyzją: Każdy tester, wykonując te same kroki, musi osiągnąć ten sam wynik.
  • Niezależnością: Wynik jednego przypadku nie powinien blokować możliwości wykonania innego (o ile to możliwe).
  • Mierzalnością: Oczekiwany rezultat musi być zero-jedynkowy (udało się lub nie).

Typowe błędy

  • ❌ Brak danych testowych – Pisanie „Wpisz login” bez podania, czy ma to być login poprawny, czy błędny.
  • ❌ Zbyt długie przypadki – Łączenie 20 kroków w jeden test. Jeśli błąd wystąpi w 15. kroku, trudno jest powtórzyć całą procedurę.
  • ❌ Opisywanie oczywistego UI – Skupianie się na tym, że „okno jest szare”, zamiast na tym, czy dane zostały zapisane w bazie.

Podsumowanie

Przypadki testowe są „instrukcją obsługi jakości” dla produktu. Pozwalają one na obiektywną ocenę, czy to, co zostało zbudowane, jest zgodne z tym, co zostało zaprojektowane w fazie Inżynierii Wymagań.

Powiązane pojęcia:

Kliknij w pojęcie, aby przejść do jego definicji w słowniku