En teststrategi skal være risikobaseret

Når jeg skal begynde på testarbejdet i forbindelse med et projekt, synes jeg tit, at det ser ret uoverskueligt ud. Jeg har fornemmelsen af at stå foran en hel bunke legoklodser og tænke: ”Hvordan får jeg hoved og hale på det her? Hvordan skal jeg gribe det an?”

Illustration: Privatfoto

Der er mange forskellige tilgangsvinkler eller strategier for test; men den ISO 29119 har valgt er heldigvis den, som jeg synes giver mest mening: den risikobaserede tilgang.

Den tilgang betyder, at man i sit testarbejde lader sig styre af den risikoprofil, der er for det produkt, man skal teste.

Produktrisici truer den forventede brug og lønsomhed af IT-Løsningen. Der kan f.eks. være en risiko for, at en Løsning ikke beregner et bestemt resultat korrekt, eller at Løsningen er alt for længe om at gennemføre beregningen.

En risikoprofil udarbejdes ved, at man deler produktet op i fornuftige områder, f.eks. kan man følge strukturen i kravspecifikationen, og beregner risikoeksponeringen for hvert område, og hvert områdes relative del af den samlede eksponering.

Testarbejdet planlægges herefter således, at alle områder berøres; men kun i forhold til deres risikoeksponering, så de ’farligste’ områder med størst andel af risikoeksponering testes først og mest, og de ’mindste farlige’ områder sidst og mindst.

Dette kan afspejles i en testorganisations overordnede teststrategi, som f.eks. kan omfatte følgende emner:

  1. Principper for risikostyret testarbejde

  2. Udvælgelse og prioritering

  3. Testdokumentation

  4. Testautomatisering og –værktøjer

  5. Konfigurationsstyring

  6. Hændelsesstyring

  7. Start- og slutkriterier

  8. Godkendelseskriterier

  9. Grad af uafhængighed

  10. Teknikker

  11. Testmiljø

  12. Måletal, der skal indsamle

  13. Gentest og –regressionstest

Hvor mange af disse emner er tænkt igennem og beskrevet i jeres organisation? Giver det – eller ville det give – mening?
Lad mig høre, hvad I mener.

Mange hilsner
Anne Mette

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

Dit artikel illustreret ganske tydeligt udfordringen med at bruge samme term - teststrategi - på to forskllige niveauer. Den overordnede teststrategi bør være statisk og forholde sig til hvordan organisationen håndterer testopgaven på tværs af projekter. En (rigtig) teststrategi, som typisk er en del af testplanlægningen, er vel der hvor man faktisk bruger risikoanalysen til definere rammerne for testen i de enkelte projekter.

Den korte version: I dit eksempel er den overordnede teststrategi ikke risikobaseret, den er baseret på en standard. Den rigtige teststrategi er derimod risikobaseret fordi ISO 29119 er valgt som standard for testorganisationen.

Endnu en god grund til at have en Test Håndbog fremfor en overordnet teststrategi til at håndtere statiske detaljer omkring "hvordan" test håndteres i en organisationen.

  • 0
  • 0
Anne Mette Hass

Hej Henning,

Begge strategier, både den overordnede og den projektspecifikke (som du kalder 'den rigtige'), skal have et indhold, der er rettet mod risikonedsættelse.
Jeg har kun forholdt mig til overskrifter i den overordnede strategi, og disse er ganske rigtig fra ISO 29119. Det kan overskrifterne i den projektspecifikke strategi også være.
Indholdet i den overordnede strategi baserer sig på organisationens overordnede holdning til risikohåndtering, mens indholdet i den projektspecifikke strategi og i plan baserer sig på projektspecifikke produktrisici.
Sådan går det hele op.
Venlig hilsen
Anne Mette

  • 0
  • 0
Jan Andersen

Det er et rigtigt spændende emne. Som med al anden kvalitetsstyring findes der ingen præcis manual til hvordan det skal gøres, men en lang række "gode intentioner" som bør give anledning til at overveje, hvordan man bedst implementerer i lige præcis ens egen sammenhæng.
Begrebet "risiko" kan her måske fremstå en anelse snævert defineret. Hvis mit produkt har fx 1.000 funktioner, så kan jeg, hvis jeg frigiver nye releases hver måned, naturligvis ikke teste alle funktioner lige intensivt. Og bør heller ikke gøre det. Tværtimod bør jeg lave en liste over alle mine funktioner og tildele dem alle en score der er baseret på:

  1. Funktionens vigtighed i produktet (for kunden)
  2. Hvor stor er konsekvensen (for kunden) hvis funktionen fejler
  3. Hvor følsom er funktionen - groft sagt hvor mange variable forhold der påvirker funktionen

Dette vil jeg opfatte som den enkelte funktions risikoprofil.

Hvis alle funktioner scores på disse 3 parametre, vil du stå tilbage med en liste - en kontrolplan - hvor det er ret tydeligt, hvordan din indsats skal fordeles.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize