Plán testování považuji v návrhu postupu testování softwaru za stěžejní dokument pro celý proces. Při realizaci návrhu jej doporučuji vytvořit jako první dokument před samotným začátkem testování softwaru. Při realizaci postupu testování softwaru musí být jakousi „biblí“ pro každého člena testovacího týmu a musí obsahovat odpovědi na veškeré otázky ohledně procesu testování daného software. Pokud na nějakou otázku z jakýchkoliv důvodů nemůže být odpověď uvedena přímo v dokumentu, bude obsahovat odkazy na místa (nebo osoby), kde se odpověď nalézá.
Plán testování obsahuje především rozsah postupu testování software, definuje druhy a kategorie testů, stanovuje harmonogram prací.
Plán testování musí minimálně obsahoval:
- Cíle testování – definice toho, co očekáváme přesně od provedení testů nad softwarem. Někdy to může být jen ověření nové funkčnosti, jindy naopak kompletní otestování celé aplikace.
- Seznam plánovaných oblastí k testování – Přestože by cílem testování při realizaci měly být všechny funkce software, je nutné vytvořit seznam těchto oblastí. K těmto oblastem také navrhuji přiřadit prioritu, která bude určovat, v jakém pořadí budou oblasti otestovány.
- Kategorie testů – kategorie testů, které budou využity během testovacího cyklu. Případně jejich využití v různých úrovních testování
- Seznam testovacích případů – seznam unikátních identifikátorů testovacích případů. Navrhuji je seřadit podle pořadí, v jakém budou spouštěny
- Definice rizik pro testování – definice hlavních rizik, které mohou znemožnit testování. Jejich podrobný seznam s ohodnocením a návrhem řešení těchto situací je zpracován v analýze rizik
- Požadavky na testovací data – definice dat, které jsou nezbytná pro provádění testů.
Mimo výše uvedené oblasti navrhuji umístit do plánu testování také harmonogram plánovaných testů. Harmonogram umožňuje čtenářům plánu testování udělat si velmi dobrou představu o tom, jaké činnosti na sebe kdy navazují. Nevýhodou je však situace, kdy se harmonogram mění i během realizace postupu testování softwaru. Udržovat pak dokument stále aktuální může být obtížné. Navrhuji proto poznamenat v plánu testování, že harmonogram je pouze orientační a nelze jej považovat za definitivní. Poznámka proto musí obsahovat sdělení, že je nutné, ověřit si aktuálnost údaje v harmonogramu u vedoucího testovacího oddělení (autora dokumentu).
Dále navrhuji dbát na přehlednost a srozumitelnost dokumentu plánu testování, jelikož je ze své podstaty určen pro všechny pracovníky, kteří se podílejí na vývoji softwaru. Rozhodně nedoporučuji uvádět odborné termíny z oblasti testování softwaru bez detailnějšího popisu.
Ještě mi tam chybí tyto kritické oblasti:
–Výstupy z testování – Co vše testování bude poskytovat? Reporty, test casy, dodání automatických testů, vše, co podává informace, nebo může být produktem, na který můžou být kladeny požadavky. Pozor, na tyto věci se musí Test manažer vyloženě ptát, málokdy mu jsou sděleny tyto očekávání explicitně.
– –Požadavky na vstupy a zdroje Kvalitu testování hodně omezuje kvalita vstupů a zdrojů ( např. dokumentů s požadavky, projektovým plánem a specifikací) Pokud očekávání jsou obrovská a vstupy a zdroje nedostatečné, je potřeba aby už před tvorbou test plánu, test manažer vysvětlil, že toto není realistické.
Díky porovnání možností a očekávání Test manažer odpoví na tyto otázky:
– Jsou vhodnější spíše free testy nebo testy dle scénářů?
– Je možné ve stanoveném čase s danou specifikací připravit podrobné test casy, aby na testování byli nasazeni brigádníci?
– Budeme si muset sami předem připravit testovací data?
– Stihneme důkladně otestovat všechny kritické části aplikace a alespoň pozitivní testy všech funkčností?
– Potřebujeme naplánovat zátěžové, bezpečnostní testy nebo testy přívětivosti (user experience)?
– Jaké dopady bude mít, když dojde k posunu začátku testování? Dokážu tyto dopady specifikovat a vyčíslit?
Bez zahrnutí definice kvality vstupů a výstupů procesu je testování tak trochu neřízený chaos a otloukánek. Test manažerovi chybí totiž pádné argumenty, aby mohl vysvětlit, proč potřebuje právě tolik času a zdrojů a proč to nelze zkrátit na polovinu.