Presentera mål och mätresultat Test Appeal Jag har kallat det här lilla föredraget för Test Appeal. Bakgrunden är den att många tycker test verkar vara något tråkigt medan en del andra ej håller med om detta. För att de som upplever det som tråkigt skall uppfatta det som lite roligare så tror jag det är viktigt att vi som håller på med test är duktiga på att kommunicera vad vi gör. Och när vi kommunicerar vad vi gör så gör vi ju det många gånger med hjälp av de resultat som testningen resulterat i. Därför tror jag det är ett bra område att fokusera på när vi ska göra testningen lite mer tilltalande för vår omgivning. Dessutom tror jag att det finns mycket att vinna för testdisciplinen generellt genom att presentera resultaten på ett tilltalande sätt. Om projektledare, styrgrupper, beställare och kunder blir mer medvetna om vad testarna egentligen gör så tror jag också att förståelsen för test kommer att öka – och då också viljan att investera på området – och det finns det nog många testare som skulle uppskatta. Presentera mål och mätresultat

E-post: anders.timmeras@sigma.se Anders Timmerås Arbetade inom kvalitetsområdet under 90-talet Har jobbat med test sedan 1995, sedan 1999 som konsult Roller: Testledare, Teststrateg, Testdesigner, Utbildare i test E-post: anders.timmeras@sigma.se Tel: 0703-79 12 39

Agenda Inledning/Exempel Testprogress Felrapportering Hur kommer jag igång?

Agenda Inledning/Exempel Testprogress Felrapportering Hur kommer jag igång?

Citat ”Att mäta är att veta” - grekiskt talesätt ”Den som inte kan mäta sina resultat, vet intet” – Einstein “You cannot control what you cannot measure.” - Tom DeMarco (Software Engineer) Att det är viktigt att mäta är ingen nyhet. Det som eventuellt har förändrats en aning är syftet med varför man mäter. Vi mäter inte bara för att veta idag utan även för att på så sätt få medel att kunna kontrollera och styra (den iterativa) utvecklingen. I stora projekt behöver vi dessutom kunna sammanställa stora mängder mätdata eller testdata på ett korrekt sätt för att kunna veta/kontrollera/styra.

Vad kan vi mäta? Produkt Processer Resurser Projekt Storlek Komplexitet Kvalitet (Testprogress / felrapporter) Processer Resurser Projekt Omfattning Det här föredraget omfattar mätning av produktens (systemets) kvalitet i form av testprogress och defekter i huvudsak vid sena testfaser (systemtest). Begränsningar De mätningar som kommer att diskuteras vid det här föredraget är i huvudsak mätningar på slutresultat. För att fullt ut kunna kontrollera behöver man även mäta tidigt i utvecklingskedjan (Marcus?).

Vad kan vi mäta? Produkt Processer Resurser Projekt Storlek Komplexitet Kvalitet (Testprogress/Felrapportering) Processer Resurser Projekt Omfattning Det här föredraget omfattar mätning av produktens (systemets) kvalitet i form av testprogress och defekter i huvudsak vid sena testfaser (systemtest). Begränsningar De mätningar som kommer att diskuteras vid det här föredraget är i huvudsak mätningar på slutresultat avseende testprogress och felrapportering. För att fullt ut kunna kontrollera behöver man även mäta tidigt i utvecklingskedjan (Marcus?). Syfte Syftet är att visa några grunder och några exempel och att ni som inte mäter och presenterar era testresultat så mycket som ni skulle önska får lite inspiration att börja / gå vidare med detta.

Vad kan vi mäta? Produkt Processer Resurser Projekt Storlek Komplexitet Kvalitet (Testprogress/Felrapportering) Processer Resurser Projekt Omfattning Det här föredraget omfattar mätning av produktens (systemets) kvalitet i form av testprogress och defekter i huvudsak vid sena testfaser (systemtest). Begränsningar De mätningar som kommer att diskuteras vid det här föredraget är i huvudsak mätningar på slutresultat avseende testprogress och felrapportering. För att fullt ut kunna kontrollera behöver man även mäta tidigt i utvecklingskedjan (Marcus?). Syfte Syftet är att visa några grunder och några exempel och att ni som inte mäter och presenterar era testresultat så mycket som ni skulle önska får lite inspiration att börja / gå vidare med detta.

Målgrupp för mätresultaten? Projektledare Projektmedlemmar Styrgrupp Programansvarig Chefer på olika nivåer (Beställare/Kund) Beställare/kund beroende på transparens i organisationen/samarbetet. Fråga: -Hur många av er här inne befinner er i någon av ovanstående grupper? -Hur många av er är Testledare med rapporteringsansvar? -Hur många av er vill bli testledare med rapporteringsansvar?

Testrapportering – exempel Testrapport – Program X, Version 0.45 55 testfall har körts 34 tester var OK 14 tester var inte OK 17 felrapporter skrevs vid denna testomgången 14 felrapporter rättade från förra testomgången Vad är det som är bra med följande exempel på presentation av testresultat? Vad är det som är mindre bra med följande exempel på presentation av testresultat? Mycket information – man har lyckats fylla en hel sida, men ändå är det väldigt många frågor som står obesvarade. Om 55 körts och 34=OK & 14=NOK, hur gick det med de återstående 7? (Vad hände med de återstående 7? – Otydliga krav?) Hur många testfall skulle ha körts vid det här tillfället? (TF enligt plan?) Hur många testfall har körts jämfört med hur många som ska köras i hela projektet? (TF jämfört med totalt?) Om det finns tester som inte kördes – hur viktiga eller oviktiga var dom? (Ej körda TF – Prioritet?) Hur många felrapporter finns det totalt som ej är lösta? (Hur många olösta felrapporter?) Hur många felrapporter har testats men visade sig ej vara lösta på ett tillfredsställande sätt? (Antal rättade felrapporter=Failed?) Hur många av de nya respektive lösta felrapporterna var allvarliga? (Allvarlighetsgrad för nya/rättade felrapporter?) Hur många var mindre allvarliga? Hur ser den förmodade trenden ut framåt i tiden? I många projekt nöjer sig projektledare m.fl. med den här typen av rapportering, trots att den låter många frågor stå obesvarade.

Kommunicera dina testresultat! En bild säger mer än 1000 ord En tabell säger mer än 100 ord Ett diagram säger mer än 1000 ord / siffror / tabellceller

Agenda Inledning/Exempel Testprogress Felrapportering Hur kommer jag igång?

S-kurvan är en utveckling över tester som fått OK (alt S-kurvan är en utveckling över tester som fått OK (alt. Lösta felrapporter) som enligt studier alltid beskriver formen av ett S (något framåtlutat/utdraget). Genom att studera utvecklingen över tester som fått OK tidigt i projektet så kan man på detta sätt se var man kommer hamna tidsmässigt om projektet fortgår på samma sätt som hittills. Viktigt att notera när man bedömer projektet utifrån S-kurvan är att kurvans utseende påverkas av ett projekts indelning i faser och hur mycket som levereras inom olika områden vid olika tidpunkter. Genom att presentera våra mätresultat på det här sättet så har vi kommit milsvida jämfört med det inledande exemplet med siffror. Låt oss nu titta på hur vi kan förbättra denna presentation ytterligare.

Kommentar: Vilka frågor föder denna grafen. Vad innebär t. ex Kommentar: Vilka frågor föder denna grafen? Vad innebär t.ex. diffen mellan implemented och Run? Genom att lägga till planen för när funktionsleveranser ska komma till testavdelningen samt när de faktiskt gör det så har man adderat en hel del information till sin rapportering som gör en räcka med frågor onödiga att ställa. Här kan vi exempelvis se att gapet mellan antalet körda testfall och den levererade funktionaliteten sällan är särskilt stort (vilket man kan förledas att tro när man ser den förra bilden. Hur många testfall skulle ha körts vid det här tillfället? - Besvarad Hur många testfall har körts jämfört med hur många som ska köras i hela projektet? - Besvarad Om det finns tester som inte kördes – hur viktiga eller oviktiga var dom? – Ej besvarad Hur många felrapporter finns det totalt som ej är lösta? – Se nästa slide Hur många felrapporter har testats men visade sig ej vara lösta på ett tillfredsställande sätt? – Se nästa slide Hur många av de nya respektive lösta felrapporterna var allvarliga? - Se nästa slide Hur många var mindre allvarliga? - Se nästa slide

Exempel på vad ett av de marknadsledande verktygen klarar: Mercury (HP) Quality Center

Exempel på vad ett av de marknadsledande verktygen klarar: Mercury (HP) Quality Center Klarar i princip att producera denna rapport Tips Glöm ej att aktivera ”history” Planned och implemented ej default Exportera till Excel

Verktyg – fördelar / nackdelar Dynamiskt Snabbt att komma igång Många olika rapporter Exportera till Excel Nackdelar Anpassning inte alltid helt enkelt Tolkningsproblem Buggar Tveksam ”Test Appeal” QC: Fördelar: -Dynamiskt skapas grafer utifrån pinfärska data. Man kan välja att anpassa en rapport lite från gång till gång. -Det går snabbt att komma igång då det finns några olika basgrafer att utgå ifrån som man sedan anpassar lite efter egna önskemål med hjälp av Wizards. -Basgraferna tillsammans med lite fantasi ger ganska många olika rapporter med ganska liten arbetsinsats. -Det finns möjlighet att exportera till Excel om man inte är helt nöjd med det grafiska utseendet (det finns även vissa möjligheter att påverka utseendet direkt i verktyget). Nackdelar: -Anpassningar som man ibland vill göra kan kräva att man har tänkt efter före projektets start och lagt till nödvändiga fält etc. i de olika formulären. -Det kan ibland vara svårt att tolka vad verktyget egentligen gör vid olika val i Wizarden (Ref: Mercury’s representant i Sverige). -Vissa versioner av verktyget har haft buggar inom detta området vilket kan vilseleda organisationen. -Utseendet på graferna kan ju diskuteras. Det går dock att exportera till Excel som sagt.

Om man nu har gjort dessa mätningar, eller för all del dessa, hur vet man att resultaten är rättvisande?

Hur vet vi att de presenterade resultaten är rättvisande? Koll på testcasen Koll på riskerna med olika krav Koll på vikten av olika krav = känsla om det är OK / NOK De resultat vi nu presenterat i föregående graf kan vara missvisande av en rad orsaker: Vissa testdesigners / test analysts kanske har en förkärlek att dela in sina testcase i väldigt små delar medan andra bakar samman sina testcase till långa flöden. Vissa krav kanske är beskaffade på ett sådant sätt att de av naturliga skäl testas med ett stort antal enkla testfall medan andra testas med ett fåtal omfattande testfall. Vissa krav kanske är mycket mer riskfyllda att införa än andra. Mer fokus måste kanske då läggas på dessa (om de är tillräckligt viktiga). Vissa krav kanske är mycket viktigare än andra. Om du har koll på allt detta kanske du kan säga huruvida dina resultat är missvisande eller inte. Om resultaten är missvisande eller om du är osäker skulle jag rekommendera att mäta direkt på de viktade kraven, eller alternativt vikta testfallen utifrån kravens viktning. VARNING!

Risker med missvisande testresultat Om bristande rapporteringskvalitet är okänd: Felaktiga beslut tas Om bristande rapporteringskvalitet blir känd: Testresultaten går ej att använda Svårt att rapportera i framtiden Exempel på felaktiga beslut som tas vid missvisande testresultat där man inte känner till att de är missvisande: -Man sätter in åtgärder på fel områden. -Man sätter inte in åtgärder när det behövs. -Man sätter in åtgärder när det inte behövs. Oavsiktlig och felaktig/olycklig styrning som bli resultat av missvisande testresultat: -Testare testar enkla grejer först för att testprogressen snabbt ska få ”rätt” utseende. -Utvecklare rättar enkla grejer först av samma orsak. Oavsett om det framkommer att testresultaten är missvisande eller inte: Följderna av missvisande testresultat är inte roliga. Se till att dina testresultat är rättvisande!

Slutsats: Se till att dina testresultat är rättvisande!

Viktning av S-kurvan Ett enkelt exempel på hur vi kan komma till rätta med missvisande testresultat. Istället för viktade testcase skulle vi kunna mäta täckning av kraven med koppling till prioritet.

Viktning av S-kurvan Kan göras relativt enkelt i Excel tar lite tid om man har många testfall… Vad klarar de marknadsledande verktygen? Här finns alternativ Eller så krävs det en del anpassning…

S-kurvan & trendlinjen Exempel 1: Vad ska vi göra nu?

Vad klarar de marknadsledande verktygen? Klarar inte detta rakt av Utgå ifrån resultatet i verktyget Exportera till Excel Utför trendanalysen i Excel Detta kan ej göras direkt i QC. Man kan däremot utgå ifrån de siffror man får ifrån QC för att exportera dessa till Excel och utföra trendanalysen där.

Att sätta mål SMART (Specific, Measurable, Achievable, Relevant and Timely)

Om man nu ska sätta ett mål – hur skulle det kunna se ut? För utvecklingsteamet: Att x antal testfall ska ha passerat med OK resultat efter fjärde testomgången? Möjligt, tänk dock på att det är inte bara utvecklingsteamet som är med och påverkar det här mätetalet då testmiljöer, ev. resursbrist i test-teamet etc. Bättre då kanske att sätta ett mål som är ett procenttal passerade tester jämfört med antalet körda. För test-teamet: Här borde man kunna använda antalet körda testfall vid en viss tidpunkt. Dock: Skulle det vara så att utvecklingsteamet ej har levererat enligt plan så bör man ta hänsyn till det. Kanske även här bättre att mäta i procent – d.v.s. x procent av levererad funktionalitet ska vara testad vid en viss tidpunkt.

Exempel på rapportering av testprogress Bilindustri Stort projekt Många subsystem ”Leveransdatum ej förhandlingsbart” Det här är ett exempel på hur man kan komplettera den traditionella S-kurvan för att få lite djupare information om olika projektdelar för ett stort projekt. Det är alltså inte meningen att denna rapportering ska ersätta S-kurvan. Vet ni förresten vad det är för skillnad på en terrorist och en metodare? Man kan förhandla med terroristen! Hoppas att vi inte har några terrorister här idag (de kanske inte skulle hålla med…)

Exempel från bilindustrin där ett stort antal (inbyggda) subsystem skall levereras samtidigt i en ny bilmodell. Denna bild från någonstans under andra halvan av projektet visar snabbt några intressanta fakta: Subsystem 2, 12 och 13 har testat ganska mycket av det som implementerats men det verkar som att kvaliteten är bristfällig. Eller är det bara icke allvarliga buggar som gör att testerna ej får ”Passed”? Subsystem 5 har ej börjat testa ännu… Problem med testmiljön eller resursproblem? Subsystem 7 och 28 har ej levererat någon funktionalitet ännu – vad beror det på? Subsystem 8 och 11 har väldigt bra Pass-rate. Hur är det med testkvaliteten? Subsystem 16 har levererat väldigt lite… Subsystem 20 har bara testat lite grann… Problem med testmiljön eller resursproblem? Subsystem 22 har testat en del men det mest har failat. Samma frågor som punkt 1. Subsystem 27 har bara testat lite och det mesta har failat. Problem? Fördelar med detta diagram: -Överblick -Många detaljfrågor kan diskuteras utifrån denna bilden Nackdelar med detta diagram: -Utan kompletterande information svarar den ej på alla frågor. -Utan kompletterande information kan ett förrädiskt lugn sprida sig avseende vissa subsystem där det tvärtom finns allvarliga problem… -Mycket info på liten yta…

Exempel på vad ett av de marknadsledande verktygen klarar: Mercury (HP) Quality Center Klarar i princip detta rakt av om: Alla subprojekt i samma QC-projekt Eller om man kör Dashboard

Exempel på graf som skulle kunna vara användbart till detta Exempel på graf som skulle kunna vara användbart till detta. Nackdelen är att om man vill ha det i procent får man göra en del anpassningar – kan vara nödvändigt om det skiljer mycket på subprojektens storlek / antal testfall etc. Vilken typ av kompletterande info skulle då behövas i detta exempel för att räta ut en del av frågetecknen? Någon typ av felrapportering där man kan se detaljer som t.ex. antal fel per delsystem samt allvarlighetsgrad för de rapporterade felen skulle kunna vara värdefullt. Vi kommer därför inte helt osökt in på området felrapportering…

Exempel på vad ett av de marknadsledande verktygen klarar: Mercury (HP) Quality Center Klarar i princip detta rakt av om: Alla subprojekt i samma QC-projekt Eller om man kör Dashboard Klarar det i % om: Man har lagt till nödvändiga fält

Agenda Inledning/Exempel Testprogress Felrapportering Hur kommer jag igång?

Det kan ju vara ganska intressant att se hur många defekter av olika allvarlighetsgrad som har rapporterats per iteration. En fråga som denna grafen INTE ger svar på är dock: Antal öppna defekter just nu… - vilket är mycket viktigt att få reda på! Därför bör denna kompletteras med följande graf…

Dessa två grafer kompletterar varandra på ett bra sätt då de beskriver defektutvecklingen från lite olika perspektiv.

Och lägg som sagt gärna in den förväntade trendutvecklingen för att ha ett hum om var man kommer att hamna i slutändan. Den här förväntade trenden kan även fungera som en målbild och man kan naturligtvis skruva lite för att uppnå ett visst mål. Har vi fått svar på våra frågor? Hur många felrapporter finns det totalt som ej är lösta? – Besvarad Hur många felrapporter har testats men visade sig ej vara lösta på ett tillfredsställande sätt? – Ej besvarad Hur många av de nya respektive lösta felrapporterna var allvarliga? - Besvarad Hur många var mindre allvarliga? – Belvis besvarad

Exempel på vad ett av de marknadsledande verktygen klarar: Mercury (HP) Quality Center Klarar graf 1 om: Man har lagt till nödvändigt fält (fas) Klarar graf 2 (exkl. trend) Ett alternativ till att försöka göra den visade kurvan är att göra en S-kurva på detta också (defekterna ackumulerat).

Fördelen med den här grafen är att man kan få ut förändringarna per dag i efterhand utan att behöva göra någon egentlig mätning varje dag. Allt finns lagrat så länge man kommit ihåg att slå på History på aktuella fält. Glöm ej att filtrera på Open…

En annan graf som kan vara bra att kika på är den som visar hur många gamla surdegar man har liggande i sitt system. Denna kan vara svår att få fram utan ett vettigt verktyg.

Exempel på felrapportering Förvaltning Klient Mycket integration Målstyrning

Järn ≈ Toapapper enligt projektdeltagarna… Resultatet? Järn ≈ Toapapper enligt projektdeltagarna…

Att tänka på vid målstyrning Vem är målen satta för? Fel här kan leda till Fel fokus med oönskade följder Suboptimering Ev. sidoeffekter Rejectade felrapporter (murar) Erfarenhet: Detta fungerar bra om utvecklare och testare sitter tillsammans Vem är målen satta för? Fel fokus: Test-teamet ska ju inte försöka begränsa antalet defekter. Om de också ska styra mot detta målet kan det bli konsekvensen i sena projektfaser. Test-teamet ska ju inte sträva efter att hitta så få buggar som möjligt… Suboptimering: En massa fel hamnar i samma felrapport… Detta mätetal fungerar bra om utvecklare och testare sitter tillsammans men blir lite svårare att hantera om man sitter åtskilda. Därmed inte sagt att det inte är värt att använda den här typen av målstyrning även i dom fallen. Man bör dock vara medveten och beredd på konsekvenserna.

Vad av ovanstående klarar då de kommersiella verktygen?

Vad klarar de marknadsledande verktygen? Mercury (HP) Quality Center Klarar att leverera de faktiska siffrorna (tillägg av fält) Trendkurvan får man rita in själv Sammanställningen får man göra själv

DDP = Defect Detection Percentage Formel Defects found in this test All defects found DDP = Vad är då definitionen på ”this test”. Vanligtvis brukar man börja med att jämföra fel hittade före leverans/produktionssättning respektive efter. All defects är alltså inkl. fel funna i produktion / efter leverans. Här gäller det att bestämma en tidpunkt när man inte mäter längre. Det kan vara vid nästa release men det kan även vara vid en tidigare tidpunkt om man anser att antalet fel efter denna tidpunkt ej är av relevant mängd.

DDP = Defect Detection Percentage Exempel 638 638 + 29 DDP = 667 = = 95,7 %

Är det någon som ser något konstigt med de här resultaten? DDP för Critical är lägst – lite konstigt…? – Beror på att siffrorna kommer från ett projekt där man använde Critical på ett lite underligt vis – en bugg kunde bara ha Severity Critical om man befann sig i de sista faserna i projektet… Trots att både Critical och High går ned kraftigt i release 2 så går DDP Total upp… Beror på att Low och Critical värderas lika…

DDP = Defect Detection Percentage Slutsats 1: Vikta DDP! Slutsats 2: Använd Severity konsistent DDP kan även mätas under projektets gång (per testfas)

Vad klarar de marknadsledande verktygen? Mercury (HP) Quality Center Går att göra med hjälp av Dashboard Eller Excel… De här beräkningarna är så pass enkla bara man har de summerade resultaten (vilka man enkelt kan avläsa i QC), så det enklaste i det här fallet är nog att göra det i Excel.

Agenda Inledning / Exempel Testprogress Felrapportering Hur kommer jag igång?

Hur kommer jag igång? Fundera/diskutera behov Prova ”på kammaren” Resultat rimliga? Resultat korrekta? Resultat rättvisande? Diskutera med projektledaren Stegvisa ”releaser” av mätresultat

Steg vid mätning/målstyrning Behov? Prova på ”Kammaren” Kommunicera mätresultat Sätt mål Mät Belöna!

Att tänka på! För att kunna kontrollera utfallet måste vi mäta: Tidigt Ofta

E-post: anders.timmeras@sigma.se Frågor? E-post: anders.timmeras@sigma.se Tel: 0703-79 12 39