Plan testów (ang. test plan) to dokument opisujący, jak będzie testowane wydanie lub projekt: zakres (co testujemy, a czego świadomie nie), podejście i poziomy testów, środowiska i dane, role, harmonogram oraz kryteria wejścia i wyjścia - czyli warunki rozpoczęcia testów i uznania ich za zakończone. Strukturę podpowiadają normy IEEE 829 i ISO/IEC 29119.
Analityk biznesowy nie pisze planu testów samodzielnie (to rola lidera testów), ale dostarcza do niego trzy rzeczy: kryteria akceptacji wymagań, biznesową ocenę ryzyka (co wolno przepuścić, a co zabija proces) i organizację testów akceptacyjnych użytkownika (UAT).
Przykład (MediFlow). Plan testów e-rejestracji: w zakresie - rezerwacja, przekładanie i odwoływanie wizyt oraz powiadomienia SMS; poza zakresem - rozliczenia z NFZ (osobny system, osobny projekt). Środowisko testowe wyłącznie z danymi syntetycznymi, bo prawdziwe dane pacjentów to szczególna kategoria RODO i nie mają prawa trafić na środowisko deweloperskie. UAT: cztery rejestratorki z różnych placówek przez tydzień pracują na dwóch ekranach - stary system i nowy równolegle. Kryterium wyjścia: zero otwartych błędów krytycznych i wysokich, no-go przy jakimkolwiek błędzie w naliczaniu slotów.
Częsta pomyłka. Mylenie planu testów ze scenariuszami testowymi: plan to strategia i organizacja ("co, kto, kiedy, na czym, dokąd"), scenariusze to konkretne sytuacje do sprawdzenia. Druga pomyłka: plan napisany raz, na początku, i nieaktualizowany - po trzech zmianach zakresu dokument opisuje testowanie produktu, którego już nie budujemy. Plan żyje albo jest makulaturą.