Test for ledelsen

Der findes mange opfattelser af, hvad softwaretest er, og desværre også mange misforståelser. Misforståelser som kan give en række udfordringer for dem der har roller inden for testområdet.

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

Det er ikke muligt at teste alt - der er ganske enkelt for mange kombinationer og muligheder og for lidt tid og budget. Omfanget af test bør være en afvejning af de omkostninger der er forbundet med testen og fordelen/værdien af testen. Denne afvejning fremgår af nedenstående figur:

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.

Successful Test Automation

Jeg er i øjeblikket igang med en rådgivningsopgave med fokus på om forudsætningerne for testautomatisering er på plads, og faldt over denne liste:

1. Analyze the current process
2. Create an automation project plan
3. Put together the right team
4. Prepare a handful of test cases for automation
5. Research and select two or three test automation tools for further evaluation
6. Do a Proof of Concept (PoC)
7. Implement the selected automation tool
8. Allow time for training and the learning curve
9. Begin automating your documented test cases
10. Periodically review your process and adjust as necessary.
    

Procesforbedring - 10 fælder der bør undgås

Jeg faldt lige over denne oversigt - Karl Wiegers 'Software Process Improvement: Ten Traps to Avoid' - jeg har fastholdt den engelske formulering for at undgå at miste nogen af betydningen ved oversættelse til dansk:

1. Lack of Management Commitment
2. Unrealistic Management Expectations
3. Time-Stingy Project Leaders
4. Stalling on Action Plan Implementation
5. Achieving a CMM Level Becomes the Primary Goal
6. Inadequate Training is Provided
7. Expecting Defined Procedures to Make People Interchangeable
8. Failing to Scale Formal Processes to Project Size
9. Process Improvement Becomes a Game
10. Process Assessments are Ineffective

 Jeg vil i et senere blogindlæg komme ind på de enkelte fælder.

Metrikker - 10 fælder der bør undgås

Jeg faldt lige over denne oversigt - Karl Wiegers 'Software Metrics: Ten Traps to Avoid' - jeg har fastholdt den engelske formulering for at undgå at miste nogen af betydningen ved oversættelse til dansk:

1. Lack of Management Commitment
2. Measuring Too Much, Too Soon
3. Measuring Too Little, Too Late
4. Measuring the Wrong Things
5. Imprecise Metrics Definition
6. Using Metrics Data to Evaluate Individuals
7. Using Metrics to Motivate, Rather than to Understand
8. Collecting Data That Is Not Used
9. Lack of Communication and Training
10. Misinterpreting Metrics Data

Jeg vil i et senere blogindlæg komme ind på de enkelte fælder.