Scenariusze testowe - jako praktyka projektowania ich zestawu - to budowanie kompletu scenariuszy, który pokrywa wymagania, zamiast zbioru przypadkowych pomysłów testerów. Narzędziownia pochodzi z technik projektowania testów: podział na klasy równoważności, wartości brzegowe, tablice decyzyjne dla kombinacji reguł, ścieżki w modelu procesu. Spoiwem jest macierz pokrycia (traceability matrix): wymaganie → scenariusze, dzięki której widać, co jest sprawdzone, a co wisi w próżni.
Dla analityka to praca na styku z zespołem testów: on wnosi wymagania i reguły biznesowe, testerzy - techniki i przypadki; razem odpowiadają na pytanie "skąd wiemy, że przetestowaliśmy to, co trzeba?".
Przykład (MediFlow). Reguła biznesowa: "wizytę można bezpłatnie odwołać do 24 godzin przed terminem". Analiza wartości brzegowych natychmiast produkuje scenariusze: odwołanie 24 godziny i 1 minutę przed wizytą (bezpłatne), 23 godziny 59 minut (płatne) oraz dokładnie 24 godziny - i tu niespodzianka: reguła nie precyzuje, czy granica jest "do" czy "włącznie". Analityk wraca z tym do biznesu, reguła zostaje doprecyzowana, a przy okazji wychodzi, że SMS przypominający wysyłany właśnie 24 godziny przed wizytą zachęca do odwołania... już płatnego. Jedna technika testowa, dwa naprawione wymagania.
Częsta pomyłka. Mierzenie jakości testów liczbą scenariuszy: 200 wariacji happy path daje gorsze pokrycie niż 30 scenariuszy dobranych technikami, za to świetnie wygląda w raporcie. Druga pomyłka: zestaw scenariuszy bez powiązania z wymaganiami - gdy wymaganie się zmienia, nikt nie wie, które testy zaktualizować. Trzecia: kopiowanie zestawu z poprzedniego projektu; scenariusze dziedziczą wtedy cudze reguły biznesowe, a własnych - tych naprawdę groźnych - nikt nie napisał.