Test och värdeskapande
•Download as DOCX, PDF•
0 likes•482 views
Article in swedish about generating value with testing.
Test och värdeskapande
- 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