Article in swedish about generating value with testing.

1. Test och Värdeskapande
Hur välskrivna ens tester än är, och hur fantastiska de testrapporter man
skriver än må vara, så är det inte artefakterna i sig som skapar värde. Du kan
ha ett väloljat automatiskt testramverk som exekverar tusentals tester varje
dag utan att detta garanterar att något värde skapas. Det kan till om med
vara så att ditt tröstlösa exekverande av testfall och skrivande av
testrapporter istället för att generera värde kostar din organisation tid och
pengar.
Detta är en frågeställning som alla testare alltid måste ha i bakhuvudet.
Genererar jag något värde? Om du inte gör det måste du ändra hur du jobbar
så att du börjar göra det.
Nyckeln till att generera värde är att känna sina kunder. Förstå deras behov
och förstå hur testaren kan möta detta behov. Olika kunder har olika behov.
Något som är värdefullt för en kund kan vara värdelöst för en annan.
Så hur genererar en testare värde? Det absolut mest konkreta och mätbara
borde rimligtvis vara de defekter eller buggar testaren hittar som faktiskt
rättas i produkten. Värdet av att inte ha buggen i produkten går på något sätt
att kvantifiera.
Det finns också omständigheter där tester måste exekveras för att möta
någon standard eller kundkrav. Ett exempel är 3GPP standarder för
mobiltelefoner. Där man inte kan välja om det är relevant att köra testfallen
eller inte. Då kan värde som genereras av testaren kvantifieras genom att
jämföra vad kostnaden skulle ha blivit om man anlitat ett externt testorgan
för att certifiera produkten.
Sen blir det genast svårare. Testaren genererar information som någon kan
använda för att fatta beslut utifrån. Medvetenhet om buggar man väljer att
inte fixa. Förståelse för kvalitén inför ett lanseringsbeslut. Information om
kvarvarande produktrisker. Betydligt svårare att kvantifiera. Här är det
viktigt att fråga sig om den information man producerar verkligen används
för att ta några väsentliga beslut med hjälp utav, eller om det bara är något
som projektet begär för att sedan ignorera.
Utöver detta kan man prata om förebyggande åtgärder och stöd till
utvecklare för att hindra buggar från att komma in i produkten från första
början. Det kan röra sig om utbildning i testtänkande, granskning av kod
eller andra artefakter, risklistor som input till skapande av komponenttester,
eller ett testramverk som utvecklarna kan använda när de skriver sina

2. komponenttester. Även detta är väldigt svårt att kvantifiera. Kanske går det
att göra det genom att mäta inflödet av fel och klagomål på redan släppta
produkter innan och efter dessa förebyggande åtgärder och stöd är
implementerade.
Det centrala är att man dissekerar det man gör och verkligen säkrar att det
genereras någon typ av värde. Att man inte bara bygger ut sin automatiska
testsvit, eller exekverar sin stora regressionssvit med manuella testfall, eller
utforskar ett system i vecka efter vecka, utan att reflektera över om det man
gör faktiskt är värdefullt för någon.
Det kan till och med vara så att man skapar kostnader om man inte då och då
stannar upp och reflekterar. Ett exempel kan vara följande scenario:
”En testare är ansvarig för att testa en applikation. Projektet börjar närma sig
slutskedet. Testaren utför dagligen ett antal testsessioner. Nitiskt rapporteras
varje avvikelse från kraven. Hundratals defekter rapporteras. Det visar sig
dock att de flesta av defekterna inte rättas. Vissa defektrapporter var helt
enkelt fel eftersom kraven i kravdokumentet inte längre var korrekta, eller
någon liknande anledning. Många defektrapporter var korrekta, men felen var
så pass små/irrelevanta att projektet bestämmer sig för att inte rätta dem.
Tiden som utvecklarna har spenderat på att analysera alla buggarna som
testaren rapporterat överstiger värdet av de få buggar som testaren hittat och
som faktiskt rättats. Utvecklaren hade kunnat spendera tiden med att rätta
andra kritiska fel som redan var rapporterade.”
I ovanstående situation har alltså testaren formellt sett gjort ett relativt bra
jobb, om antalet felaktiga defektrapporter är förhållandevis låg. Många fel
har trots allt rapporterats. Sen om projektet väljer att inte rätta dem är väl
inte testarens fel?
Det är en irrelevant frågeställning. Det man ska fråga sig i situationen ovan
är om vetskapen om alla de små/irrelevanta defekterna som rapporterats är
värd mer eller mindre än den tid som utvecklaren spenderat på att analysera
defekterna. Om svaret är mer kan man fundera på om man ändå kanske kan
utnyttja tiden mer effektivt och på något sätt rapportera mer relevanta
defekter, och om svaret är mindre kanske man ska sluta rapportera
irrelevanta defekter som kostar mer än de genererar värde.
Att veta vilka defekter som är viktiga kan vara långt ifrån trivialt. En defekt
som är irrelevant för en person kanske är viktig för en annan. Samma sak kan
gälla olika faser av projektet. I början av projektet kanske det är värdefullt
att rapportera ett problem med användarvänligheten, medan det en vecka
innan leverans kanske inte är det, utan kanske ska vänta till nästa version.

3. Kännedom om kundernas behov och systemets komplexitet gör bedömningen
enklare, men man introducerar alltid en risk genom att göra detta.
Man kan tycka vad man vill om exemplet, men kontentan är att man aldrig
ska göra någonting utan att ifrågasätta om det man gör faktiskt genererar
något värde. Oavsett om man gör ”rätt” eller ”fel” rent formellt. Oavsett om
man kodar automatiska testfall, utför testsessioner, designar manuella
testfall, eller skriver testrapporter.
/Johan Hoberg