Blog

A Practical Guide to Testing in DevOps

Katrina Clokie har udgivet en e-bog der handler om test af software i et DevOps setup.

Nu vil jeg ikke forsøge mig med at anmelde bogens indhold, det er der flere andre der har gjort (se linket ovenfor).

Jeg vil nævne at det er en bog med god inspiration til dig, der skal finde dine ben at stå på i DevOps som tester. For selvom DevOps flere steder er beskrevet som om der næsten ikke findes test (ligesom i flere andre rammeværk, f.eks. SAFe), så bliver der stadig testet på livet løs. Og ja, dine færdigheder indenfor testfaget er der stadig brug for, blot i en lidt anden kontekst.

Det var en fornøjelse for mig at læse den og jeg blev klogere på test i DevOps.

Test Management tool

Når jeg arbejder med test i projekter er gode værktøjer vigtige for hvor effektivt jeg selv kan arbejde, men specielt også for hele test teamets success med at opsamle den dyrebare information der findes under test processen.

Mit favorit test management værktøj for tiden er Testrail fra Gurock.com. Efter min mening er det et fornuftigt kompromis mellem tilgængelighed, integrationsmuligheder, funktionalitet og pris.

Skab værdi med test

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.

Omkostninger ved kvalitet versus kvalitetsniveau

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.