rikke simonsen bloghoved

Test skal baseres på risikovurderinger

Dette års testkonference arrangeret af DSTB havde temaet “Fra teori til praksis”. Det var en velbesøgt konference med 250 deltagere, 2 keynotes og 4 mulige spor.

Første keynote var Erik van Veenendaal med oplægget “Building on Success - Beyond the Obvious”. Han lagde ud med paradokset, at meget få IT virksomheder har en fungerende praksis for reviews eller test automatisering, og alligevel lykkes det for dem at release og drive en succesfuld virksomhed.

Så en ting er, hvad der i teorien defineres som must do og best practice, og som mange af os forsøger at leve op til. En anden ting er, hvad vi rent faktisk gør og behøver at gøre ude i den virkelige verden.

Jeg har i denne blogpost taget udgangspunkt i Eriks oplæg, der gav en god ramme for mange af de andre oplæg, der var på konferencen, og som behandlede nogle af de mest grundlæggende kompetencer, man bør bestride inden for test.

5 anbefalinger

Erik introducerede os til 5 grundlæggende anbefalinger, som han mente var de vigtigste i forhold til test:

  1. Test skal baseres på risikovurderinger
  2. Brugen af reviews skal være begrænsede men effektive
  3. Unit testing er et whole team approach
  4. Introducer en test design fase
  5. Invester i mennesker

Det er altså muligt at komme rigtig langt i sin kvalitetssikring uden at reviewe hver eneste dokument og kodestump eller ved at automatisere alle sine test. Sund fornuft, gode afvejelser og de rigtige mennesker har langt større betydning.

Risikovurderinger

Det er ikke nyt at test bør tage udgangspunkt i risikovurderinger. Det mange måske ofte glemmer er, at det er kunden, der skal tage vurderingen og ikke os som testere eller udviklere. Selvfølgelig kan vi vejlede, men i sidste ende er det kunden der ved, hvorvidt det har lille eller stor betydning for forretningen hvis en bestemt hændelse indtræffer.

Risk Matrix

Erik præsenterede os for, hvordan man ved hjælp af en risk matrix nemmere kunne få overblik over hvilke risici, der skulle adresseres først. Det er ikke muligt at teste alt, så der må prioriteres. En risk matrix er et koordinatsystem, hvor den ene akse er sandsynligheden for at et hændelse indtræffer, og den anden akse er effekten.

Ved ikke bare at vedligeholde en risikolog men plotte dem ind i koordinatsystemet, bliver det hurtigt visuelt, hvilke risici der har størst sandsynlighed for at indtræffe og som samtidig vil have størst negativ indvirkning. De vil i et sådant koordinatsystem ligge i øverste højre kvadrant. Man kan herudfra så prioritere hvilke issues, der skal adresseres først og hvordan.

Test reducerer ikke risici

Klaus Jørgensen fra Delta holdt et særskilt oplæg om risikobaseret test, og om hvordan det er eller snarere ikke er en risikoreducerende aktivitet. Hovedpointen var, at risikobaseret test ikke i sig selv reducerer risici i projektet.

Test frembringer viden om risiciene, det afhjælper dem ikke. Det kræver, at der er nogen, der agerer på den frembragte viden for at risiciene reduceres.

Estimering af risici

Klaus havde også den gode pointe, at vores risici som udgangspunkt var ukendte - for vi kender ikke sandsynligheden for at en hændelse vil indtræffe. Den er baseret på et estimat. Jo mere viden og erfaring vi har, feks. historik jo bedre.

Sandsynligheder bør udtrykkes i procenter. Fordelen ved dette er, at man begynder at lede efter tal og oplysninger, der kan hjælpe en med at estimere istedet for at man falder i fælden med blot at konkludere, at sandsynligheden for at hændelsen indtræffer er “meget sjælden”.

Effekten af at hændelsen indtræffer bør angives på en åben skala - og ikke som mange gør - på en skala fra 1 til 5. På den måde er det altid muligt at indplacere en hændelse relativt i forhold til de andre. Enheden skulle være kroner og øre - for det er i sidste ende hvad det vil koste virksomheden at en hændelse indtræffer, der har betydning.

Næste blogpost - Reviews

I næste blogpost vil jeg tage udgangspunkt i Eriks anden anbefaling om begrænset - men målrettet - brug af reviews.

Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Henrik Gammelgaard

Hej Rikke,

Du har en pointe i at man til tider skal traeffe risikobaserede beslutninger vaegtet ift. omkostninger for forskellige stakeholders; der er dog en svaghed i at indfoere sandsynligheder som du plaederer for, og det er impact af en given haendelse du ikke kan forudsige.

Som Donald Rumsfeld kaldte dem, the unknown unknowns, 'black swans', og hvilken impact de vil have - jeg vil mene at god test og de rigtige indsatser her kan vaere med til at mitigere effekten af disse. Du kan have en pointe i at kunden her skal bestemme, men det kan man overlade til 'eksperter' (testerne), lige saa vel som at kunden heller ikke bestemmer praecist hvilke linier kode du skal skrive (hvis dette er besluttet allerede er koden naermest pr def allerede skrevet). Hvis du er nitpicky saa vil ud mente at helt rigtige unknown unknowns aldrig kan fanges, og det er korrekt - men jeg vil mene at meget at det vi ser som usandsynligt reelt ikke er.

Ift. unit testing og reviews, saa kan du sige at de kan fange known knowns - hvilket stadigvaek er uendeligt vigtigt - da det groft sagt enabler dig til at fejle hurtigere naar du f.eks. refactor. Min erfaring er at et niveau med -meget- hoejt code coverage goer at du har mindre risiko ved f.eks. deployments, men det siger intet ift. om det rent faktisk er det rigtige du har bygget (ergo loeser du det faktisk problem)

Log ind eller Opret konto for at kommentere