Agil testplan - behöver vi verkligen en?

Behöver vi ett Agile Test Plan Document?

Testplanering är en viktig aktivitet i en testprocess och en som kräver noggranna tankar och beslut från inte bara testchefen (som vanligtvis är ansvarig för att skapa testplanen) utan alla medlemmar i testteamet och produktutvecklingschefen.

Vissa människor tror att det är den viktigaste delen av testprocessen (jag personligen tycker att testdesign och abstrakt tänkande är det viktigaste) och spenderar många timmar och ansträngningar på att komma med en bra testplan.

Läroböcker tillägnar ett helt avsnitt relaterat till testplanering, hur man skriver en och vad man ska inkludera i en testplan medan vissa styrande organ och tillsynsorganisationer som FDA kräver en omfattande testplan för att godkänna en produkt.

I den verkliga världen, i en vattenfallsmiljö, är testplandokumentet ofta en som man nästan aldrig tittar på under produktens livscykel. Aktiviteten med 'Testplanering och övervakning' bör vara en pågående aktivitet under projektets livscykel, den bör uppdateras enligt ändringar i projektet, men i de flesta fall är detta inte fallet; testplanen uppdateras antingen inte eller ändringarna är retrospektiva, vilket gör testplanen till den minst värdefulla biprodukten.

Medan testplanering nästan alltid betraktas som en måste-ha-produkt i ett vattenfallsprojekt, behöver vi verkligen en testplan för ett smidigt projekt? dvs tillför det verkligen något värde till vad hela laget försöker uppnå?

Det smidiga manifestet gynnar helt klart fungerande programvara över omfattande dokumentation och svarar på förändring över att följa en plan.

I en smidig miljö diskuteras innehållet i en release (objekten) före sprinten så att testteamet i förväg vet vad som är omfattningen och vad som ska testas.

I 'planeringspokerspelet' diskuteras uppskattningarna så att testteamet vet hur lång tid det tar att testa en funktion (detta inkluderar miljöinställningar, scenarier, automatisering, utforskande, prestanda osv.).

I ”berättelseskrivningssession” där detaljer om varje funktion är genomtänkt börjar testteamet redan skriva scenarier för att täcka de många sätt som berättelser kan testas på - detta är teamets mest värdefulla aktivitet.

Under sprinten testar QA kontinuerligt ny kod / funktion. Testplanering blir en dynamisk aktivitet när prioriteringarna för dagen förändras. Testning baseras på vad som är aktiviteten för dagen och resultatet av dagen innan.

Det är tydligt att testplanen inte avslöjar brister men testscenarier kommer att göra det. Ansträngningen måste flyttas för att skapa bättre scenarier än att skapa en testplan.

Vad som verkligen behövs är ett kort agilt teststrategidokument som beskriver de processer som är tillämpliga över sprints , dvs avsnitt om sprintplanering, specifikationer Workshops, manuell kvalitetssäkring, automatisering, testtäckning, testrapportering, testmiljöer, iscensättning osv ... Detta är processer och aktiviteter som gäller för varje sprint men naturligtvis härledda av företagets vision.

Så med allt detta i åtanke, hör testplandokumentet eller omfattande teststrategier verkligen till det förflutna? Behöver vi verkligen en Agile Test Plan?