Test af software skal kunne betale sig
Min overordnede tilgang er at omkostningerne til testaktiviteter under udvikling af ens software applikation skal stå i forhold til de risici for tab der kan være, hvis applikationen svigter under drift.
Det er her det gælder om at finde det rette “sweet spot”: Hvor meget vil man investere i forebyggelse af fejl og svigt inden applikationen sættes i drift kontra hvilke omkostninger man kan tåle ved svigt, når forretningen er blevet afhængig af applikationens funktionalitet.
Forklaring på “Sweet spot”-begrebet
A = B+C: (”Sweet spot”) Omkostninger ved kvalitet; Summen af udgifter til forebyggelse/opdagelse af fejl og udgifter ved svigt.
B: Udgifter til forebyggelse/opdagelse af fejl;
- Kvalitetsstyring
- Reviews
- Statisk test
- Dynamisk test
- Teststyring
C: Udgifter ved svigt;
- Analyse af forstyrrelser
- Rettelse af fejl
- Gentest og regressionstest
- Finansielle tab (f.eks. tab af markedsandel, bøder, produktionstab, m.m.)
- Image tab
Testmetoder
Test skal sammen med kunden forberedes og gennemføres på baggrund af løbende risikovurderinger helt fra forretningsniveau, hvor produktet med tiden forventes at fungere, og ned til de enkelte funktioner der er indlejret i og udgør det samlede produkt.
Test skal udføres i hele produktets levetid, fra vugge til grav, i en veltilpasset målestok, med et defineret formål og efter fornuftige processer.
Nogle organisationer har en generel testmetode, som i et vist omfang er fleksibel mht. indhold, men kan være strengt kontrolleret af dikterede processer. Det kan have sin relevans at teste sit produkt efter en sådan metode, hvis man ønsker at sende en raket til Mars med mennesker ombord eller hvis man har et farmaceutisk præparat til brug på mennesker. Der kan i stedet for menneskeliv være store værdier på spil, som man vil undgå at tabe, f.eks. i en bank eller en pensionsfond.
I disse tilfælde kan en generel testmetode efter en kendt model, måske endda reguleret ved lov, være en hensigtsmæssig fremgangsmåde for at imødegå uventede overraskelser.
I andre organisationer kan test efter en tilpasset eller skabt-til-formålet testmetode være tilstrækkeligt.
Formålet med at teste
Hvert produkt har sin helt egen karakter der defineres af en række egenskaber. Det medfører samtidigt at den test man ønsker at udsætte produktet for er nødt til at være tilpasset til formålet.
Det vigtigste formål med test er at man skal indsamle informationer nok til at kunne evaluere produktet og samtidigt nok til at lære produktet tilstrækkeligt godt at kende.
Derfor skal der ikke testes for lidt for så kan der komme for mange overraskelser senere. Der skal heller ikke testes for meget, da omkostningerne kan blive højere uden at man lærer mere om produktet og tiden indtil produktet kan tages i anvendelse kan blive længere end planlagt.
Værdien det giver at have en testmanager i hele projektet
Testmanagerens indsats sikrer en kvalificeret og struktureret håndtering af testaktiviteterne. Testmanageren etablerer en løbende fokusering på de kvalitetsmæssige egenskaber af produktet i projektet.
Testmanageren leverer informationer til ledelsen der gør det muligt at træffe de bedste beslutning i den givne situation ud fra en kvalitativ og objektiv status på produktets tilstand.
Testmanageren styrer testforløbene fra projektets start til aflevering af det endelige produkt og bidrager til at ledelsen kan fokusere på at styre projektet sikkert i det ønskede mål.
Case: transitionsprojekt
Jeg var projektdeltager med titel af Test Manager på et transitionsprojekt for en kunde hvis formål var en total flytning af eksisterende it-systemer og kunde- og virksomhedsdata til en ny software- og hardware platform hos en ny hosting partner. Projektet havde en forventet levetid på 18 måneder og et budget på 18 mio DKK.
Projektet endte med at bruge i runde tal ca. 1 mio DKK i hele projektets levetid på at forberede og gennemføre test løbende på delleverancer. Samtidigt havde projektet hensat ca. 2 mio DKK til reserver for det tilfælde at delleverancerne var fejlbehæftede, mangelfulde, forsinkede eller lignende.
Ud af 24 delleverancer blev der afleveret 24 til tiden. Der var ingen fejl eller mangler som forhindrede ibrugtagning af kunden og kunden oplevede efter ibrugtagningen få og mindre problemer, som kunne løses indenfor samme dag.
Projektet blev ikke pålagt dagbøder eller andre reklamationer. Kunden havde ingen produktionstab eller datatab.
Det var en god forretning at teste i projektet.
