Article about test plans and why they should be simple, and what they should include. In swedish. Based on thoughts of James Whittaker and James Bach.

1. Testplanen i sin enkelhet
Under ett års tid har jag haft som en del av mina arbetsuppgifter att granska
testplaner för olika typer av applikationer och produkter. Detta har givet
upphov till ett antal reflektioner kring hur jag tycker en testplan bör vara
utformad för att faktiskt generera någon form av värde, och inte bara vara
formalia som påtvingas utvecklings- och testteamen.
Min tankegång inspireras löst av James Bachs definition av en testplan [1]:
Test Plan: the set of ideas that guide a test project
Test Strategy: the set of ideas that guide test design
Test Logistics: the set of ideas that guide the application of resources to fulfill a test strategy
Också James Whittakers tankar kring tio-minuters-testplanen [2], som bygger
på att det du inte hinner skriva ner i din testpl an på 10 minuter förmodligen
inte är relevant nog att ha med i den, är något jag tycker är väldigt intressant.
Vad jag vill uppnå är en så enkel testplan som möjligt, som bara innehåller
information som är värdefull, förändringsbenägen och lämplig att ha i denna
typ av projektdokument. All statisk information som inte förändras över
projektets gång vill jag förpassa till teststrategier eller logistikdokument.
Jag tror att det finns ett värde i enkelhet som i det här fallet uppkommer
genom att dokumentet blir enklare att förklara och förstå, samtidigt som det
kostar mindre att skapa. Det jag framför allt vill undv ika är dokument som
till stor del är kopior av tidigare testplaner, med en massa statisk
information som ingen reflekterar över eller tar hänsyn ti ll.
Hur ser då en enkel och värdefull testplan ut? Allt är så klart
kontextberoende, men jag tror att den bör innehålla följande komponenter:
Ansvarsområden
Testkonfigurationer
Definition of Done
Aktivitetsbeskrivningar
Aktivitetsplanering
Riskmatris

2. Återkopplingsmekanism
Det bör alltså vara tydligt i testplanen vem som har vilka ansvarsområde n,
och vad dessa områden innefattar. Det är inte omöjligt att detta varierar över
tiden, speciellt om man använder sig av utforskande testning. Genom att
dokumentera detta vet utomstående vem de ska kontakta i teamet, och det är
enklare att undvika överlapp som kan uppkomma när flera testare angriper
samma testområde, p.g.a. oklara ansvarsgränser.
Vilken konfiguration av produkten som tester utförs på bör också vara
beskrivet. Prioriteringar mellan olika konfigurationer kan variera över
projektets gång och det är viktigt att det är tydligt vilken eller vilka
konfigurationer en viss testaktivitet har utförts på. Om detta inte definieras
blir det oklart vad som faktiskt testats, och den produkt en viss kund faktiskt
får, kan vara något helt annat än den som teamet har testat.
Varje aktivitet eller testfas bör ha ett tydligt definierat slut, och skiftande
prioriteringar kan göra att dessa definitioner ändrar sig över tiden. Det ska
vara tydligt för stakeholders vad som faktiskt har utförts när en aktivitet
eller fas är över, så att de inte har felaktiga förväntningar. Vilken kvalitet,
testtäckning och risknivå man kan förvänta sig, samt vilken formell
dokumentation som finns tillgänglig, är exempel på vad definitionen kan
innehålla.
Testaktiviteter som ska utföras under projektet bör också finnas beskrivna i
testplanen. Vilka scope de olika aktiviteterna har, och deras syfte, längd,
samt vad startkriterierna är, bör t.ex. finnas dokumenterat. Detta gör det
enklare för stakeholders att förstå testarbetet och sätter testresultaten i rätt
kontext.
Hur dessa aktiviteter är förlagda i tiden , när rapporter finns tillgängliga,
samt vilka resurser som behövs och finns att tillgå vid de olika tidpunkterna
är nog den mest klassiska komponenten i en testplan. Det är definitivt något
som kan förändras över tiden, och inte något man kan kopiera från en
gammal testplan utan eftertanke. Ofta ett krav från stakeholders som t.ex.
projektledare eller linjechefer.
En av de viktigaste sakerna jag tittade på när jag granskade testplaner var
vilka risker som hade identifierats, och hur det var tänkt att olika
testaktiviteter skulle mitigera dessa risker. Detta är något jag tycker
testplanen bör innehålla. Riskerna bör prioriteras på något sätt, antingen
genom en ”låg, medium, hög” klassificering, eller någonting mer raffinerat,
som t.ex. ”Severity, Occurrence, Detection”, och det bör också finnas en
mitigeringsplan i form av någon slags testakt ivitet. Denna riskidentifiering är
långt ifrån enkel, och svårigheterna ökar med systemets komplexitet. Detta

3. var något jag hade överseende med när jag granskade testplaner, men man
bör ändå kunna förvänta sig ett tappert försök till att kartlägga den befintliga
riskbilden och att skapa en mitigeringsplan för de kända riskerna.
Slutligen bör det finnas någon form av återkopplingsmekanism som beskriver
hur tanken är att testplanen ska utvecklas över projektets gång. Vilken
information kommer man att utnyttja för att utveckla och förbättra
testplanen, så att det inte blir ett dokument man bara skriver i början av
projektet och sen inte använder. En viktig del av detta är återkoppling kring
och uppdatering av riskmatrisen, som snabbt blir meningslös om den in te
uppdateras.
Detta var mitt försök att med utveckla mina egna tankar, baserade på James
Bachs och James Whittakers artiklar, kring hur testplaner bör vara utformade.
Jag har säkert missat viktiga komponenter som bör vara med i en testplan,
och i specifika kontexter kan det säkert variera avsevärt, men kanske har det
väckt några tankar hos läsaren kring vad som bör inkluderas i detta för
testaren centrala, och förhoppningsvis värdefulla, dokument.
/Johan Hoberg
Referenser
[1]A question about test strategy
http://www.satisfice.com/blog/archives/63
[2]The 10 Minute Test Plan
http://googletesting.blogspot.se/2011/09/1 0-minute-test-plan.html