Mätetal inom kvalitetssäkring: En praktisk utgångspunkt

• ”Feedbackloopen är för lång.”

• ”Jag är inte säker på vilka tester vi kör.”

• ”Jag vet inte var våra testresultat finns.”

• ”Jag förstår inte våra testresultat.”

Den här typen av frågor betyder oftast att ni har lyckats införa CI/CD-arbetssätt i utvecklingen och att automatisering frigör tid för ytterligare förbättringar. Men hur besvarar du de här frågorna innan de blir verkliga problem och människor börjar tappa intresset?

Som tur är har du svaret inom räckhåll! Du behöver definiera relevanta mätvärden och göra dem synliga för hela organisationen, särskilt för ditt team.

Vilka mätvärden bör jag ha?

Vi får ofta den frågan. Tyvärr är svaret det ökända ”det beror på”. Det är bättre att visa något än ingenting, så börja helt enkelt någonstans.

När din organisation kan samla in, lagra och presentera data börjar ni vanligtvis förstå vilka mätvärden som behövs. ”Tja, det var inte särskilt hjälpsamt”, kanske du tänker. Därför vill vi lyfta fram en intressant artikel som vi har stött på. I den presenterar författarna följande mätvärden:

1. Användarnas upplevelse

2. Defekter som upptäcks i produktion

3. Testtäckning

4. Defekter mellan sprintar

5. Planerade jämfört med levererade stories

När vi tittade på dessa såg vi vissa överlappningar med DORA-mätvärden.

Driftsättningsfrekvens

Detta bör korrelera med en hög ”(1) Användarnas upplevelse”. Faktum är att det är en förutsättning för att du ens ska kunna observera det.

Ledtid för förändringar

Detta visar hur snabbt du kan gå från en idé hela vägen till produktion, vilket motsvarar ”(5) Planerade jämfört med levererade stories”.

Andel förändringar som misslyckas

Detta visar hur många defekter du har hittat och hur lång tid det tog att åtgärda dem. Med andra ord gör ”(3) Testtäckning” det lättare att analysera grundorsaken till andelen förändringar som misslyckas.

”(4) Defekter mellan sprintar” är ett mer detaljerat exempel på den övergripande felfrekvensen.

Tid för att återställa tjänster

Detta visar hur snabbt du kan lösa incidenter i produktion, vilket är nästa fråga efter att du har konstaterat ”(2) Defekter som upptäcks i produktion”.

Med tanke på överlappningarna och att DORA-mätvärden har visat sig fungera ser vi dessa som bra mätvärden att börja med.

Var ska du börja?

Nu när vi har definierat flera relevanta mätvärden, hur samlar vi in dem?

På Eficode tror vi på automatisering och att data i rapporter och dashboards ska vara så nära realtid som möjligt. Därför startade vi för några år sedan ett par open source-projekt för att stödja den här typen av initiativ:

• InfluxDB-plugin för Jenkins

• Oxygen

I våra kundcase har Jenkins CI varit den mest använda CI/CD-lösningen, och vi har redan genomfört ett framgångsrikt proof of concept för mätvärden med open source-tidsseriedatabasen InfluxDB, i kombination med ett annat open source-verktyg, Grafana, för att bygga dashboards.

Open source-lösningar kan kräva lite handpåläggning, men eftersom de är helt kostnadsfria är de det billigaste alternativet. Det hjälper dig att komma i gång snabbare – kom ihåg att du vill börja se data så att du kan vidareutveckla dina mätvärden.

Exempel på konfiguration:

Hur går du vidare när du har data?

När vi har satt upp infrastrukturen för att börja samla in och visualisera data skapar vi vanligtvis några grafer som besvarar några av de vanligaste frågorna. Till exempel: ”Hur stor andel av testerna som körs i Continuous Integration godkänns?” (det vill säga andelen misslyckade ändringar eller defekter under sprinten, som nämnts tidigare).

Datan kommer direkt från ditt CI/CD-verktyg, så den är så aktuell som möjligt. Och om alla kan se din data har teamet bättre förutsättningar att förstå den aktuella situationen.

Nästa steg är att tillsammans med dina intressenter börja fundera på produkten som du och ditt team bygger. All data är inte lika viktig för alla. Chefer vill till exempel se den övergripande andelen godkända tester under månaden, medan utvecklare vill se de senaste resultaten och veta om miljön klarar smoke tests.

Som tur är har Grafana och andra lösningar stöd för flera dashboards. Det gör det enkelt att visualisera separata mätvärden för ledning, teamledare, QA-team och andra.

Vi rekommenderar att du ger varje intressent tillgång till den viktigaste datan, samtidigt som de kan se all data vid behov.

Vi har ofta sett att när du börjar visa aktuell data uppstår fler idéer om vad som bör hanteras härnäst. Oftast leder det till att team börjar fatta beslut baserade på fakta i stället för att hitta på förklaringar.

Varför inte fördjupa dina kunskaper genom att lära dig mer om att bygga in kvalitet i din mjukvara?