際際滷

際際滷Share a Scribd company logo

Testplanen i sin enkelhet

Download as DOCX, PDF
Johan Hoberg
Johan Hoberg

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 of 3
Downloaded 11 times
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
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
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

More Related Content

Testplanen i sin enkelhet

  • 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