Definicja

Scenariusz testowy to dokumentacja określająca konkretny cel testu lub obszar funkcjonalny, który musi zostać zweryfikowany. Można go traktować jako most łączący wymagania biznesowe z technicznymi aspektami zapewnienia jakości. Podczas gdy Przypadek użycia mówi o tym, jak użytkownik korzysta z systemu, scenariusz testowy odpowiada na pytanie: “Czy ta konkretna funkcja działa poprawnie w danym kontekście?”.

Struktura i poziomy szczegółowości

Warto odróżnić scenariusz testowy od bardzo szczegółowego przypadka testowego (test case):

  • Scenariusz testowy (CO): Jest ogólny. Przykład: “Sprawdzenie możliwości opłacenia zamówienia kartą kredytową”.
  • Przypadek testowy (JAK): Jest szczegółowy. Zawiera konkretne kroki (1. Wpisz numer karty…, 2. Kliknij zapłać…) oraz dane testowe i oczekiwany rezultat.

Skąd brać scenariusze testowe?

Analityk biznesowy i systemowy dostarczają fundamentów pod budowę scenariuszy poprzez:

  1. Kryteria Akceptacji (AC): Każdy punkt w AC z User Story powinien stać się co najmniej jednym scenariuszem testowym.
  2. Scenariusze alternatywne w Przypadkach Użycia: Wszystkie ścieżki błędów (np. “Błędny kod PIN”) muszą zostać pokryte scenariuszami testowymi.
  3. Wymagania niefunkcjonalne: Scenariusze dotyczące wydajności (np. “Sprawdzenie zachowania systemu przy 500 użytkownikach”).

Rodzaje scenariuszy testowych

Podczas analizy systemowej warto zaplanować różne perspektywy testów:

Typ Cel
Pozytywne (Happy Path) Weryfikacja, czy funkcja działa przy poprawnych danych.
Negatywne (Error Handling) Sprawdzenie, czy system poprawnie reaguje na błędy (np. brakujące pola).
Integracyjne Weryfikacja przepływu danych między systemem a zewnętrznym API.
Regresyjne Sprawdzenie, czy nowa zmiana nie popsuła istniejących już funkcji.

Scenariusze testowe w Agile

W środowisku zwinnym dąży się do automatyzacji i wczesnego definiowania testów:

  • Shift Left Testing: Tworzenie zarysów scenariuszy już podczas Backlog Refinementu, co pozwala deweloperom pisać kod od razu z myślą o testach.
  • Behavior Driven Development (BDD): Zapisywanie scenariuszy w formacie Given-When-Then (Zakładając, że… - Kiedy… - Wtedy…), co sprawia, że są one czytelne zarówno dla biznesu, jak i automatycznych narzędzi testowych.

Typowe błędy

  • Zbyt skomplikowane scenariusze – Łączenie wielu niezależnych funkcji w jeden długi scenariusz, co utrudnia identyfikację miejsca awarii.
  • Brak mierzalnych rezultatów – Scenariusze typu “Sprawdź, czy system działa szybko” zamiast “Sprawdź, czy czas ładowania wynosi < 2s”.
  • Pomijanie warunków brzegowych – Testowanie tylko standardowych wartości, zamiast sprawdzania np. zachowania systemu przy datach granicznych lub pustych polach.

Podsumowanie

Dobrze zdefiniowane scenariusze testowe są gwarancją, że dostarczany Inkrement jest wysokiej jakości i spełnia założenia biznesowe. Dla analityka są one narzędziem walidacji – jeśli nie da się napisać scenariusza testowego dla wymagania, oznacza to zazwyczaj, że samo wymaganie jest niejasne.


Powiązane pojęcia:

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