Jag fick igår en fråga mailad till mig: “Har du möjligtvis en kortfattad enkel beskrivning på olika testfaser i ett projekt, bl.a. Unittest, Systemtest, Integrationstest resp Acceptanstest?”. Svaret på denna korta fråga blir dock långt och skrivet med vissa kval.
Svår fråga eftersom det numera är ganska förvirrade begrepp, och dessutom stundom ett ålderdomligt tankemönster.
Redan RUP 2003 omarbetade testavsnitten, övergav V-modellen och delade, tack vare de täta iterationer man tänkte sig, upp testerna enbart i utvecklartester och systemtester. Jag kan tycka att det är en bra sak att särskilja testerna på ansvarsområden snarare än faser (speciellt i en agil värld där faserna är mer glidande och de “rättrogna agilisterna” ofta försöker undertrycka att de ens existerar), men tycker att det är en något begränsande sätt att se det.
En vanlig indelning är ju i hur stor andel av systemet som testerna omfattar, och den brukar även kunna ligga till grund för en kronologiskt hanterbar processindelning:
* Enhetstest (på en liten enhet kod)
* Integrationstest in the small (på samverkan mellan systemkomponenter)
* Systemtest (på hela systemet)
* Systemintegrationstester (på beroendesambanden mellan externa system och systemet under test)
En annan indelning är ju efter när i projektet de inträffar, och eftersom man vid agil utveckling gärna snabbt och tidigt går i produktion och därefter fortsätter utvecklingen parallellt blir det lite förvirrat. Man kan därför dela upp det i de tester som genomförs kontinuerligt:
* Enhetstester
* System integration testing in the small
* Systemtest av ny funktionalitet
* Regressionstest
* Omtest av rättade fel
Vid sidan av dessa har vi de andra typer av tester som genomförs när det är möjligt och lämpligt:
* User acceptance test
* Användbarhetstest
* Operations acceptance test
* Prestandatester
* Systemintegrationstester
* Säkerhetstester
* Fail-over-tester
* Robusthetstester
* Förvaltningsbarhetstester
… Osv
Många av den senare typen av tester genomförs enligt behovs- och riskhanterad praxis vid lämpliga tillfällen, som till exempel inför större driftsättningar. Nu när automatiserad continuous deployment blir allt med efterfrågat ska det bli spännande att se hur dessa typer av tester hanteras. I någon mån har användbarhetstester och user acceptance testing ersättas med den täta verksamhetsavstämning som de agila principerna bygger på, men det kan vara bra att planera för särskilda fokustillfällen även för dessa, om inte annat för verksamhetsförankringens skull och för att man då får fokus på hela systemet snarare än enskilda komponenter.
Det finns ju även formella tester som ofta måste genomföras, och de vill man ofta genomföra på ett så produktionslikt system som möjligt. Dessa kan innefatta compliance-tester, regulatoriska krav, och om beställar- och leverantörsförhållandet så kräver; acceptanstestning.
Självklart varierar scope och definitioner med huruvida det handlar om interna projekt, inköpta system, externt beställda system eller något däremellan. Dessutom varierar de med den övergripande change-processen och vilka aktörers och intressenters åsikter som väger tyngst, vilket gör svaret något mer komplicerat ändå.
Nå, jag svävar ut eftersom detta är något som jag finner skevt i testvärlden. För att göra svaret enkelt. Kolla gärna SSTBs ordlista (www.sstb.se).
Mitt tips: De gamla definitionera av testfaserna bygger på V-modellen, som i sin tur endast är en (ofta vantolkad och övertolkad) beskrivning av vilka typer av tester som sker mot vilken typ av dokumentation. Eftersom denna dokumentation sällan tas fram inom ett agilt projekt, och dessutom inte kommer i någon slags ordning så är det svårt att bygga en testprocess på det. Snegla istället på vem som ska göra vad, och när, samt vad som är minimun framtaget att det behövs för att kunna genomföra uppgiften. Det är ju essensen av vad som behövs. Det allra bästa tipset är kanske: Börja göra vad som känns rätt, men vig tid för extern kunskapsinhämtning samt för reflektion över hur du kunde gjort bättre, så har du ett fungerande system för ständig förbättring. Med tiden bör det testarbetet därigenom bli sketabra! 🙂
Bra beskrivning. Men jag vill fortfarande slå ett slag för v-modellen. Den är en “kortfattad, enkel beskrivning på olika testfaser” som fortfarande fungerar. Anpassa den lite och den fungerar perfekt för att förklara hur testningen fungerade igår, fungerar idag och hur den kommer att fungera imorgon!
Se gärna min artikel från april 2011:
http://www.testzonen.se/?p=2228
Ja, V-modellen fungerar, och speciellt i din tolkning. Mina invändningar rör främst att den ofta tycks övertolkas, och att den är exkluderande så att de som baserar testerna på den riskerar ha ett fokus som kanske stundom är sub-optimalt.
* Det finns en förvirring om V-modellen visar testfaser, testnivåer när den ursprungligen skapad för att bara visa vilken typ av test som lutar sig mot vilken dokumentation.
* En del verkar inrymma ett tidsperspektiv i V-modellen, vilket bland annat lett till W-modeller och liknande. Det fanns inte från början och är nog ganska överspelat med agil utveckling. Specification-by-example i ATDD och likanande spegelvänder möjligen i sådana fall i någon mån modellen.
* I en tid då affärsnytta ständigt är huvudfokus för systemutvecklingen kan det visserligen vara bra att belysa att det finns fler tester att genomföra, men då begreppet verksamhetsnytta är så mångfacetterat är jag inte helt trygg med att luta mig mot V-modellen för att nå den.
* Att dokumentera för mycket är improduktiv sk waste, och ofta kommer därför dokumentationen (allt för) sent i projekten, vilket gör att det är svårt att följa V-modellen praktiskt. Det är dock, som du säger, inte helt fel att ha V-modellen som underlag för hur det “bör” hänga ihop så man kan hantera de genvägar man tar.
* Utvecklingsunderlagen, de formulerade förväntningarna på systemet (också kända som “Kraven” eller ett dussin andra namn), har blivit väldigt mycket mindre fixa sedan V-modellen skapades, vilket lett till att testningen stundom skiftat karaktär och att kontroller mot specifikation endast utgör en bråkdel av testarbetet.
* Kvalitetshöjande testaktiviteter i realtid, som parprogrammering och partestning, får till exempel inte rum i modellen.
* Få bilder av V-modellen innehåller systemintegrationstestning in the large
Således: Som pedagogiskt hjälpmedel, ja. Som praktiskt användbar modell, långt ifrån alltid emedan processer och organisationsstrukturer sätter käppar i hjulen.
Googles indelning av vad tester omfattar:
http://googletesting.blogspot.se/2010/12/test-sizes.html#!/2010/12/test-sizes.html