Test case (przypadek testowy) to precyzyjny przepis na pojedynczy test: warunki wstępne, kroki do wykonania, dane testowe i oczekiwany rezultat. Jeden przypadek weryfikuje jedno konkretne zachowanie systemu i daje jednoznaczną odpowiedź: zaliczony albo nie.
Przypadki testowe piszą testerzy, ale surowcem są wymagania i kryteria akceptacji od analityka. Tu działa proste prawo: niejasne wymaganie = nieweryfikowalny test. Dlatego dobrzy testerzy są pierwszymi recenzentami pracy BA - pytanie „jak mam to przetestować?" wykrywa dziury w wymaganiach szybciej niż niejeden przegląd dokumentu.
Przykład z MediFlow, przypadek TC-114: „Rezerwacja przy braku wolnych terminów". Warunek wstępny: lekarz ma zapełniony grafik na 30 dni do przodu. Kroki: pacjent wybiera specjalizację, lekarza, klika „pokaż terminy". Oczekiwany rezultat: komunikat o braku terminów plus przycisk zapisu na listę oczekujących; system nie pokazuje pustego kalendarza. Ten przypadek powstał, bo analityk dopisał do user story scenariusz negatywny - bez niego tester sprawdziłby tylko szczęśliwą ścieżkę.
Częsta pomyłka: mylenie przypadku testowego ze scenariuszem testowym. Scenariusz to szerszy przepływ biznesowy („pacjent umawia i odwołuje wizytę"), który rozpada się na wiele przypadków. Druga: pisanie przypadków wyłącznie dla happy path. Większość błędów produkcyjnych siedzi w przypadkach brzegowych - ostatni wolny slot brany przez dwóch pacjentów naraz, odwołanie wizyty dokładnie 24 godziny przed terminem, pacjent z dwoma kontami.