Dette indlæg er alene udtryk for skribentens egen holdning.

En teststrategi skal være risikobaseret

26. september 2013 kl. 13:203
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

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?”

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.

Artiklen fortsætter efter annoncen

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

3 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
3
27. september 2013 kl. 23:37

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.

1
27. september 2013 kl. 13:18

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.

2
27. september 2013 kl. 15:38

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