Fra produktrisiko til en risikobaseret teststrategi

Hører du tit sætninger som ”vi laver risikobaseret test”, læser master testplaner, hvor der står en eller anden variation af det samme, men når du kigger på den test, der bliver gennemført, så er det ikke noget, der gennemsyrer aktiviteten? Der er med andre ord ingen rød tråd fra det, der står i teststrategien, til den test, der er blevet specificeret og afviklet, og det endda selvom man kan se, der er blevet lavet en produktrisikoanalyse.

Produktrisikoanalyse har jeg allerede talt om i to tidligere artikler, du kan finde her:

Produktrisikoanalyse i en agil kontekst
Produktrisikoanalyse

Se desuden denne video, hvor jeg fortæller om risikobaseret teststrategi.

Men produktrisikoanalysen er jo kun første skridt på vejen, derefter skal der fastlægges en teststrategi der bedst muligt adresserer de risici der er identificeret, og sidst men ikke mindst så skal der designes og specificeres test der udlever teststrategien. De aktiviteter, der gennemføres i projektet omkring test og kvalitetssikring, skal alle støtte op om opgaven med at mitigere risici.

For at dette kan ske i praksis så er der et par punkter der skal være på plads:

1. Alle kender til resultatet af produktrisikoanalysen
2. Testplanlægning gennemføres på basis af PRA. Det betyder at den intensitet vi planlægger og designer test med, skal matche den risiko den addresserer
3. Valg af testdesignteknikker til testdesign sker på basis af teststrategien, altså på basis af den produktrisiko de skal mitigere
4. Prioriteringen af testafviklingen skal afspejle risikobilledet – højest risiko testes først

Punkt 1 har jeg allerede adresseret i tidligere artikler, så lad os springe videre til punkt 2.

Fra produktrisiko til teststrategi

Med gennemførelsen af produktrisikoanalysen har du grundlaget for din teststrategi i form af en tabel der ser ca. sådan her ud:

Du har med andre ord identificeret testmål, fundet ud hvilke kvalitetsattributter der er relevante for dem, og har vurderet dem ud fra konsekvens og sandsynlighed – og derfra udledt risikoklassen. Men at du har en række med ABC er jo ikke rigtig tilstrækkeligt ? så næste punkt er at komme fra disse til en egentlig strategi. Første punkt i den forbindelse er at identificere hvilke testniveauer (eller testaktiviteter hvis du er agil og ikke vild med det andet mere traditionelle begreb) der bør være i dit projekt. Unit test er givet (håber jeg) men udover det så kunne det f.eks. være systemtest, systemintegrationstest, brugeraccepttest osv. Altså testaktiviteter med hvert sit fokus. Uanset om du er i et traditionelt eller agilt projekt vil du jo have forskellige aktiviteter, og det kan jo også være din kontrakt siger noget som måske ligger udenfor det du synes er ”rigtig agilt” – f.eks. en formel brugeraccepttest, en overtagelsesprøve eller en driftstest, men også de forskellige testaktiviteter som du finder i de agile testkvadranter.

Du sætter hver af de identificerede aktiviteter op i tabellen, en pr kolonne – og gerne i ca. den rækkefølge du forventer at de gennemføres i (unittest, systemtest, accepttest f.eks.). og så kommer vi til det svære; nu skal du for hver kombination af testmål og kvalitetsattribut identificere hvordan du bedst muligt adresserer den. Hvor skal der være mest test (=højest intensitet)?

Det kan være svært at få hul på denne del, hvor er det smartest at lægge den høje testintensitet. Her er der et par gode tommelfingerregler at have med:

1. Adresser risici så tidligt som muligt.
2. Højeste intensitet og dermed testfokus bør ligge inden accepttest med slutbrugere, det er for sent at mitigere risici når du står med dem.

Arbejdet med at identificere den bedste måde at mitigere det risikobillede der blev identificeret i forbindelse med PRAen skal du naturligvis ikke sidde alene med. Et forslag kunne være at du laver et oplæg til hvordan du mener det skal adresseres, og så vender du det f.eks. med en arkitekt eller en lead udvikler. Dette for at få indspark i forhold til især den tekniske del af testen. Det kan jo godt være du gerne vil have højest intensitet på unit test niveau for at adresserer risici så tidligt som muligt, men hvad nu hvis det er en performance risiko der først for alvor kan adresseres som en del af systemtesten. Så det er en god ide at sparre med nogen med den dybe indsigt i hvad der er muligt tæt på koden.

Så langt så godt, nu har du en ide om hvornår hvad skal testes hvor meget ? men der mangler en væsentlig del; hvordan? Hvordan skal testeren/teamet oversætte de der prikker til en eller anden form for dækning eller tilgang til test?

Leo Van der Aalst beskriver i sin artikel ”Test design was not invented to bully the testers”  fordelen ved brug af testdesignteknikker, men har også en fin matrice baseret på TMap metoden der giver indsigt i hvilke teknikker der er bedst ved hvilken intensitet. Det handler om at få tilstrækkelig dækning, ikke for meget og ikke for lidt. Måden den benyttes er at du identificerer hvilken kvalitetskarakteristik du skal teste med hvilken intensitet, og kan så finde den celle i tabellen hvor forslag til teknikker er listet. F.eks. hvis du skal teste funktionalitet detaljeret med en intensitet på 2 ”**” så er oplægget at du bruger en af teknikkerne DCoT-pairwise testing (Data Combination Test), ECT-modified condition/decision coverage (Elementary Comparison Test) eller exploratory test (ET). For et indblik i disse teknikker kan du besøge tmap.net – hen ad vejen vil vi besøge en række af teknikkerne på vores blog og/eller videos, Annemette Clement er vores 100-meter mester udi disse ?

I den overordnede teststrategi skal testmanageren IKKE bestemme i detaljen hvilken teknik der skal bruges hvor, du giver et antal teknikker ud fra matricen, men der er ingen tvivl om hvem der i sidste ende beslutter hvilken teknik der benyttes – det gør den person der i detaljen kender til opgaven og derfor kan vurdere hvilken er den bedste, med andre ord testeren.

Nu kan jeg umiddelbart forestille mig mindst to indvendinger:

1. Mine testere kan ikke testteknikker så det giver ikke nogen værdi at lave produktrisikoanalysen
2. Vi er agile så vi laver ikke produktrisikoanalyse.

Med hensyn til den med testteknikkerne; En produktrisikoanalyse tegner et fælles billede af hvad det er for en testopgave vi står overfor, det er vigtigt uanset om testerne/teamet kan teknikker eller ej. Du kan stadig give dem en rettesnor for hvor meget test der skal specificeres og afvikles udfra en række tommelfingerregler som f.eks.;

Ovenstående er blot ment som et eksempel på hvordan du kan benytte output fra din produktrisikoanalyse til at give en række tommelfingerregler for hvad der skal testes, definer dem der passer til din kontekst.

Nu har testerne et grundlag for deres test specifikation, men de skal naturligvis i detaljen beslutte hvordan de bedst muligt adresserer de risici der er identificeret.

Når det så er sagt så kan jeg kun anbefale at i som team bruger lidt kræfter på at sætte jer ind i som minimum de mest basale testteknikker, jeg er sikker på at i vil finde værdi i dette ikke kun ud fra et testmæssigt perspektiv men også ud fra et behov for at forstår forretningens behov, finde strukturerede men ikke tungt dokumenterede metoder til at fastholde disse og ikke mindst til at visualisere hvad det er systemet skal kunne.

Med hensyn til punkt to, så vil jeg tillade mig at henvise til tidligere artikel samt video om hvordan man får produktrisikoanalysen integreret i den agile måde at arbejde på. Risikopoker kan sagtens køres videre i forhold til ovenstående beskrivelse af identifikation af teststrategi. I nedenstående har jeg simplificeret strategitabellen ud fra den device at man ikke taler om test niveauer i agile, men du kan selvfølgelig stadig bruge det lige som du har lyst til – der er ingen silver bullet, gør det der virker bedst i din kontekst.

En lille advarsel i forhold til nedenstående. I Tmap har man vist dette eksempel til den agile kontekst, men pas på ikke KUN at have fokus på userstories, tænk også på produktrisici i forhold til featuren og til systemet som helhed – de skal også adresseres.

Hvis vi genbesøger den løsning jeg beskrev i artiklen med udgangspunkt i PRISMA, så kan du også her finde en letvægtsmetode til at dokumentere teststrategien, du skal simpelthen ”bare” udvide din graf en lille smule.

Denne tilgang er meget visuel, især hvis du får den tegnet på flipover eller andet så den faktisk kan hænge på væggen i teamets område, er I ikke sammen må den selvfølgelig laves elektronisk men så fastholdt et sted hvor teamet kommer. (med andre ord ikke i word ?)

Når man går i gang med en ny feature så genbesøge produktrisikoanalysen og dermed teststrategien. Der kan være sket ændringer med scope, både at man har skåret i featuren men også den modsatte vej (scope creep), så det kan være nødvendigt at ændre/tilføje risici. Dermed kan der også være behov for at ændre i den relaterede teststrategi så vi har rette grundlag for det videre arbejde. Dette er et arbejde som testeren/teamet som udgangspunkt gør som en integreret del af testforberedelserne, det kræver ikke genkørsel af PRA eller større bureaukrati, bare at man tager stilling og agerer i forhold til det nye billede.

Nu har I en risikobaseret teststrategi, men husk nu punkt 4 fra tidligere ”Prioriteringen af testafviklingen skal afspejle risikobilledet – højest risiko testes først”; det er ikke nok at specificere den rette test, du skal også sikre, at I har det rette fokus, når I afvikler testen.