Mange har den opfattelse, at testerne kan sikre kvaliteten af de enkelte softwareleverancer. At teste giver ikke isoleret en højere kvalitet i softwaren - det forudsætter at de fundne fejl faktisk også rettes, og dermed øges kvaliteten. Testen bidrager selvfølgelig til denne kvalitetsforøgelse, men alene ved at evaluere softwareleverancen og belyse kvaliteten af denne.
Men hvis ikke softwaretest sikrer kvaliteten, hvad er værdien så?
Et vigtigt og værdifuldt udbytte af test er information - herunder information om kvaliteten af softwareleverancen. Denne information kan anvendes i flere sammenhænge - dels til fejlrettelse og dels til dannelsen af et beslutningsgrundlag for afgørelsen om leverancen skal idriftsættes i produktion eller ej. Testerne er med til at bidrage til grundlaget, men selve beslutningen er ledelsens ansvar.
Informationen om kvaliteten kan også med stor fordel anvendes til at italesætte de potentielle risici der er for forretningen, hvis softwaren idriftsættes.
Ledelsen får rapportering fra projektets testmanager, som typisk vil adressere følgende fem aspekter:
- Test (og dets resultater) opdelt på status (godkendt, fejlet, blokeret m.m.)
- Fejl opdelt på alvorlighed (forretningsmæssigt) og prioritering (hvordan skal den rettes)
- Testdækning, herunder eksempelvis andelen af krav der er dækket af test
- Produktrisici opdelt på risikoklasse (høj, medium, lav)
- Tillid, som er en mere subjektiv opfattelse af softwaren og kvaliteten
Kurven A (Rød) udtrykker de samlede omkostninger til fejl således at jo flere fejl - udtrykt ved et lavere niveau af kvalitet desto højere omkostninger og omvendt for færre fejl. Årsagen til denne sammenhæng bygger bl.a. på Barry Boehms studier. Kurven C (Gul) illustrerer de samlede testomkostninger for både statisk (f.eks. review) og dynamisk test og er stigende ved et ønske om højere kvalitet. Kurven B (Blå) viser kvalitetsomkostningerne og udgør summen af kurverne A og C. Det bør være målet at tilsikre en balancering af alle disse forhold og komme så tæt på kurvens minimum som muligt.
Da det ikke er muligt at teste alt er det vigtigt at der sker en klar udvælgelse og prioritering af testen. Det kan eksempelvis ske via risiko-baseret test med vurdering af produktrisici. Det er vigtigt, at ledelsen bakker op om dette og sikrer at forretningen deltager i dette arbejde.
Ovenstående figur kan anvendes som en god model for dialog mellem ledelsen og testmanageren om omfanget af testindsatsen. Hvis du er leder kan du anvende denne til en drøftelse med dit udviklingsprojekts testmanager - god fornøjelse.
God læsning - Ord som "Risk based testing" og "Context driven testing" dukker op - og så spotter jeg en sjov detalje - linjen C, som synes grøn på min skærm, beskirves som gul....
SvarSlet