Šablona pro testovací plán

Další šablonou, kterou přidávám do Google Docs je Test Plan.

Není to "čistá šablona", vyplnil jsem ji vzorovým projektem - pro představu jak by to mohlo asi vyplněné vypadat (smazat část obsahu můžete vždy). Pokud po vyplnění obsahu bude testovací plán rozsáhlejší, doplňte si na samostatný list seznam kapitol (obsah).

Teď něco málo k obsahu test plánu. Různé metodiky mají pro něj různě sofistikované definice, případně se liší pořadí kapitol, někdy částečně i obsah. Co je ale podstatné z praktického hlediska - musí mít zahrnutou v sobě odpověď na tyto otázky:

1. Co je cílem testů - jaké jsou přínosy? Proč by měl někdo (projektový manažer...) za toto úsilí zaplatit?
2. Co přesně za ty peníze dostanu? Tedy scope testů (co se bude testovat, co ne a proč, do jaké hloubky), testovací strategie (jakým způsobem testy proběhnou, kdo je zodpovědný za jednotlivé činnosti) a výstupy z testovacího procesu (závěrečný report; nebo pouze seznam chyb, počet vykonaných testů atd.) 
3. Testovací prostředí - kde se co bude testovat, kdo bude zodpovědný za chod prostředí a podobně.
4. Testovací data - jak budou získána, kdo je bude vytvářet (někdy je příprava dat časově hodně náročná - třeba je nutné data anonymizovat...)
5. Požadované součinnosti - koho kromě testerského týmu bude třeba alokovat pro support (například podpora vývojáře při přípravě dat, business analytika pro konzultace...) - nezapomínejte, že i tuto podporu někdo musí zaplatit.
6. Akceptační kritéria - kdy bude produkt chápán jako akceptovatelný pro reálný provoz (nutno domluvit se zainteresovanými rolemi, například projektovým manažerem; test manažer si je nemůže napsat sám bez schválení)
7. Pozastavení/znovuobnovení testů - u "interních" projektů se to v test plánech uvádí málokdy, u projektů typu dodavatel-zákazník to je důležité z hlediska toho, kdo zaplatí případné prostoje (například když se najde tak závažný problém v produktu, že testeři zákazníka nemohou testovat, jen "sedí a čekají na opravu od dodavatele").
8. Harmonogram testů - kdy (z časového hlediska) se bude vykonávat která činnost a kdo je za ni odpovědný. Prakticky je to detailní projektový plán pro oblast testování. Je dobré uvádět i časový rozsah od-do, ale i náročnost v mandays (jelikož tyto dva údaje se mohou lišit)
9. Zdroje, role a zodpovědnosti - tady se uvádějí údaje, podle kterých má projektový manažer nakoupit zdroje (lidské, materiální...). U lidských zdrojů pokud není známo přímo jméno konkrétního člověka, uvádí se alespoň role (od které se odvíjejí hodinové sazby).
10. Rizika a omezení - je vhodné uvést, když jsou přítomna a mohou výrazně ovlivnit výsledky testů, nebo kvalitu produktu (třeba když něco není možné otestovat kvůli omezením testovacího prostředí...)
11. Pravidla a použité metodiky - opět se spíše uvádí u dodavatelských projektů, mělo by se určit jednoznačné chápání pojmů (například co se rozumí pod pojmem testovací případ) a případně ošetřovat alespoň základní situace "co dělat když..." - dá se pak vyhnout pozdějšímu handrkování mezi dodavatelem a zákazníkem typu "my jsme si mysleli...". Hloubka popisů záleží od zvyklostí firmy, případně vztahu mezi dodavatelem a zákazníkem (lze to psát například "orientačně" - v hrubých rysech a jen nejdůležitější věci, nebo "defenzivně" - podrobně).

Pokud se chcete dozvědět o test plánu podrobněji, koukněte se na příslušný odsek v syllabu pro ISTQB certifikaci, nebo třeba metodiku RUP, část testování.