Nisse tog fram några grafer, kika på dem!

Nisse tog fram några grafer, kika på dem!

När man är ute i olika testorganisationer för att utveckla processer med tillhörande verktyg, får man oftast höra ”Vi vill ha standard rapporter och standard mätetal implementerade i verktyget”. ”Vad är syftet med rapporteringen och vad skall rapporterna innehålla” och ”Vad vill ni veta med hjälp av mätetalen och vilka mätetal vill ni ha ut”, är ju då de skjälvklara motfrågorna jag ställer. Svaret på den frågan är oftast ”äuum vet inte riktigt, men Nisse tog fram några grafer i ett projekt som såg bra ut, kika på dem” eller så får man höra ”ledningen vill veta hur många testfall vi har exekverat”.

Men som tur är finns det undantag och idag pratade jag till min stora glädje med ett sådant undantag. På frågan ”vad vill du att rapporterna skall innehålla och vilka mätetal vill ni ha ut” svarade detta undantag som den naturligaste sak i världen ”Bestäm du vad rapporten skall innehålla och vilka mätetal som är nödvändiga att ta ut. Jag vet bara att jag vill se trender från testarbetets progress och på testobjektets kvalitet utifrån ett affärsflödes perspektiv. Trender som jag kan styra arbetet efter och använda i rapporteringen till projektledningen”. Efter ett sådant svar blir det så uppenbart att det stora flertalet inte fokuserar på vad man vill veta, utan på bocka av standardrapporter och mätetal på testmognads checklistan.

Det är just fokuset på vad vill vi veta eller snarare vad är målet med detta mätetal som gör att jag föredrar att arbeta med oflashiga gamla Goal/Question/Metric (GQM) metoden med röter från 70-talet för att få fram mätetal och rapporter. GQM fokuserar helt på vad målet är och använder sedan mätningen som ett sätt att besvara om målet är uppfyllt eller inte. Detta tvingar organisationen som tar fram mätetalen att fokusera på det viktiga, vad är syftet med att mäta? Eller med andra ord, vad vill vi veta?

image001

För att lättare få acceptans för GQM metoden brukar jag visa ett konkret, men kanske inte helt renlärigt exempel på hur jag tidigare har använt metoden för att definera mätetal i ett större projekt. Detta exempel tänkte jag nu återge i här i korthet.

Det hela började med att jag på ett tydligt sätt ville visa testningens progress för projektets styrgrupp. Eftersom testningsprogressen var långsam på grund av väldigt mycket buggar i testobjektet ville jag naturligtvis även synliggöra kvaliten på testobjektet för att försvara den låga testprogressen. När man använder sig av GQM metoden så börjar man med att definera målen för mätningen, alltså, vad vill vi veta?

Om vi funderar lite runt målen så inser vi att de redan är satta. Visa testningens progress och visa testobjektets kvalitet. Jag formulerade om dessa mål och såg till att de är någorlunda SMARTA, alltså  formulerade enligt SMART: specifika, mätbara, accepterade, realistiska och tidsbestämda. Målen blev då:

G627

Nu när vi har definierat våra mål så är det dags att ställa de frågor som behövs för att kunna besvara om vi uppnår målen eller inte. Oftast så behövs det ett flertal frågor per mål och det är absolut att rekommendera då det ökar träffsäkerheten för mätetalet. Jag valde i detta exempel att ställa tre frågor per mål, jag provade först med ett större antal frågor men införandet blev då för tidskrävande och komplext för detta projekt. Frågorna jag ställde var dessa:

Q627

För att sedan kunna besvara dessa frågor så behöver nödvändiga mätetal identifieras. Något jag verkligen försökte tänka på när det gäller mätetal är att även de skall vara formulerade enligt SMART: specifika, mätbara, accepterade, realistiska och tidsbestämda.

M627

Sådär nu har vi identifierat mål, frågor och mätetal som hjälper oss att samla information för att på ett tydligt sätt visa testningens progress för projektets styrgrupp. Det som återstår är att bearbeta och presentera informationen på ett tydligt sätt anpassat efter målgruppen. Nedan ser vi hur vi berbetat datat för G2-Q2 samt en graf över resultatet.

G2627

Värdena ovan och grafen hjälper förmodligen testaren och testledaren, men inte en styrgrupp. Därför bör man förfina och aggregera datat vidare. Mer om detta i en kommande artikel här på TestZonen.

About Jonas

Jonas Hermansson VD, Krav och testnörd på Inceptive Stockholm Grundare av TestZonen.se. Tidigare medlem i Styrelsen SAST. Medlem i Styrelsen DSDM konsortiet. Jonas började arbeta med kvalitetssäkring och test 1994 och är specialiserad på testorganisation, testprocess och testverktyg. Han har bland annat arbetat som testledare, testchef, testautomatiserare, lärare och mentor samt med krav och verktygsupphandling.