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?
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å:
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:
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.
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.
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.
Vem är Nisse?! 🙂
GQM är för mig personligen något nytt även om det mesta känns igen, att genom frågor komma fram till metoden, i detta fall mätetalen.
Sedan är det ju alltid roligt att se teknikhumorn i att ta fram metoder som förkortar något så att meningen blir intressant såsom SMART. Undrar om någon har en metod som oavsiktligt kan förkortas till DUMB.
Jag är inte så förtjust i SMARTa mål; jag tror att de kan missa det som är viktigast, vara för snäva och kortsiktiga.
Nja, då föredrar jag hellre mål som är vaga, pågående, motiverande, viktiga och pålitliga.
(Vague, Ongoing, Motivating, Important, Trustworthy)
Intressant Rikard. Kan du utveckla den metoden (vill du verkligen ha vaga mål?)? Rolig förkortning faktiskt. Vi har i ena hörnet SMART och i andra hörnet VOMIT. 🙂
Om vi utgår från att definitionen på kvalitet “Quality is value to some person that matters”, så blir ju tydliga mål kring kvalitet/testning väldigt svåra definiera. Att använda SMART känns inte som det enklaste.
Test progress är lurigt. Jag tycker det är så många saker vi gör, som testare, som inte vägs in i progresshanteringen. Jag gillar bättre idéen med en virtuell/verklig whiteboard som innehåller mindre metrics.
Är det bra progress om ett planerat testfall blir blockerat eller falerar? Är det kanske bättre med en Pass? Ska man undvika svåra tester för att visa progress snabbare? Jag skrev en notis kring detta här: http://thetesteye.com/blog/2009/10/growing-test-teams-progress/
Den enda metric som jag tycker säger någonting är då man tittar på buggar och då med fokus på Find Rate, Fix Rate, Resolve Rate och Close rate.
Martin, mindre mätetal på en whiteboard fungerar utmärkt inom projektet, i mindre projekt. Men de kommunicerar dåligt med icketekniska personer, personer som ofta har beslutande poster i organisationen/projektet. Dessutom går det att lära sig mycket av mätetal om vi använder samma mätetal i flera projekt i organisationen, speciellt estimeringen och tydande av trender underlättas mycket av det.
Håller med om att ha mätetal på antalet exekverade testfall är oftast väldigt intetsägande eller i värsta fall missvisande (kan dock fungera utmärkt i vissa fall), men att mäta på kravuppfyllnad ger nästan alltid mycket intressant data.
Att diskutera kvalitet och testning genom mätetal kan vara bra när det finns en kontext och någon som kan presentera vad de betyder.
T.ex en fallande kurva i buggstatistik kan betyda flera saker, det jag var med om vid ett tillfälle var att hela vår testgrupp var iväg på kurs. Någon tolkade statistiken som att vi faktiskt började närma oss målet, dvs att trenden hittade buggar gick ner. Så en skämtsam lösning på att få klar releasen är ju då att skicka QA på bio.
Men som sagt, jag håller med om att det är lättare att diskutera och presentera när man har mätetal. Utan mätetal så verkar man få mindre kraft gentemot ledning. Det betyder inte att jag behöver tycka om det.
Jag tror att det här med mål generellt och SMARTa mål specifikt rör sig om en blandning av ett språkligt fel och en önskan om att kunna göra allt till “metrics”.
Allt för att vi tror att vi gör bäst i att försöka prata samma språk som vi tror att personer i beslutsställning vill prata.
Om man tror att “icke-tekniska” personer tilltalas av att få ett par siffror (dolda i en graf) presenterade för sig, så är det som att säga: “Eftersom du ju har lite svårt för det tekniska så har vi översatt orden Klart, Inte riktigt klart, Duktig, Många, Problem, Krav, Nyskild, Få, Fixat, Slarvig, Testfall, Dyslektiker, Arbetsnarkoman, Rader kod, Onödigt komplex kod, Snårig konfiguration, Teknisk skuld, etc till siffror och dolt alltsammans i en graf som visar ett aggregerat värde där många av de ovan nämnda orden har vävts in på ett inte helt verklighetstroget sätt.”
Jag tycker att det är lite ojuste mot de så kallade icke-tekniska.
Vidare kan man jämföra om man har ett mål (Information Objective) i sin teststrategi som är: “Hitta (så många) allvarliga buggar (som möjligt)!” eller om man har ett mål som är: “Hitta 2 allvarliga buggar!”
Här gäller att det första målet inte är SMART, medan det andra kan vara det.
Är det skillnad på vilken typ av testning som man kommer att välja? Ja, det är mycket troligt.
Vilket skulle man som chef föredra och vilket skulle man som testare föredra?
Kanske skulle det visa sig att en testkunnig chef egentligen vill ha det första målet och en lat testare skulle föredra det andra målet?
Om man skulle byta ut ordet “mål” mot det svenska ordet “intention” så tror jag att man kommer lite närmare det ordet som vi egentligen borde vara ute efter. Detta eftersom de aktiviteter som vi gör inom programvaruutveckling inte går att direkt översätta till siffror (kvantitativa mått) utan snarare handlar om en komplex bild som kan tas fram vid en kvalitativ undersökning.
Det är ju lite trist att vi har översatt engelska ord till svenska och tagit det första bästa och sedan kört med det som om det vore helt självklart. Samma sak med requirement som vi till svenska har översatt med den hårdare varianten “krav” istället för “behov” som det i de allra flesta fall är den korrekta betydelsen; åtminstone när vi pratar om de krav (eller rättare sagt behov) som finns på ett mjukvaru-program.
En sista passus är att de mål som gäller på företagsnivå ofta har en tendens att hamna hos de på “golvet”; och då i någon sorts variant som antingen har blivit verklighetsfrämmande eller för förenklad.
Men är det inte rimligt att anta att det som görs av de på “golvet” istället ska bidra till att uppnå målen, dvs det kan räcka att jag i min roll som programmerare förbättrar mig på de områden som jag behöver förbättra för att på så sätt vara med och bidra till det SMARTa målet “75% nöjda kunder och ett snittbetyg på 4 av 5 vid den årliga undersökningen om programmets upplevda kvalitet…”.
Dvs här kan man ha ett mål i betydelsen av intention där man handlar i en viss anda i strävan att uppnå ett mätbart mål på en högre nivå.
Detta är kvalitetsmål på koncernnivå som sipprar ner till den enskilde. Men istället då för att mäta hur många buggar någon orsakar eller rapporterar så undersöker man vad det är för områden som någon behöver förbättra eller jobba på för att bidra till att uppnå målen (läs: kvalitetssäkring).
Sedan kan ju dessa mål föra andra positiva egenskaper med sig såsom en gemensam bild av vilken produkt det är som vi vill ta fram, etc.
“ger nästan alltid mycket intressant data.”
Där börjar vi närma oss den gyllene medelvägen.
Man kan ta fram siffror, titta på detaljerna och förstå helheten; göra en analys som hjälper vid beslut (utan att gömma beslutet bakom siffror.)
Att använda specifika mätetal som riktlinjer tror jag inte på.
I stället för att använda “produktkvalitet ska överstiga 0,92 för att kunna releasa”, tycker jag en beslutsfattare ska säga “jag förstår de allvarligaste bristerna i systemet, men tror att värdet av en release nu är större.”
Mått+analys är en helt annan sak än metrics.
Bengt; Mål är ett verktyg, som fungerar olika för olika personer; och det viktiga är att stimuleras till att göra saker som är bra för personen och företaget, inte att de finns nedskrivna på ett format som följer en fiffig förkortning.
Jag gillar vaga mål (bättre release än förra; bli en bättre testare; få större självinsikt), andra gillar specifika mål.