Testplanen i sin enkelhet

615 views
404 views

Published on

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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
615
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Testplanen i sin enkelhet

  1. 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. 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. 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

×