8 skäl att mäta testernas effektivitet

2009-10-16 Artikelbanken Test Läst 9093 gånger

För att beräkna olika aspekter av testarbetets effektivitet kan man använda mätetal, eller teststatistik med ett annat ord. Det existerar ett stort antal mer eller mindre vedertagna mätetal och alla är specialiserade för att lösa behov genom att besvara frågor. Exempel på sådana frågor är hur mycket pengar felen i ett IT-system kostar, hur effektiva testerna är och vilka typer av fel som oftast missas. Här får du veta mer om ett antal vanliga frågor som mätetal kan besvara. Du får också en introduktion till en strukturerad process för att införa mätetal.

Fråga 1: Vad kostar felen?

Det är kraftfullt att kommunicera mätetal som är baserade på ekonomi. En av de mest intressanta uppgifterna är hur mycket pengar ett genomsnittligt fel kostar och detta är dessutom förhållandevis enkelt att beräkna. Ta de senaste 30 felrapporterna för ett IT-system. Undersök vilka roller som har varit inblandade i att lösa respektive fel och hur lång tid var och en fick lägga ner för att åtgärda problemet. För en felrapport påträffad i produktion kan det se ut så här:

Aktivitet

Tid (timmar)

Teknisk projektledare utreder felet tillsammans med en utvecklare

1

Utvecklare rättar felet

2

Utvecklare testar rättningen

1

Testare testar rättningen

4

Användarrepresentant uppdaterar användardokumentation

2

Utvecklare uppdaterar system- och driftdokumentation

1

Utvecklare gör installationsprogram för patchen

2

Information till användarna via e-post

1

Användarrepresentant på plats i samband med installation för att övervaka att installationen lyckas

2

Tekniker som är på plats vid installation

4

Summa antal timmar för rättning av felet

20

Om den genomsnittliga timkostnaden är 1 000 kr innebär det att varje fel som påträffas i produktion kostar 20 000 kronor att åtgärda. Gör motsvarande beräkningar för flera nivåer från kravhantering till acceptanstest så kan beräkningen användas för att visa hur mycket felen kostar på varje nivå. Detta är intressant till exempel för att bedöma besparingspotentialen av att ändra arbetssättet så att fler fel hittas tidigare.

Fråga 2: Hur är testfallens kvalitet?

Ett sätt at bedöma testfallens kvalitet är att undersöka förhållandet mellan kraven och testfallen. Testfallen bör vara länkade till kraven och varje krav bör testas med ett rimligt antal testfall, inte för många och inte för få. En spårbarhetsmatris är ett enkelt sätt att synliggöra sambanden mellan kraven och testfallen och sådana matriser finns inbyggda i de vanliga testadministrativa verktygen. En spårbarhetsmatris kan visa om det finns krav som saknar testfall. Den kan också användas för att underlätta valet av regressionstestfall.

Ett annat sätt att bedöma testfallens kvalitet är att titta på hur stor del av programkoden i det testade systemet som genomlöps när testerna utförs. Att ta reda på denna andel kallas med ett samlingsnamn för kodtäckningsanalys. Om ett program exempelvis består av 100 rader programkod och 90 av dessa genomlöps av testfallen så är det avsevärt bättre än om bara tio av raderna körs. Andelen genomlöpt programkod mäts med hjälp av ett särskilt testverktyg, ett kodtäckningsverktyg. Det är inte så att testfallen absolut måste täcka 100 % av programkoden. Även om det går att uppnå hög kodtäckning kan det finnas som inte upptäcks, till exempel prestandaproblem eller bristfällig användbarhet.

Fråga 3: Är systemet färdigtestat?

S-kurvan är ett mätetal som kan illustrera vilken status olika felrapporter har. Ofta visas tiden på den horisontella axeln och antalet funna fel på den vertikala axeln. I en S-kurva visas antalet ackumulerade felrapporter vilket innebär att kurvan bara kan öka och så småningom plana ut, den kan inte gå nedåt. När testarbetet inleds är det sannolikt att många fel påträffas. Ju längre tid som går, desto färre nya fel hittas för varje dag. Resultatet blir att kurvan så småningom planar ut och bildar det som ibland kallas kurvans ”nacke” och kurvan ser då ut som ett utdraget ”S”. Att kurvan planar ut kan vara ett tecken på att testerna kan avslutas eftersom allt färre fel hittas. Men det kan också tyda på andra orsaker, t ex att färre testare deltar i slutet än i början eller att testfallen har nötts ut.

Ofta väljer man att visa tre kurvor i samma diagram, en för nya fel, en för fel som är klara för omtest och en för stängda felrapporter, detta görs för att kunna dra fler slutsatser av statistiken.

I de vanliga testadministrativa verktygen finns funktionalitet för att enkelt skapa S-kurvor.

Fråga 4: Hur effektiva är testerna?

Testernas effektivitet kan mätas genom att se hur stor andel av felen som hittas under en testperiod i förhållande till andelen fel som hittas efteråt. Om de flesta felen hittas under testperioden är det ett tecken på hög effektivitet och omvänt. Mätetalet kallas PHF, procent hittade fel, och kan användas i många olika situationer:

  • För att undersöka om en ändring i arbetssättet lett till högre effektivitet. Mät, ändra arbetssättet, mät igen.
  • Man kan jämföra en testnivå för en version av systemet med samma testnivå vid ett senare tillfälle.
  • Man kan jämföra testnivåer med varandra, till exempel systemtest med acceptanstest. Samma princip gäller här, de flesta felen bör hittas på den tidigare testnivån.

Fråga 5: Vilka fel missas och fråga 6: När missas dessa fel?

Med kännedom om vilka typer av fel som missas går det att förbättra arbetssättet så att en större andel fel av denna typ hittas nästa gång. En annan fråga är om de kvalitetssäkrande aktiviteterna är tillräckligt effektiva så att felen hittas så tidigt som möjligt, i anslutning till att de införts. Ett mätetal som kan hjälpa till med detta är fel-läckage som kan illustreras i en tabell liknande denna:

 

Granskning
av verksam-
hetskrav

Granskning
av system-
design

Komponent-
test

Integrations-
test

System-
test

Acceptans-
test

Totalt

Missade
fel

Verksam-
hetskrav

30

10

4

2

2

2

50

20

System-
design

 

22

6

3

0

1

32

10

Implemen-
tering

   

20

8

20

2

50

30

Vertikalt visas krav- och designaktiviteterna från dokumentation av verksamhetskrav till implementering. Horisontellt visas kvalitetssäkrande aktiviteter såsom granskning och test. Anpassa tabellen till de aktiviteter som förekommer i organisationen.

I exemplet ovan kan man se att 30 fel har hittats i samband med granskning av verksamhetskraven. Om man summerar de fel som kan härröras till kraven som hittats vid alla test- och granskningsaktiviteter framgår det att totalt 50 kravrelaterade fel har hittats, vilket innebär att 20 fel av 50 eller 40 % av felen inte hittades under kravgranskningen. Det är nog inte praktiskt möjligt att hitta 100 % av kravfelen vid granskning av kraven men genom att kategorisera felen går det att hitta sätt att förbättra arbetssättet. I exemplet hittades de flesta av de resterande kravfelen då systemdesignen granskades. Kanske kan fler kravfel hittas nästa gång om granskningsmetodiken förfinas med checklistor till granskarna eller genom att granskningsroller används på ett bättre sätt.

Fråga 7: Blir testerna klara i tid?

Genom att kontinuerligt följa upp alla pågående aktiviteter blir det lättare att bedöma om testerna kommer att bli klara i tid. Målgrupp för mätetalet är testgruppen, beslutsfattare och utvecklare. Det bästa är om mätningen visualiseras, exempelvis i en burn down-chart som är vanlig i de agila utvecklingsmodellerna. I en sådan visualisera i vilken takt åtagna arbetsuppgifter slutförs.

Diagrammets vertikala axel visar den estimerade tiden för att slutföra alla aktiviteter i iterationen. Den horisontella axeln visar kalendertid från iterationens början till dess slut. Innan iterationen inleds tidsuppskattas alla aktiviteter. Den heldragna linjen visar planerad tid baserad på denna tidsuppskattning. Kurvan ovanför visar den verkliga tidsåtgången och denna uppgift uppdateras varje dag i samband med utvecklingsteamets avstämningsmöte.

I det här exemplet kan man se att teamet ligger efter. Antingen får några aktiviteter tas bort så att leverans kan ske i tid eller så får leveransdatumet flyttas framåt (detta bör undvikas).

Det är fullt möjligt att göra en separat burn down-chart med testaktiviteter men det är vanligare att diagrammet innehåller alla aktiviteter som teamet har åtagit sig, till exempel kodning, test och dokumentation.

Fråga 8: Vilka aktiviteter kvarstår?

Alla intressenter, projektledare och utvecklingsteamet har behov av att snabbt kunna se status för de olika aktiviteterna som ingår i en leverans. Bland de agila teknikerna finns konceptet Scrum-tavla (Scrum board) där en whiteboard-tavla används för att visa status för samtliga aktiviteter som ingår i en leverans. Jämfört med en burn down-chart som visar summan av alla aktiviteter visar Scrum-tavlan status för varje enskild aktivitet. En scrum-tavla ritas på en whiteboard-tavla som delas in i ett antal kolumner, där rubrikerna ofta har namn i stil med ”åtagen”, ”under arbete” och ”klar”. När en aktivitets status ändras flyttas aktiviteten från en kolumn till nästa. Scrum-tavlan uppdateras dagligen av teamet och därmed ger tavlan en god nulägesbild.

Att välja och införa mätetal

Att börja använda mätetal på ett strukturerat sätt i en organisation hanteras som vilket projekt som helst med en projektgrupp, tidplan och definierade mål. Arbetet kan vara mer eller mindre komplicerat beroende på faktorer som organisationens storlek, testmognad och vilka mätetal som införs. Följande är ett antal viktiga milstolpar i arbetet med att välja och införa mätetal:

  1. Olika mätetal besvarar olika frågor, därför börjar valet av mätetal med att fastställa vilka frågor som ska besvaras. Exempel på frågor kan vara ”lägger vi ned tid vid rätt tillfälle”, ”vad kostar egentligen felen” och ”hur effektiva är testerna”. Målen bör vara formulerade enligt SMART-modellen: specifika, mätbara, accepterade, realistiska och tidsbestämda.
  2. Välj mätetal. Jämför olika mätetal med varandra för att se vilka som bäst besvarar de ställda frågorna. Kanske är en kombination av flera mätetal bäst.
  3. Säkerställ stöd från ledningen. Det är viktigt att ledningen marknadsför mätetalsanvändningen internt för att uppnå bred acceptans. Ofta ser projekten mätetal som något nödvändigt ont och därför är det viktigt att visa på de långsiktiga fördelarna som att hitta fler fel vid rätt tillfälle, roligare arbete och att omgivningens respekt för testning ökar.
  4. Anpassa mätetalen till organisationen. Ta fram mallar och instruktioner till dem som ska rapportera in statistiken. Ofta behöver även vissa justeringar i arbetssättet göras, t ex kan det vara nödvändigt att börja räkna antalet funna fel på komponenttestnivån för att kunna beräkna PHF (procent hittade fel).
  5. Anpassa verktygen. I ett felrapporteringsverktyg kan man behöva lägga till vissa fält eller säkerställa att alla anger information på enhetligt sätt så att det ska bli möjligt att få ut den information som önskas.
  6. Utvärdera valet av mätetal efter en tids användning. Komplettera med fler mätetal när efterfrågan växer.

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