Jag gick i artikeln ”Nisse tog fram några grafer, kika på dem!”här på TestZonen igenom ett exempel på hur jag i ett projekt tog fram två mätetal med Goal-Question-Metrics metodiken.
Exemplet började med att jag i ett projekt på ett tydligt sätt ville visa testningens progress för projektets styrgrupp. Eftersom testnings progressen var långsam på grund av väldigt mycket buggar i testobjektet ville jag naturligtvis även synliggöra kavliten på testobjektet för att försvara den låga testprogressen. De resulterade i målen, frågorna och mätningarna du ser nedan.
Det jag inte gick igenom i den föregående artikeln är hur du presenterar dessa mätetal på ett vettigt sätt anpassat för den tänkta målgruppen. För testledaren i projektet så är det förmodligen intresantast att se graferna för G1-Q1, G1-Q2 osv. Medans projektägaren förmodligen bar vill se ett aggregerat resultat som bara säger bra eller dåligt. För att komma dit så måste förstås bestämma vad som är bra och vad som är dåligt samt aggregera och prioritera de frågor som hör till samma mål. Men vi tar en sak i taget och börjar med att visa hur graferna för frågerna till Q1 ser ut i vårat exempel.
Dessa grafer är ju faktiskt något som testledaren och övriga projekt medlemmar kan ha stor nytta av och agera utefter. Men hur vet vi vad som är bra och vad som är dåligt? Det finns förstås inget givet svar på vad som är bra och vad som är dåligt, men jag brukar utfrån erfarenhet och branchstandarder göra ett förslag på vad som är bra, normalt och dåligt. Detta förslag presenterar jag sedan för hela projektet i en workshop, under denna workshop har alla sedan möjlighet att tycka till om kriterierna. Dessa kriterier förfinas och justeras sedan löpande vertefter projektet och organisationen skapar sig mera erfarenhet. I vårat exempel såg kriterierna ut såhär för G2-Q2-M1:
Värde är det som vi får från mätningen, kriterium är etiketen på intervallen av värde och numeriskt kriterium är en siffer baserad etiket på värdet som används vid prioriteringen mellan de olika frågorna och mätningarna.
Prioriteringen byggde jag i detta fall på att alla frågor får en prioritets siffra från 0-100, där hundra är högsta prio. Samtliga ingående frågor till ett mål måste dock alltid tillsammans ha det summerade värdet 100. Sedan multipliceras frågans prioritets värde med frågans nuvarande nummeriska kriterium, detta upprepas sedan för samtliga frågor och de erhållna värderna summeras. Detta summerade värde geomförs sedan med maxvärdet för målet och en procentsats på måluppfyllnaden fås. Se bilden nedan så klarnar det förhoppningsvis.
Vi har nu ett procentuellt värde på uppfyllanden av målet, men även här måste vi vet vad som är bra och vad som är dåligt. Så vi sätter även här upp antaganden utefter erfarehet och bollar dessa med projektet. Dessa kriterier brukar jag dock inte ändra om de visar sig vara felaktiga utan jag brukar istället justera in kriterierna på frågorna, detta för att undvika att skapa förvirring vid presentationen av siffrorna. I vårat exempel hamnade värderna så här:
Värde är det som vi får från mätningen, kriterium är etiketen på intervallen av värde och numeriskt kriterium är en siffer baserad etiket på värdet som används vid prioriteringen mellan de olika frågorna och mätningarna.
Prioriteringen byggde jag i detta fall på att alla frågor får en prioritets sifra från 0-100, där hundra är högsta prio. Samtliga ingående frågor till ett mål måste dock alltid tillsammans ha det summerade värdet 100. Sedan multipliceras frågans prioritets värde med frågans nuvarande nummeriska kriterium, detta upprepas sedan för samtliga frågor och de erhållna värderna summeras. Detta summerade värde genomförs sedan med maxfärdet för målet och en procentsats på mål uppfyllnaden fås. Se bilden nedan så klarnar det förhoppningsvis.
Vi har nu ett procentuellt värde på uppfyllanden av målet, men även här måste vi vet vad som är bra och vad som är dåligt. Så vi sätter även här upp antaganden utefter erfarehet och bollar dessa med projektet. Dessa kriterier brukar jag dock inte ändra om de visar sig vara felaktiga utan jag brukar istället justera in kriterierna på frågorna, detta för att undvika att skapa förvirring vid presentationen av siffrorna. Bilden nedan visar värderna i vårat exempel.
Nu är vi äntligen redo att presentera svartet på frågorna för projektägare och andra intresenter som vill ha en lättfattlig bild av måluppfyllnaden. Det är dock mycket viktigt att inte dölja underliggande data om intresenten vill se den, det skapar bara onödig misstro mot mätetalet. Se också alltid till att kommentera konstiga avvikelser eller oväntade vären på dina mätetal så att ingen dra förhastade slutsatser. Att det inte hittades några fel förra veckan, behöver ju exempelvis inte betyda att kvaliten höjts utan kan bero på att testgrupperingen var sjuka osv. osv. Det är också på grund av att det är så lätt att dra förhastade slutsatser som man skall se till att mätetalen bygger på flera frågor som kompleterar varandra.
Nu är vi i mål när det gäller att ta fram, prioritera och presentera våra mätetal. Det är vi nu i vårat exmepel går vidare med är att omvandla dessa mätetal till styrtal. Syftet med ett styrtal är att värderna från mätetalet och de underliggande frågorna ligger till grund för att prentera ett förslag på hur det är lämpligt att agera vid nuvarande staus på mätetalen. När vi i exmplet tog fram instuktionerna till styrtalen så gjorde vi helt enkelt en matris med de olika kombinationerna av kriterier i de underliggande frågorna. Sedan dokumneterade vi lämplig åtgärd till var och en av kombinationerna. De föreslagna åtgärderna kompleterades sedan med checklistor som användes för att utföra åtgärden. Dessa checklistor blir naturlitvis förlegade efter ett tag och behöver regelbundet underhållas och justeras.
I nästa artikel om mätetal tänkte jag gå igenom några av de nytigaste mätetalen och resonera lite om hur mätetal lätast förs in i organisationen.
Frågan är hur mycket energi man ska lägga på mätetal?
Tom DeMarco, som bl.a har varit med och skrivit den lysande boken Peopleware, har tidigare skrivit boken “Controlling Software Projects: Management, Measurement, and Estimation”. I en relativt ny artikel ifrågasätter han sina egna teorier. Ni hittar hans artikel här:
http://www.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf
Kan vara bra att se andra sidan av myntet. Det finns flera bloggarna som skriver om den negativa sidan av mätetal, läs på innan ni bestämmer er vad som är bra och dåligt samt vad som passar er.
Martin, en bra läsvärd artikel du länkade till. Jag håller med artikel författaren i princip, om man försöker implementera allt vad som han skriver i boken ” Controlling Software Projects: Management, Measurement, and Estimation ” så skulle det bara leda till en gigantiskt tvångströja över projektet och organisationen. För att inte tala om vilka resurser det skulle sluka att införa, underhålla och följa upp ett så stort antal komplicerade metrics.
Nä så här i Sverige kan man ju lätt falla i frestelsen att säga att lagom är bäst, men inte heller det är sant. Utan det gäller som jag i artiklarna skrivit, det gäller att ha ett syfte med mätningen, det skall finnas ett behov. Annars är det inte värt att mäta.
Jonas- jag har läst båda dina artiklar. Det lilla jag kan om GQM så verkar du följa den processen. Dock så gör du i min mening ett väldigt allvarligt misstag. Du försöker beskriva någonting kvalitativt med en kvantitativ metod. Kvalite är inget absolutbegrepp. När vi försöker oss på att sätta en siffra på kvalite så är vi ute på mycket farligt vatten. En produkt som har en kvalite på 65% säger mig inte någonting och då vet jag ändå hur du fått fram siffran. Att bedöma kvaliten beroende på hur många fel i förhållande till exekverande testfall är direkt vilseledande och säger inte ett dugg om produktens kvalite. Många söker enkla vägar att förmedla kvalitativ information på och att kvantifiera det i siffror är ett typiskt sådant beteende. Jag tycker att hela din inledning på artikeln ” Nisse tog fram några gafer” var väldigt bra skriven och du prickar ett väldigt relevant problem. Jag tycker dock att din lösning tenderar till att förstärka problematiken istället för att hjälpa.
Vi måste inom testvärlden komma ifrån att rapportera vår information i form av siffror. Detta är inte representativ för den information vi tillandahåller och testningen tenderar till att styra mot att uppfylla våra KPIer iställer för att fokusera på att test produkten.
Vi måste börja beskriva vår information diskriptivt. Den största delen information vi tar fram inom test tenderar mer att ligga åt det empirisk-hollistiska (kvalitativa) hållet än det rational-atomismistisk (matematiskt härledbara). Vi vet inte från början exakt vilka resultat som är tänkbara. Detta kräver en följsamhet gentemot det man utforskar. Valet av metod kanske får ändras under projektets gång. Det man vill studera handlar ofta om kvaliteter och inte om antal, fördelningar eller exakta mätvärden. Resultatet kan vara nya aspekter på ett problem eller försvar av de värden som finns i produkten.
Därför kan inte vår rapportering bestå av ett antal siffror utan behöver vara en beskrivning av de observationer, angräppsätt, analyser samt slutsattser vi utfört.
Vi är väl inte här för att lura vår omvärld?
Henrik, jag förstår vad du vill komma åt, men ibland måste man vara lite context styrd och leverera det som beslutsfattare runt projektet vill ha. Att då göra det på en så lätt begriplig form som möjligt ser jag som självklart. De styrande i detta stora projekt ( med en testbudget på ca 20miljoner/år) , skulle aldrig godta att jag endast helt subjektivt rapporterade ”en beskrivning av de observationer, angräppsätt, analyser samt slutsatser vi utfört” utan att backa upp detta med några siffror. Då endast subjektiva analyser inte räcker eller accepteras tycker jag aggregerade mätpunkter är bra mycket mera rättvisande än att bara redovisa mätpunkterna rakt upp och ner. Dessa ögonblicks bilder kompletterades i just detta exempel givetvis även med mera subjektiva rapporter i löptext som beskrev känsla och analys av nuläge och framtid.
Nu var detta ett exempel för att förstå metoden, men skall vi särskåda detta så tycker jag att den största bristen är att det blir fokus på antalet exekverade testfall istället för kravtäckning. Detta berodde i detta fall på att det endast fanns klart brisfälliga krav och mycket liten tillgång till slutanvändare trots att det var ett DSDM projekt.
Jonas, jag ser inget i dina två artiklar som passar in på din beskrivning “…ibland måste man vara lite context styrd och leverera det som beslutsfattare runt projektet vill ha.”
För det första så antyder du i din första artikel att kunderna inte riktigt vet vad de vill ha presenterat; och i nästkommande stycke skriver du att en person sa att det var upp till dig att välja mätvärden men att denne person hade en vink om vad den ville se.
Om du med detta menar att du är “lite styrd” av rådande kontext så må det vara hänt, men du missar ju de viktiga följdfrågorna till den andre personen när denne sa:
“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.”
Några av de naturliga följdfrågorna är ju då:
Vad menar du med testobjektets kvalitet?
Vad menar du med testobjektets kvalitet utifrån ett affärsflödes-perspektiv?
Vilken information är projektledningen intresserad av?
Vilken information är projektledningens ledning intresserad av?
Det vore nästan helt otroligt om det inte visar sig att svaren på frågorna ovan säger oss att vi som testgrupp inte kan bidra med några vettiga siffror, aggregerade eller inte, för att de kvantitativa mått som vi kan producera inte har någon koppling till frågorna.
Även om du har gjort GQM enligt boken, så är det ju ingen som har något egentligt intresse i de tolkningar av målen som du har tagit fram; och framför allt så är det bluff hur du kommer fram till att de siffrorna verkligen visar det som står.
Jag håller helt med Henrik Anderssons när han säger “Våra intresenter är inte experter på test och vet inte alltid vad vi har att erbjuda. Det är vår uppgift att förstå vad dom vill ha och att lära dom förstå den information vi levererar. Det är en stor skillnad mellan vad man uppfattar och vad man begär”
Att blint leverera det som beslutsfattare vill, även om det innebär oärlig vilseledande information, skulle vara context drivet håller jag verkligen inte med om. Det är väldigt få contexter då ett sådant beteende skulle vara försvarbart. Det är snarare oetiskt.
Våra intresenter är inte experter på test och vet inte alltid vad vi har att erbjuda. Det är vår uppgift att förstå vad dom vill ha och att lära dom förstå den information vi levererar. Det är en stor skillnad mellan vad man uppfattar och vad man begär.
Jag förstår vad du menar med att vi ofta förväntas att rapportera på ett visst sätt, speciellt i större projekt. Jag har tidigare under många år fallit in i ledet och gjort dessa misstag. Efter att känt mig oärlig och inte mått bra av detta kom jag till insikten att det är inte rätt att göra så.
Vår uppgift är inte att tillhanda hålla vilseledande och oärlig information och om detta frågas av mig så förklarar jag att det inte kommer hända och försöker finna vad det egentligen är dom är ute efter. Har vi inte förståelse för varandra så går jag helt enkelt där ifrån. Jag är inte här för att lura och bedra någon då jag är övertygad om att det skulle slå tillbaka dubbelt så hårt mot mig längden. För mig handlar det om integritet.
Jag säger inte att det är så att du varit oärlig i ditt projekt. Detta kan jag inte veta då jag inte har tillräckligt med underlag för att bedöma det. Jag argumenterar endast baserat på den data som finns tillgänglig för mig.
Jag ser det dock hända väldigt ofta i projekt och på företag så detta är i min mening ett stort problem i vår bransch.
Att rapportera ”en beskrivning av de observationer, angräppsätt, analyser samt slutsatser vi utfört” behöver inte betyda att lägga fram långa uppsattser med text. Även det materialet kan aggregeras, visualiseras och det kan ingå mätdata om det skulle vara relevant.
Men om det är som du skriver att det inte accepteras. Då har vi ett större problem i organisationen som inte längre handlar om vad vi rapporterar.
”tycker jag aggregerade mätpunkter är bra mycket mera rättvisande än att bara redovisa mätpunkterna rakt upp och ner.”
Jag tycker inte det spelar någon roll om dom är aggregerade eller ej om mätpunkterna i sig är orelevanta i grunden inte hör hemma i en rapport.
Vår främsta uppgift är inte att mäta utan att utvärdera. Då bör vi inte främst bygga vår rapportering på mätetal.
Du beskriver GQM metoden bra men att använda denna metod skulle leda till att vår chef förstår siffrorna eller att mätetalen skulle avspegla helheten är jag klart tveksam till.
För ett gäng år sen var jag inne på att man behövde ha siffror som backade upp beslut och rekommendationer.
Jag gillade inte att testrapporternas sammanfattning baserades på maggropskänsla.
Nuförtiden är jag tillbaka på maggropskänsla, eller snarare: subjektiva bedömningar baserade på kunskap om detaljerna, erfarenhet, hörsägen med mera.
En intressant mening i artikeln är:
“Se också alltid till att kommentera konstiga avvikelser eller oväntade vären på dina mätetal så att ingen dra förhastade slutsatser”
Om graferna ser bra ut, men vi vet om att det finns riktigt allvarliga brister, så skulle jag tro att man går mer på personernas slutsatser, än på uppfyllandet av metrics.
Så vad ska vi med dessa metrics till?
Om det är så att de är till för de tillfällen då ingen har kunskap om detaljerna, så har man nog allvarligare problem än sina metrics…
Eller kan det vara som så att siffrorna betydelse är att det ska se ut som att man har bra koll på läget?
Jag tror att bakgrunden är att metrics funkar bra i tillverkningsindustrin, där man försöker tillverka samma sak många gånger med bibehållen kvalitet.
Sen har det förts över till programvara utan att fundera tillräckligt mycket på skillnader i ex. komplexitet och kundnytta.
/Rikard
“Om nåt ser bra ut, så är det inte säkert att det är det.
Om nåt ser dåligt ut, så är det ofta dåligt.”
Rikard, mätetalen är ständigt uppdaterade och ständigt tillgängliga för intressenter. Muntlig rapportering som så klart är effektivast och mest rättvisande blir snart inaktuell och irrelevant samt har begränsad spridning vilket blir ett problem i störe projekt. Mätetalen hjälper mig även att vara objektiv i mina utlåtanden om hur testerna går, jag tänderar annars att förblindas av de problem områden jag jobbar mestadels med just då. Det kan finnas andra sidor av testprojeket som går lysande, dessa glömmer jag ibland omedvetet bort.
“Om graferna ser bra ut, men vi vet om att det finns riktigt allvarliga brister, så skulle jag tro att man går mer på personernas slutsatser, än på uppfyllandet av metrics.” Det håller jag naturligtvis med om, men om du har den situationen så har du brister i dina mätetal, om de är uppsatta för att visa just detta.
Det känns som det finns en tendens att försöka likställa rapporteringen från små projekt med några få testare där man alltid har detalj kontroll på allt, med rapporteringen från större projekt med ett stort antal testare där man omöjligt har detalj insikt i allt. Sedan kan man fundera på hur effektiva dessa stora projekt är, men det är en helt annan historia.
Och ja, mätetalen är bara ett komplement till vanlig hederlig statusrapportering, men i mitt tycke så fyller mätetalen väl sitt syfte i större projekt.
ag glömde att passa på att tacka för alla kommentarer på artikeln, detta ger den verkligen mervärde och får en att tänka runt ämnet några varv till. Kommentarerna påvisar även att man bör tänke efter både en och två gånger på vad syftet med mätetalen är. Tack!
“Det känns som det finns en tendens att försöka likställa rapporteringen från små projekt med några få testare där man alltid har detalj kontroll på allt, med rapporteringen från större projekt med ett stort antal testare där man omöjligt har detalj insikt i allt.”
Det kan kanske tyckas så men:
Kan bara prata för min egen del och då stämmer det inte alls. Jag skulle påstå att en stor del av min erfarenhet kommer från stora projekt och organisationer.
En liten historia:
För ett par år sedan var jag testledare för ett test team på 10 pers. Vi var ett av säkert 20 test team. Vi körde Exploratory test de andra exekverade fördefinierade testfall på traditionellt vis. När vi startade upp ville “projektet” att vi skulle rapportera på ett motsvarande sätt som de andra teamen (baserat på siffror). Jag förklarade för dom att det inte var i mitt intresse att vilseleda och att dom skulle gå miste om väldigt värdefull information. Vi som enda testteam satte upp vår egen rapporterings struktur och de andra fortsatte som vanligt. Vi fick förklara och utbilda mottagarna av våra rapporter men ganska snabbt såg våra intressenter värdet i det vi levererade och fler och fler ville över tiden ta del av våra resultat.
Detta har i min mening absolut inget med storlek på projekt att göra. Det är kunskap, utbildning och förståelse som är avgörande. Mätetalen fyller inte varken mer eller mindre betydelse i stora eller små projekt. Det handlar om mätetalens relevans i den kontext dom ska verka i. Där du i min menig förespråkar en högst tvivelaktigt bruk av mätvärden.
“detalj kontroll på allt, med rapporteringen från större projekt med ett stort antal testare där man omöjligt har detalj insikt i allt.”
Jag får en viss känsla av att du ser det som att om man inte använder mätetal så måste man i text beskriva varje steg,tanke och observation man gör. Så är inte fallet man kan summera och aggregera resultat utan att främst använda sig att ett trubbigt verktyg som mätvärde.
“Jag får en viss känsla av att du ser det som att om man inte använder mätetal så måste man i text beskriva varje steg,tanke och observation man gör. Så är inte fallet man kan summera och aggregera resultat utan att främst använda sig att ett trubbigt verktyg som mätvärde.”
– Då har du missuppfattat mig helt, jag aggregerar givetvis resultat, varken jag använder mätetal eller inte. Jag är absolut ingen förespråkare för “pratiga”, överdetaljerade långa rapporter, tvärt om så håller jag dem till ett minimum oavsätt om jag tar med mätetal eller ej i rapporten/rapporteringen.
Kul med engagemanget kring mätdata från testledare. Jag som i alla personlighetstester klassats som analytisk eller analytisk, analytisk gillar att följa läget status och progressmässigt i siffror och grafer/diagram. I de uppdrag jag inte haft tillgång till kraftfulla verktyg för detta (Ex. Quality Center) har jag försökt få fram detta med Excel.
Intresset och värdet av att visuellt visa hur långt man kommit eller hur många defects man hittats fördelat på severity eller annat, brukar man kunna fånga projektets intresse av genom att vara aktiv och regelbundet skicka ut mail, beskriva läget kortfattat på projektmöten eller sätta upp färgglada bilder på väggarna. Vi vill ju se oss som den proffession som ska ge “Project Intelligence” till beslutsfattare i ledningen.
Men nästan aldrig har beställare eller styrgrupper varit engagerade kravställare på vilken information och vilka mätdata man vill ha.
Man utnyttjar därmed inte kraften som finns för att styra företaget eller projektet.
Det är som att prenumerera på en tidning med 5 bilagor och bara använda och läsa en av dom