Test, är det bara en aktivitet ?

Nej, självklart inte säger ju vi som dagligen jobbar med det. Det är ju en viktig aktivitet för att skapa sig en uppfattning om ett systems kvalité samt försöka hitta och fixa så många buggar som möjligt (Vet att det finns flertal olika definitioner av test men jag tycker denna, som i mitt tycke är ganska enkel, funkar bra).

Tyvärr möts man inte alltid av denna inställning till test och det finns väl lika många exempel som det finns företag men några dåliga exempel jag stött på är:

– ”Det står ju i projektstyrningsmodellen att vi måste ha test så du får väl göra det då”
– ”Ja vi ska testa men det måste starta och sluta på de enligt tidplanen fastställda datumen”
– ”Men hälften av en funktion fungerar ju så nu kan du väl börja testa”

De två sista citaten kommer ifrån en organisation som använder sig av en tämligen klassisk projektstyrningsmodell med grindpassager men som också tagit ett steg åt det agila hållet och kör programmeringen i sprintar som även skall innehålla systemtest. Acceptanstest görs i slutet när alla sprintar är klara. Ett viktigt mätetal för företaget var projektets grindpassager och därför ville man t.ex. gärna få igång acceptanstest till varje pris.

En lite djupare analys tycker jag visar att man kanske inte lyckats balansera tid, kostnad och kvalité på ett bra sätt. Detta har jag upplevt som ett inte ovanligt problem och som delvis beror på vilka mätetal man använder (t.ex. grindpassager i det här fallet)

Så vad kan man då göra för att försöka förbättra den här balansen ?
Ett sätt som jag provat är att tillämpa de ”Test entry criteria” (villkoren för start av testning) som vi tagit fram i testplanen lite hårdare för att verkligen säkerställa att systemet är moget för t.ex. acceptanstest när den startar. Tyvärr har jag upplevt ett antal gånger att testplanen enbart har blivit en artefakt som krävs för grindpassage och sedan glöms bort. Mina erfarenheter av en hårdare tillämpning på ovan nämnda företag beskrivs nedan:

Två gånger hade man kört igång acceptanstest trots att man egentligen var medveten om att kvaliteten på systemet inte var vad kunderna önskade (Start av acceptanstest var ett viktigt kriterium för grindpassage). Man hade t.ex. kodat in nya funktioner ända in i till den sista minuten på den sista sprinten vilket gjort det omöjligt för testarna att få till en vettig systemtest och nära nog ingen regressionstest. Acceptanstest-teamen, som var externa bolag men inom samma koncern, körde nära nog fast direkt och fick snällt vänta på att blockerande buggar löstes medan acceptansperioden så sakteliga tog slut (den måste ju också avslutas enligt tidplan för att få passera nästa grind). Resultatet blev en förlängd acceptanstest-period, försenad grindpassage, försenad produktionsstart och en missnöjd kund.

Jag blev ombedd att hjälpa till att förbättra situationen och vad jag kom fram till var att man ju kunde tillämpa sina ”Test entry criteria” lite hårdare för att verkligen säkerställa att systemet var färdigutvecklat. Kraven justerades lite och de vi ställde upp var:

• Alla krav skulle vara färdigutvecklade och systemtestade vilket gick att följa upp med ett verktyg (Jira i det här fallet).
• Max antal kvarvarande buggar.
• De integrationer mot omgivande system som fanns skulle vara testade och fungera.

Vad blev resultatet då ?
Man kan sammanfatta det hela med att tre saker hände:

1. Acceptanstest-fasen blev lite försenad då man trots ovanstående kriterier ändå kodat nya funktioner till sista minuten av sista sprinten. Acceptanstest-teamen verkade dock inte besvikna över detta utan mer nöjda med att man äntligen satsat lite mer på kvalitén
2. Det gnälldes lite hos projektledaren över att kriterierna var för hårda, ”nu kommer vi ju aldrig att kunna passera grinden…”
3. Det blev ingen större skillnad i mängden hittade buggar men däremot hittades de flesta i början på perioden istället för i slutet vilket gav utvecklarna en bättre chans att rätta dem. Dessutom hittades färre allvarliga buggar.

Så här såg fördelningen av antal hittade buggar ut innan den hårdare tillämpningen av ”Test entry criteria”

Och så här såg den ut efteråt:

Jag tror inte det gagnar någon att stenhårt tillämpa sina kriterier och vägra starta testningen om inte alla är 100% uppfyllda. Har man t.ex. någon enstaka bugg för mycket som inte påverkar testningen i alltför stor grad skall man givetvis köra igång och även om någon enstaka funktion inte är helt färdig. Det viktiga är att man har sina kriterier, att alla i projektet är införstådda med dem och att de utvärderas samt att man gör ett medvetet val efter dem. Egentligen inga konstigheter utan bara en liten förskjutning åt kvalité-hållet i den klassiska balansen av tid, kostnad och kvalité.

Är då test bara en aktivitet ?
Svaret är ju fortfarande givetvis nej även om det finns folk som vill tro det. Vi som jobbar dagligen med det vet ju bättre fast vi måste kanske också jobba med att nå ut med budskapet.