Mät värdet av testerna

2009-05-11 Artikelbanken Test Läst 8465 gånger

För att kunna räkna på värdet av testningen kan man använda olika typer av mätetal, eller teststatistik med ett annat ord. Det finns många sorters mätetal. Vissa kan användas för att bedöma om man har testat tillräckligt. Andra används för att mäta testernas effektivitet och åter andra används för att räkna ut hur mycket pengar felen egentligen kostar. I den här artikeln får du lära dig fyra praktiskt användbara mätetalstekniker som kan användas i testarbetet.

S-kurvan

S-kurvan är ett klassiskt mätetal som ofta används för att visa ackumulerat antal felrapporter. I sin enklaste form visas tiden längs den horisontella axeln och antalet funna fel på den vertikala axeln. Eftersom kurvan är ackumulerad kommer antalet felrapporter bara att öka, kurvan kan aldrig gå nedåt. I början av testarbetet är det sannolikt att man hittar många fel. Ju längre tid som går, desto färre nya fel hittar man för varje dag. Resultatet är att kurvan så småningom planar ut och bildar det som ibland kallas kurvans ”nacke” och kurvan ser då ut som bokstaven S, något utdraget. Att kurvan så småningom planar ut i stället för att fortsätta öka brant kan tyda på att kvaliteten successivt blir bättre och bättre eftersom allt färre buggar hittas, men det kan också ha andra orsaker, t ex att färre personer testar i slutet än i början.

Ofta väljer man att visa tre kurvor i samma diagram, en för öppnade fel, en för fel som är klara för omtest och en för godkända felrapporter, detta görs för att kunna dra fler slutsatser av statistiken. Om kurvan för öppnade felrapporter ser ut som ett fint S men kurvan för fel som är klara för omtest är mer ryckig, kan det tyda på att utvecklarna rättar felrapporterna då och då i stället för kontinuerligt. De kanske jobbar med nyutveckling i stället för att rätta buggar. Orsaken kan också vara att vissa fel är mer omfattande än andra så att en stor del av utvecklarresurserna går åt till att rätta buggar. Om detta är anledningen, bör det blir en ketchupeffekt när felen är åtgärdade – först kommer ingenting, sen kommer många felrapporter tillbaka till testarna för omtest på en gång.

Komplettera gärna S-kurvan med att ta fram felstatistik som visar antalet nya felrapporter, antalet under rapporter utredning, under rättning, under omtest, godkända och så vidare. Om S-kurvan indikerar en flaskhals hos utvecklarna, så syns det i felstatistiken när antalet fel under utredning eller under rättning ökar.

Ibland ligger flaskhalsen hos testgruppen. Detta syns i S-kurvan som att kurvan som visar antalet fel som är klara för omtest är ryckig. Det kan tyda på att testarna inte gör omtest kontinuerligt utan snarare då och då. Det kanske är roligare att hitta nya fel än att bekräfta att gamla buggar är åtgärdade?

Det finns tillfällen då det inte finns någon mening med att ta fram S-kurvor. Ett exempel är om antalet funna fel är mycket litet eller om testperioden är kort. I dessa fall är det mycket svårt att dra några vettiga slutsatser av statistiken eftersom det händer för lite. Använd i stället teststatistik och titta på hur många fel som påträffats och hur många av dessa som åtgärdats.

S-kurvor finns ofta som en inbyggd funktion i administrativa testverktyg, men man kan också räkna för hand och göra ett diagram i Excel.

Procent hittade fel

Procent hittade fel, PHF, är en teknik för att mäta hur stor andel av felen som hittas under testperioden jämfört med hur många som hittas efter produktionssättning. Resultatet är ett mått på testperiodens kvalitet – testerna är ju inte särskilt effektiva om de flesta felen hittas av användarna i stället för under testperioden. Genom att använda PHF är det möjligt att jämföra testernas kvalitet före och efter en ändring av testprocessen.

Tekniken fungerar så här: Räkna antalet fel som hittas under en testperiod. Som exempel hittas 80 fel under testerna. Driftsätt systemet och fortsätt räkna antalet fel under en period, exempelvis fram till nästa driftsättning. Som exempel hittas 20 ytterligare fel under denna period. Totalt har således 80 % av felen hittats under testerna, vilket är klart godkänt i de flesta system.

Man kan både jämföra mellan systemtest av version 1 och systemtest av version 2, men också mellan testnivåer, t ex mellan systemtest och acceptanstest. Generellt sett brukar man säga att 80-90 % av felen bör hittas på en testnivå jämfört med nästa testnivå. Om andelen hittade fel är mycket högt, t ex 95 % kan det bero på att testerna var väldigt bra, men det kan också bero på att systemet inte har använts tillräckligt mycket under perioden efter driftsättningen. Om man får detta resultat när man jämför en testnivå med nästa, kan det bero på att den senare testnivån är dåligt genomförd.

Procent hittade fel kan användas för att mäta värdet av att en förändring i testarbetet. Mät en gång, genomför förändringen och mät igen.

Felens kostnad

Ett användbart mätetal som kan användas i kombination med de andra mätetalen är hur mycket pengar varje fel kostar. Om man vet att ett fel kostar X kronor att åtgärda så blir det genast mer intressant att använda tekniken procent hittade fel. Hur kommer man då fram till vad felen kostar? En medarbetare brukar i genomsnitt kosta 1 000 kr per timme. Många stora företag har en färdig schablonsiffra för detta som man använder t ex vid budgeteringar för projekt. Börja med att ta reda på vilken siffra din organisation räknar med. Intervjua sedan de som är inblandade i test- och korrigeringsarbetet, t ex IT-arkitekt, utvecklare, testare, testledare och dokumentera vad som görs om ett fel hittas. Här är ett exempel för fel som inträffar i produktion:

Aktivitet Tid (timmar)
Teknisk projektledare och utvecklare utreder felet 1
Utvecklare rättar felet 2
Utvecklare testar programmet 1
Testare testar om felet 1
Dokumentation 4
Installationsprogram för buggfix 2
Information till användare via e-post 2
Övertid i samband med installation 4
Summa 17

Om den genomsnittliga timkostnaden är 1 000 kr innebär det att varje bugg som påträffas i produktion kostar 17 000 kronor att åtgärda. Gör motsvarande beräkningar för de olika nivåerna från kravhantering via komponenttest till acceptanstest så kan du använda detta som grund för att räkna ut hur mycket felen kostar på varje nivå. Om du ändrar testprocessen så att fler fel hittas tidigare, kan du beräkna vad företaget tjänat på ändringen. Använd tekniken i kombination med procent hittade fel.

Kodtäckning

Kodtäckning är ett samlingsnamn för ett antal tekniker för att mäta hur stor del av programkoden som körs när testfallen utförs. Om du har ett program som består av 100 rader programkod och får reda på att 90 av dessa genomlöps av testfallen så är det avsevärt bättre än om du får reda på att bara tio av raderna körs. Kodtäckning mäts med hjälp av ett särskilt testverktyg för ändamålet, ett så kallat kodtäckningsverktyg. Det fungerar så att en liten del av verktyget byggs in i systemet som testas. Därefter utförs testerna med hjälp av manuella eller automatiserade testfall och kodtäckningsverktyget loggar och redovisar resultatet. Det är vanligt att en grafisk vy av systemet visas och det finns möjlighet att direkt hoppa till koden för att närmare studera de delar som inte genomlöpts. Kodtäckning visar därmed en aspekt av testfallens kvalitet, nämligen att testfallen ska täcka så stora delar av programkoden som möjligt.

Det är lätt att ledas att tro att testfallen bör täcka 100 % av programkoden för att det ska vara bra, men detta är inte praktiskt möjligt eftersom det finns kod som är mycket svår att nå. Ett exempel är programmets felhantering som används för att hantera fel som uppstår i systemet. Ofta använder programmeraren både hängslen och svångrem, vilket gör att en del felhanteringskod är till för att hantera teoretiska problem som inte inträffar i verkligheten. Vad som är en rimlig nivå på kodtäckning varierar mellan olika programmeringsspråk och är beroende av systemets arkitektur. I ett system som utvecklades i C# nådde vi 92-93 procent kodtäckning som exempel.

Det finns ett flertal kodtäckningsverktyg på marknaden, både kommersiella och sådana som är öppen källkod. Verktygen är konstruerade för att passa ihop med ett eller flera programmeringsspråk, därför finns det inga generella tips på verktyg. Enklast hittar du rätt verktyg genom att söka med Google, t ex på ”code coverage C++” för att hitta ett verktyg för programmeringsspråket C++.

Avslutning

Det är viktigt att förklara för de inblandade vad det är som mäts, t ex att det inte är individerna som mäts. Mätetalsteknikerna bör kombineras och tillämpas vid flera tillfällen, inte som en engångsinsats om det ska gå att dra några slutsatser. Som du ser visar mätetalen olika saker:

  • S-kurvan kan visa om systemet är klart för att driftsätta.
  • Procent hittade fel mäter kvaliteten på en testfas.
  • Kodtäckning visar testfallens kvalitet.
  • Det är möjligt att beräkna felens kostnad.

Tips för vidare läsning

  • I boken ”Test och kvalitetssäkring för IT-system” av Ulf Eriksson behandlas mätetalen utförligt.
  • Faktabanken innehåller fler kostnadsfria dokument inom test och krav.

 

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln