Kvalitet kostar, men fel kvalitet kostar mer. Varför är det så viktigt med kvalitet, och vilka metoder kan du som Test Manager eller QA Manager använda i din organisation?
Att jobba med utveckling av mjukvara är att jobba inom ett område där sanningen kontinuerligt ändras, där vilka metoder som är bäst ständigt ändras, och där det ibland framställs som att det skulle finnas en Quick Fix. Påståenden som ”om ni börjar jobba agilt så löser ni alla problem” är allt för vanliga. Här kommer vi istället fokusera på några av de metoder som finns, och hur de skulle kunna införas hos er.
Kontinuerliga analyser och riskbedömningar
QA-rollen är kontinuerligt under förändring. Idag jobbar många med utforskande tester, kontinuerlig förändring och förbättring, riskbedömningar, tvärfunktionella team och agila metoder. Allt eftersom QA:s roll och arbetsmetoder ändras, följer att kraven på en QA manager också ändras. Alla metoder har sina styrkor, men ingen av dem kommer att lösa alla problem och alla kan inte införas samtidigt.
För att lyckas leverera rätt kvalitet, i varje leverans, behöver QA managern förstå modern agil utveckling och QA:s roll i denna. Dessutom vilka andra metoder som finns, och hur dessa passar ihop.
Riskbedömningar kan användas även i traditionell utveckling, men görs då oftast en gång, i början av projektet. Jobbar man agilt kan man analysera kontinuerligt, bedöma riskerna kontinuerligt, och anpassa sig till detta. Som exempel kan man tidigt i utvecklingen se om ens team har problem med kommunikation, någonting som leder till en risk för fler fel, och då kan man åtgärda detta snabbare.
Metoder och verktyg
Vi utgår här från att ni redan jobbar agilt. Visserligen kan flera av dessa metoder användas även om man jobbar med exempelvis vattenfall, men de fungerar bättre om man jobbar med agila metoder, och ni kommer att märka att de är lättare att införa i en organisation som redan ställt in sig på kontinuerlig förändring. I en mer statisk organisation, där förändringar är stora och kommer mer sällan, orsakar en förändring ofta konflikter och leder under en period till minskad produktivitet.
Teknisk skuld
Teknisk skuld uppstår för att man inte fixar problem direkt. I en utvecklingsmodell som vattenfall kan det innebära att man skjuter väldigt många problem framför sig, där allting ska fixas i nästa release, en release som kommer påbörjas när denna är klar.
Men, även om man jobbar agilt finns en risk för teknisk skuld. Om vissa buggar hamnar i backloggen, för att de inte bedöms som lika viktiga, bidrar de till att bygga upp en teknisk skuld. Ofta visar detta sig i att backloggen blir större och större för varje sprint (om man jobbar enligt Scrum).
En teknisk skuld leder till flera saker: stress över en växande backlogg, irritation från de som rapporterat felet eftersom det dyker upp gång efter gång efter gång. Men, framförallt blir de svårare att lösa. Ett problem kan vara enkelt att fixa. Utvecklaren kanske behöver en timme om den ska fixas nu. Men, om 4 veckor, eller 4 månader, är det svårare, tar längre tid, har ökad risk för att inte lösa problemet. Därmed ska även teknisk skuld ligga med i de kontinuerliga riskbedömningarna.
Det finns flera sätt att minska den tekniska skulden. Jobbar man med Scrum kan man lägga in att varannan (var tredje, var fjärde, etc) sprint ska ägnas åt backlogg och att rätta fel. Här är värt att återigen poängtera att det tar längre tid att fixa ett fel ju längre sedan det rapporterades. Utvecklare pratar gärna om ”context switching” dvs att när man byter fokus tar det tid att sätta sig in i det nya fokuset. Att det gått en månad sedan man utvecklade en funktion som man ska buggfixa nu är en väldigt stor switch. Därför föreslår vi någonting annat:
Zero bug policy
En ”Zero bug policy” kan ha flera namn. En metod beskrivs på ”fixitnowordeleteit”. I korthet handlar det om att bestämma hur snabbt en bugg måste rättas, vilken prioritet det ska ges, och om man någonsin får ha en backlogg.
Hur snabbt och prioritet hänger ihop med hur ni arbetar. Om ni jobbar med CI/CD och har kontinuerliga leveranser kan det ibland vara rimligt att avbryta eller pausa leveransen. Detta om buggen är kritisk och får systemet att krascha, bli instabilt, leder till kostnader, etcetera. En bugg som är av skönhetstyp kan utan problem åtgärdas efter att leveransen är klar. Men, alla buggar måste fixas.
Ett annat sätt för att minska buggar är att se till att kod utvecklas och testas i direkt följd, dvs att testet utförs direkt när koden är klar. Här kan man jobba med Quality Assistance och tvärfunktionella team, dvs att teamet testar av ny kod direkt. Jobbar man enligt Quality Assistance så är det utvecklaren tillsammans med den som just då är testansvarig i teamet som gör detta.
Det man vill undvika är att kod ska samlas ihop, paketeras, och senare deployas till en testmiljö, en miljö där de som testar inte sett koden innan, och där test kanske inte ens sitter med i teamet. Detta fördröjer återkoppling till utvecklaren och leder till context switching, liksom till att buggarna tar längre tid att laga.
Hold the line
Hold the line innebär att fel omedelbart ska stoppa allt annat arbete, och det kommer från Kanban-tänket. Det gör att det passar extra bra om man jobbar med Kanban eller Scrum-ban, men det kan användas även i andra modeller. Det finns två saker som är viktiga här:
- 1. Teamet måste vara överens om var nivån för detta går. Prata igenom det, få teamet att nå konsensus, kommunicera. Om teamet vill ha ”stop the line” för minsta lilla bugg (ex.vis ett skönhetsfel) så blir det ineffektivt, men det kommer teamet snabbt att upptäcka, och justera, så länge som ni jobbar med kontinuerlig förändring och förbättring.
- 2. Definiera vad det innebär för ditt team. Ska alla i teamet sätta sig bredvid den som hittat felet? Ska man ha tuta som man tutar i när man vill stoppa? Är några (ex.vis de som håller på med en deploy) undantagna. Följ sedan denna definition. Skriv ut den och sätt på väggarna.
-
-
Kontinuerlig förbättring
Inget av de metoder som beskrivs ovan (hold the line, etc) kommer fungera direkt. Ni kommer hitta delar som fungerar bra och delar som inte fungerar för er. Man får inte gå in i den här processen och tro att ”om vi gör såhär så löser vi alla problem”. Ett exempel på en sådan missuppfattning är när man inför Scrum för att slippa teknisk skuld. Det fungerar helt enkelt inte så, och därför måste man justera, justera, justera. Detta fungerar mycket bättre om teamet, utvecklingsavdelningen, företaget är inställda på kontinuerlig förändring, kontinuerlig förbättring. Det minskar konflikter, ökar produktivitet och leder till en kultur där man hela tiden utvecklas.
Kommunikation
Allt som beskrivits hittills i den här artikeln bygger på kommunikation. Det är ditt nyckelord, både för dina utvecklare, de som jobbar med QA och för dig. Utan kommunikation kommer det här inte att fungera. Kommunikation är så mycket mer än att peka med hela handen eller att skicka ett policy dokument för hur test ska gå till.
Det finns olika metoder att öka kommunikationen i dina team. Ett första steg kan vara att se om ni är överens för var ansvaret för olika saker ligger, det vill säga hur mycket som ska delegeras från chefer till övriga.
Sammanfattning
Att jobba agilt är inte en lösning. Att jobba agilt gör det lättare att införa en del av dessa ändringar, och är nödvändigt för andra. Ska vi sammanfatta det som står här så är det följande som behövs:
- 1. Kommunikation
- 2. Jobba agilt
- 3. Kontinuerlig utvärdering (ex.vis riskanalyser)
- 4. Zero bug policy där Hold the line kan vara ett sätt att jobba
- 5. Kontinuerlig förbättring
- 6. Konsensus i teamet.
-
Du kan aldrig tvinga igenom en förändring, du kan aldrig tvinga igenom kvalitet.
