Et af de rigtig vigtige værktøjer i en risikobaseret tilgang til test – og til at forstå det risikobillede der tegner sig for et givet produkt, er produktrisikoanalysen (PRA). For nyligt lagde jeg en lille video op for at give en lynintroduktion til emnet, men jeg tænkte det måske kunne være godt at putte lidt flere ord – og billeder på.
Hvorfor skal vi lave en produktrisikoanalyse?
Hvis vi nu antog at vi havde al den tid og alle de ressourcer vi skulle bruge til at teste en applikation, så kunne vi jo ”bare” teste alt lige meget – og teste i bund (selv om man pr definition ikke kan teste ALT). Men det er vist ikke den verden ret mange af os befinder os i. Der er begrænsninger på de ressourcer vi har til rådighed, og der er begrænsninger på kalendertid. Derfor så er vi hele tiden nødt til at lave den gode prioritering; hvor skal vi lægge den største indsats, hvor kan vi teste mindre – og ikke mindst med hvilket fokus skal vi teste?
Vi skal altså definere og implementere den bedst mulige teststrategi indenfor de rammer vi er blevet givet. PRA’en er en helt essentiel brik i den forbindelse, som grundlag for at definere projektets eller teamets test strategi, og dermed fundamentet for at kunne definere og implementere en risikobaseret tilgang til test. Uden den kan vi reelt ikke vurdere hvor vi skal lægge indsatsen i testen, og hvad der skal have mest fokus.
Samtidig er PRAen med til at give et fælles billede i forhold til risici, det er ikke kun for test at den giver værdi. Den kommunikation vi har når vi gennemfører en PRA, uanset vores udviklingsmodel og metode for PRA, er essentiel for at skabe et fælles billede af hvad det er vi står overfor. Hvor skal vi have vores fokus.
Det kan nogle gange skabe lidt forvirring når vi taler om produkt risici, idet mange kun er vant til at fokusere på risici relateret til projektets succesfulde afvikling, altså projektrisici. Det er vigtigt at have et fælles billede af forskellen på de to.
Projektrisici er i forhold til projektets succesfulde afvikling, når vi i mål som planlagt, hvad hindrer os i det? F.eks. om testmiljøet bliver klar, om vi har de nødvendige kompetencer osv.
Omvendt så er Produktrisici i forhold til produktets kvalitet – det vi leverer til kunden. Hvad er kritisk for brugerne, hvad er svært at lave – vi kigger altså på det forventede slutprodukt
Men brugt rigtigt så er en produktrisikoanalyse et utroligt vigtigt værktøj at have i værktøjskassen, ikke kun som testmanager eller tester – men for hele teamet.
Hvornår laver man en PRA?
Det næste er så hvornår du skal lave en PRA, og det er kan reelt være både i starten af projektet, i starten af en release, i starten af sprint eller måske når i skal i gang med en ny feature – så den kan give værdi på mange forskellige tidspunkter med mange forskellige detaljeringsgrader.
- Når projektet starter (eller når det agile release train starter op … eller det agile team etablerer starten på en backlog) så er det lidt i helikopter perspektiv vi laver en PRA, vi kigger på den samlede opgave overordnet i forhold til den viden vi har (kravgrundlag, kontrakt etc)
- For en enkelt release, eller for et program inkrement eller et sprint går vi lidt mere i detaljen. Kigger på scopet i den kontekst, og her ved vi gerne lidt mere omkring detaljerne og kan bryde product risici ned og gøre dem mere konkrete.
- For en enkelt feature eller story. Nu er vi helt nede i materien – her er vi allermest konkrete. Vi har udelukkende fokus på scope for den givne feature/story og hvad den måtte påvirke, vi kan blive mere detaljerede og kan mappe det direkte mod den udviklings- og testopgave der følger efter.
Hvem skal med til en PRA?
Når du skal i gang med at facilitere en produktrisiko er det vigtigt at have forskellige interessenter med, det vil sige deltagere med forskellige perspektiver på den enkelte produktrisiko.
Dels selvfølgelig interessenter med forretningsperspektivet der har indsigt i den reelle brug af systemet så de kan vurdere hvad konsekvensen af en fejl i en givet del af systemet vil være forretningen. Men også interessenter fra IT der har indsigt i kompleksiteten af det system der skal udvikles, modenheden af den eksisterende arkitektur og selvfølgelig også kompetencer og erfaring i teamet.
Og så skal vi selvfølgelig ikke glemme testeren i denne forbindelse. Hun kan reelt have viden i forhold til ”begge sider” – en erfaren tester har som regel en del forretningsviden og vil kunne give indspark til brugen af systemet, men har også erfaringer fra test af systemet til at vurdere hvor det ofte går galt, hvor fejl potentielt plejer at hobe sig op.
Hvordan laver man en PRA?
Der er mange forskellige metoder til at lave PRA, for mig er det ikke så vigtigt hvilken du bruger – bare du gør det og tager den sammen med dit team. I det følgende giver jeg en introduktion til en af de metoder jeg selv har brugt rigtig meget gennem årene, jeg vil senere supplere med lidt inspiration til den agile kontekst.
Jeg har som regel lavet lidt hjemmearbejde og har f.eks. oplæg til en eller anden form for nedbrydning af opgaven, måske i features, i funktionelle områder eller lignende. Men denne nedbrydning er ikke hugget i sten, den kan til enhver tid tilpasses så den dækker det billede som deltagerne har f opgaven. Det er udelukkende ment som en hjælp til at få diskussionen i gang, det er så meget nemmere end baseret på et tomt whiteboard.
Listen diskuteres og tilrettes til man er enig om at dette er scope. Derefter skal vi i gang med næste del – at identificere hvilket perspektiv i forhold til de enkelte punkter som skal have fokus. Her mener jeg, er det f.eks. funktionalitet der er centralt i nedbrydningen – selve den funktionalitet der bliver stillet til rådighed? Eller kunne det være vigtigt hvordan performance er? Er der nogen utalte krav? Er der en bekymring i forhold til dette? Husk at de nonfunktionelle kvalitetsattributter ofte er de der bliver fokuseret mindst på, men som kan have en voldsom effekt hvis de fejler.
Så for hvert punkt på listen afklarer vi hvad der er i fokus. Jeg står ikke med hele listen fra ISO-standarden, der er rigtig mange og det giver ikke værdi. Ofte har jeg kigget lidt i kontrakter, krav, featurebeskrivelser, diskuteret lidt med arkitekten mv – og måske nået til en liste på 4-5 stykker. For det meste er funktionalitet, performance, sikkerhed og brugervenlighed givne. Dertil kan så komme andre i henhold til konteksten.
Nu har vi så en liste af ”testmål”, og for hvert af disse har vi en indikation af hvilke kvalitetsattributter der er vigtig. Så kommer vi til den sværeste del, vurderingen af hvor alvorlige disse er, hvad risikoklassen er for hver enkel kombination.
Her vælger jeg som regel at tage et fokus ad gangen. Først er det forretningen der primært har ordet, for vi starter med at kigge på konsekvens. Hvad er konsekvensen for forretningen hvis der identificeres en alvorlig performance fejl i feature X i produktion. Angiv High-medium eller low (eller er i mere til tal så bruger du selvfølgelig bare 3-2-1). Forretningen diskuterer og sætter ord på hvorfor de vælger f.eks. high. Vi arbejder os gennem alle testmål/kvalitetsattributter med forretningsfokus, et ad gangen. IT er som hovedregel stille i dette forløb, vi forventer at det er forretningen der har denne indsigt, men der kan selvfølgelig stilles afklarende spørgsmål ligesom at har man en viden om f.eks. en work around som den pågældende forretningsrepræsentant ikke har, så skal man selvfølgelig flage det.
Når vi er igennem listen, skal IT på banen, og nu er det forretningen der sidder stille ? Nu skal vi nemlig diskutere sandsynligheden for at risicien indtræffer. Er det en meget kompleks kode? Er vi inde og skal tilføje noget til et eksisterende modul som tidligere har givet mange problemer? Er det en helt ny platform? Er det piece of cake fordi vi har lavet noget lignende i forrige release som bare skal tilpasses? Igen diskuteres og afklares.
Facilitatoren har en meget vigtig rolle her! Nogle gange oplever man at ALT er High, så er det vigtigt at vi tager diskussionen ”jamen er det her punkt lige så ”High” som det tidligere? Prøve at få nuanceret klassificeringen.
Efterhånden som i når ned gennem listen så har du altså to punkter for hver risici – en konsekvens og en sandsynlighed. For at udlede risikoklassen som er det vi skal bruge til det efterfølgende arbejde med teststrategien har du to muligheder, alt efter om du valgte High/medium/low eller 3/2/1.
Med det første har du en matrice du kan bruge til at udlede risikoklassen. Nedenstående er en standardmatrice defineret på basis af erfaringer på tværs af brancher, men hvis du f.eks. har en kontekst der kræver højere sikkerhed (life-science, space osv.) så tilretter du naturligvis bare matricen til den kontekst gennem at hæve risikoklasserne så f.eks. også medium konsekvens/sandsynlighed er A og der måske slet ikke er nogen C – den diskussion skal du tage med din forretning.
Hvis du bruger tal i stedet for High-medium-low (3-2-1) så kan det gøres hurtigt ved at gange de to tal med hinanden.
Når man er nået gennem listen på denne måde, har man et billede af risikoprofilen på sit scope – alle punkter har nu en risikoklasse tilknyttet.
Her er det ofte værd at bruge lidt tid på at kigge det igennem i sin helhed, når deltagerne ser risikoklasserne i forhold til hinanden, kan det godt give lidt anledning til yderligere diskussion, og måske også en re-klassificering.
Dette er produktrisikoanalysen. Med basis i den kan vi nu gå i gang med at udlede den bedst mulige teststrategi. Det vil sige hvilken intensitet af test skal gennemføres ved hvilke testaktiviteter. Og når du er nået så langt, så har du givet teamet og testerne et stærkt værktøj i hånden, for den testintensitet giver nemlig dem et vigtigt indspark i forhold til hvilken testteknik de skal bruge, hvordan de bedst muligt skal mitigere risikoen.
