Scenariusz testowy (ang. test scenario) to opis sytuacji do przetestowania sformułowany z perspektywy celu biznesowego: co sprawdzamy i po co. Stoi piętro wyżej niż przypadek testowy (test case), który rozpisuje scenariusz na konkretne kroki, dane wejściowe i oczekiwany wynik - jeden scenariusz zwykle rodzi kilka przypadków.
Analityk biznesowy jest naturalnym współautorem scenariuszy: wyprowadza je z kryteriów akceptacji, reguł biznesowych i przypadków użycia, a potem recenzuje pokrycie - czy testy sprawdzają to, co dla biznesu naprawdę ważne, a nie to, co łatwo było zautomatyzować.
Przykład (MediFlow). Scenariusz dla e-rejestracji: "dwóch pacjentów próbuje jednocześnie zarezerwować ostatni wolny slot u kardiologa". Cel biznesowy: nigdy nie może dojść do podwójnej rezerwacji, a przegrywający pacjent nie może zostać z niczym. Oczekiwanie: jeden dostaje potwierdzenie, drugi - czytelny komunikat plus trzy najbliższe alternatywne terminy. Z tego scenariusza powstają przypadki testowe: kolizja web vs web, web vs rejestratorka przy okienku, web vs bot listy rezerwowej. Ten scenariusz nie wziął się z sufitu - wynika wprost z rozszerzenia 6a przypadku użycia UC-03 i z bólu, który podwójna rezerwacja oznacza w realnej przychodni.
Częsta pomyłka. Pisanie scenariuszy wyłącznie dla happy path: rezerwacja się udaje, dane są poprawne, system odpowiada. Tymczasem błędy mieszkają w wyjątkach - zajęty slot, zerwane połączenie w kroku 7, pacjent z trzema aktywnymi rezerwacjami próbujący czwartej. Druga pomyłka: mieszanie poziomów, czyli scenariusz rozpisany od razu jako 40 klików z danymi testowymi - to już przypadek testowy; scenariusz ma być na tyle zwięzły, żeby biznes mógł go przeczytać i powiedzieć "tak, to trzeba sprawdzić".