Det finns inget bättre än när alla protokoll i valfri acceptans- eller testfas bara kan checkas av. Fungerar, inga problem, klart respektive hittat ett fel, rättat ett fel, fungerar, klart. Oftast är vägen till en accepterad produkt, tjänst eller applikation en process i flera iterationer. Det är viktigt att hålla koll på alla iterationer och säkerställa spårbarhet för att fatta rätt beslut. Det är insamlingen av information till beslut, som genomförs i test- och acceptansfaserna av ett projekt. I detta inlägg vill jag belysa vad skillnaden mellan testfall och testutfall är och hoppas en analogi till att packa sin resväska kan hjälpa till att illustrera processen.
Skillnaden mellan testplan, testfall och testuppföljning
Oavsett om du har arbetat i IT-projekt eller inte så har du säkerligen gjort en checklista någon gång. Kanske en checklista för att inte glömma att packa något inför en resa? Låt oss ta det som ett exempel för att förklara skillnaden mellan testplan, testfall och test(utfalls)uppföljning.
För att säkerställa att väskan blir färdigpackad och att inget glöms bort skulle nog de allra flesta göra en enkel lista och agera på den:
- Skriv en lista över alla saker som behöver packas.
Det är en analogi till acceptanskriterierna i ett projekt, en sprint eller liknande. - Packa (eventuellt i omgångar, dagar innan, dagen innan och det sista innan avresa - Glöm inte tandborsten på morgonen!)
Det är själva genomförande av systemutveckling och processimplementation i analogin. - Bocka av allt som är med (sannolikt i omgångar här med – Vad bra, tandborsten är med!)
Detta är i analogin själva testutförandet.
Packlistan respektive testplanen skapas för att ha en tydlig plan för vad som behöver packas eller implementeras. Analogin mellan IT-projekt och en packlista har så klart sina begräsningar. Ytterst sällan behövs fler än ett ord för att förstå vad som behöver packas. Mycket sällan behöver man granska om tandborsten håller måttet inför resan. Den kanske viktigaste skillnaden är att en packning i regel är överskådlig, medan ett projekt oftast är mer komplext med många inblandade personer, processer och system, vilket gör det svårt att få en överskådlighet och det finns ett större behov för uppföljning. Det är just därför viktigt att ha en plan över vem som är ansvarig över packlistan (alltså testfallen), vem som packar vad och när det ska packas. I slutet ska ju beslut fattas om man är redo att stänga resväskan (eller sprinten/projektet).
Ta höjd för iterationer
Själva nyttan med packlistan är att bedömningen av utfallet är enkel och transparent. Alla punkter är överstrukna eller avbockade – perfekt. Om man vill slippa att ta fram en helt ny checklista för varje resa är det smart att ta fram en mall som kan återanvändas. Förmodligen kommer behovet för varje packning variera, men inte ändras i grunden. Denna mall för packlistan går att jämföra med att ha en mall för acceptanskriterierna eller testfallen i IT projektet. Det underlättar att ha en mall för dessa så att de kan användas i flera iterationer eller för flera resor. Tandborsten som många andra saker behövs ju ändå på nästan varje resa. Många grundläggande krav, steg eller kriterier behöver checkas i varje iteration av utvecklingen. Det är viktigt att dokumentera utfall för varje testiteration – för att fatta rätt beslut. Det är alltså viktigt att skilja mellan mallen och själva checklistan som tas fram baserad på mallen.
Uppdateras behovet för testerna eller packlistan, så gör man det i mallen. Det påverkar inte gamla listor respektive dokumentation av testomgångar, men alla framtida kommer att innehålla ändringen. Säg att något ändrar sig i livet eller i systemlandskapet. Du kanske behöver packa en extra tandborste för ditt barn just har fått sin första tand. I systemlandskapet erbjuder ni kanske kunden ett digitalt kvitto framöver – det behöver också testas i varje iteration.
Fördelen är att all dokumentation kommer att vara mer komplett och rättvis, både framåt och bakåt. Särskilt i testsammanhanget, kan man även ta kopior av samma mall och enbart ändra vissa parametrar, till exempel att testa via en mobil enhet, att testa med olika betalsätt i ett betalflöde eller med olika leveranssätt i ett leverans- och kvittoflöde. Det är lättare att notera med vilka ingångsvärden man har testat. Det kan även innefatta programvaruversion, testdata eller vilka kollegor som genomförde testen vid vilken tidpunkt.
Allt ovan är något som testverktyg har bra stöd för! Vill du veta mer? Kontakta oss på Centigo eller ta kontakt med Marcel Buder. Och: Glöm inte tandborsten!
