Risici har, hvis de materialiserer sig, en negativ indvirkning på vores projekter. Risikostyring handler om at overveje, hvilke risici der findes, og træffe foranstaltninger for at reducere sandsynligheden for dem, eliminere dem eller begrænse deres indvirkning på vores interessenters mål.
I nogle virksomheder praktiseres risikostyring med ingeniørmæssig og matematisk præcision. Inden for software er det ikke muligt at være særlig præcis. De fleste organisationer praktiserer stadig ikke risikobaseret test systematisk. Men der er en god grund til dette: Når produktrisici i software først er identificeret, er de ofte utrolig svære at vurdere.
Set fra test- og kvalitetssikringsperspektivet er en risiko en ”fejltilstand, man bør være bekymret for”. Risikobaseret test er praksissen med at modellere potentielle fejltilstande i et system som produktrisici for at understøtte afgrænsning, skalering og prioritering af test.
I denne artikel vil jeg præsentere et manifest for risikobaseret test. Vi ser på klassisk risikostyring og på, hvordan vi kan tilpasse den, så den bliver nyttig for testere. Til sidst ser vi på nogle praktiske forhold og overvejelser, der kan hjælpe dig med at anvende din egen metode til risikobaseret test.
- Projekt-, proces- og produktrisici
- Et manifest for risikobaseret test
- Den klassiske tilgang til risiko
- Produktrisiko og test
- Praktiske forhold
- Forståelse af testens rolle i risikostyring
Projekt-, proces- og produktrisici
Der findes hundredvis af bøger om risiko og risikostyring, som beskriver talrige tilgange til styring af risici på projektniveau. Typisk fokuserer disse tilgange på det, vi vil kalde projekt- og procesrisici, måske med en enkelt risiko med en titel som ”manglende opfyldelse af krav”. Det er ikke særlig nyttigt at have én enkelt kravrisiko, eftersom det ikke er sådan, at man kan prioritere én risiko til test.
Der findes tre typer softwarerisici.
Projektrisiko: Disse risici vedrører projektet i dets egen kontekst. Projekter har normalt eksterne afhængigheder såsom adgang til de nødvendige kompetencer, afhængighed af leverandører, faste deadlines eller begrænsninger såsom en fastpriskontrakt. Eksterne afhængigheder er projektledelsens ansvar.
Procesrisiko: Disse risici vedrører primært projektets interne forhold, og projektets planlægning, overvågning og styring bliver undersøgt. Typiske risici her er undervurdering af projektets kompleksitet, indsats eller de nødvendige kompetencer. Den interne styring af et projekt, såsom god planlægning, overvågning af fremdrift og kontrol, er alt sammen projektledelsens ansvar.
Produktrisiko: Produktrisiko er det primære risikoområde, som testere beskæftiger sig med. Disse risici vedrører definitionen af produktet, kravstabiliteten (eller manglen på samme), produktets kompleksitet og teknologiens fejlbehæftede karakter.
Fra nu af fokuserer vi på produktrisici. Vi vil bruge betegnelsen produktrisiko på følgende måde:
Et manifest for risikobaseret test
I projekter, hvor der vil blive taget risici (hvilket vi mener gælder for dem alle), skal testere synliggøre risiciene for ledelsen og foreslå pålidelige testmetoder til at håndtere disse risici gennem hele projektet.
Dette er ledelsens opgave – at udføre og/eller føre tilsyn med følgende risikobaserede testopgaver:
Den klassiske tilgang til risiko
Der findes mange variationer, men den klassiske tilgang til risiko forsøger at være kvantitativ.
Have an account? Log In
Sandsynlighed, konsekvens og eksponering
For at vurdere en produktrisiko er vi nødt til at forstå, hvad konsekvensen af denne fejltilstand er. Hvis der opstår en fejl, siger vi, at risikoen materialiserer sig. Derefter spørger vi: “Hvor alvorlig er risikoen?”, hvilket ellers omtales som eksponering.
For at beregne eksponeringen vurderer vi risikoen ud fra to dimensioner:
- Sandsynligheden for, at en risiko materialiserer sig. Denne værdi angives typisk som en procentdel mellem (men ikke inklusive) nul og 100 procent.
- Konsekvensen (eller påvirkningen eller tabet) af, at en risiko materialiserer sig. Dette er de potentielle omkostninger ved skaden, hvis denne fejltilstand opstår.
Eksponeringen for en risiko – hvor alvorlig en risiko er – beregnes som produktet af sandsynligheden og konsekvensen.
Den klassiske tilgang til risiko mangler ofte den teknologiske understøttelse, der er nødvendig for effektiv styring. Moderne teststyringsløsninger udfylder dette hul ved at tilbyde funktioner, der er skræddersyet til risikobaseret test.
Kvantitativ eller kvalitativ vurdering
Det er ofte vanskeligt at forudsige de potentielle omkostninger ved en fejl. Uden yderligere oplysninger er det også næsten umuligt at forudsige sandsynligheden for en fejl med særlig stor sikkerhed. Derfor anvender de fleste fagfolk semi-kvantitative eller kvalitative skalaer for sandsynlighed og konsekvens.
Det er almindeligt at bruge numeriske intervaller fra et til fem for begge skalaer, hvilket giver os mulige eksponeringsværdier fra et til femogtyve. Men få testere, udviklere eller interessenter tildeler disse tal med nogen sikkerhed, så det er almindeligt blot at bedømme risikoeksponeringen direkte ved hjælp af en skala fra 1 til 5 eller – endnu enklere – en rød, gul, grøn-vurdering. Nogle går så langt som blot at sige, at risici er inden for eller uden for omfanget, men vi vil mene, at dette er en for stor forenkling.
Uanset om du kvantificerer risiciene eller bruger farvekoder til dem, er det afgørende ved risikovurderinger ikke selve vurderingen, men de samtaler og den debat, der opstår, når du tildeler og diskuterer vurderingerne.
Hvis du bliver bedt om at vurdere risici med større præcision end skalaer fra et til tre (eller fem, hvis det virkelig er nødvendigt), bør du alvorligt overveje, om de tal, du tildeler, har nogen reel værdi.
Numerisk vurdering kan give et indtryk af videnskabelig stringens, men hvis tallene er gætterier, narrer du dig selv. Hvis tal afslører forskelle i opfattelse, f.eks. at en bruger siger “fem”, og udvikleren siger “et!”, er der grundlag for en samtale, fordi forventningerne eller opfattelserne tydeligvis er forskellige.
Pas på med at bruge en simpel ordning, hvor risici enten er inden for eller uden for omfanget. Det kan være tydeligt, hvilke bekymrende risici der skal håndteres gennem test. Projekter udvikler sig imidlertid over tid og bliver ofte forsinkede, så der må indgås kompromiser. Hvis risici ikke prioriteres på en eller anden måde, bliver du nødt til at gennemgå alle bekymrende risici for at afgøre, hvilke der eventuelt skal fjernes fra eller tilføjes til omfanget.
Vi vil diskutere afgrænsning, prioritering og skalering mere detaljeret i efterfølgende artikler, så følg med.
Produktrisiko og test
Diskussionen af (produkt)risici vil afdække interessenternes frygt for sandsynligheden for fejl i kritiske områder af projektet eller systemet. Når vi har en liste over produktrisici, hvordan omsætter vi den så til handling og konkrete testplaner? Før vi kan besvare det spørgsmål, er vi nødt til at forstå lidt bedre, hvordan test påvirker eller indvirker på vores risikovurderinger.
Test reducerer ikke risiko – den informerer risikovurderinger
Du vil ofte høre folk sige, at “test reducerer risiko”. Det er ikke sandt — test kan nogle gange øge risikoen. Mantraet om, at test reducerer risiko, udspringer af en manglende forståelse af både risici og test.
Lad os sige, at vi har identificeret en risiko for, at en funktion eller funktionalitet kan svigte. Vi udformer en test og kører den. Testen kan bestå eller mislykkes. Hvordan vil en bestået eller mislykket test påvirke vores risikovurdering?
For det første har test ingen indvirkning på vores forståelse af konsekvensen af en fejl. Konsekvensen af en fejl er, hvad den er, og test ændrer ikke på det.
Der er fire relevante testresultater og deres indvirkning på risikosandsynligheden. De er opsummeret i denne tabel:
| Risikosandsynlighed stiger | Risikosandsynlighed falder | |
| Test består | Nej. En bestået test kan kun få os til at føle os mere sikre på, at en fejltilstand ikke vil opstå. (Dette forudsætter, at vores tests er meningsfulde). | Ja, med tiden. Efterhånden som vi kører flere og flere tests, der består, og udforsker forskellige scenarier, mindskes sandsynligheden for fejl. |
| Test mislykkes | Muligvis, afhængigt af fejlen. Men sandsynligheden falder over tid. Vi forudsagde, at denne fejltilstand ville opstå; vores valg af test er blevet bekræftet. Heldigvis kan vi rette dette nu og fokusere vores test på at reducere risikoen for andre fejl af denne type. | Ikke sandsynligt, medmindre vores risikovurdering var forkert. |
Ved at køre tests, som vi forbinder med en bestemt risiko, får vi stadig flere oplysninger, der kan forbedre vores risikovurdering. Hvis tests mislykkes, er vores valg blevet bekræftet. Når vi retter fejlen og tester igen, bør vores risikovurdering falde, efterhånden som tests består. Men hvis vi bliver ved med at finde nye eller flere fejl, kan vi revurdere risikoen som højere.
Nu hvor du forstår testens potentiale til at kvalificere vores risikovurdering, kan vi se på, hvordan tests specificeres ud fra risikobeskrivelser.
Risikobaseret testplanlægning
Når vi som testere har identificeret en produktrisiko, der giver anledning til bekymring, skal vi formulere et sæt tests, der viser, at den pågældende fejltilstand er mindre sandsynlig. Vores testtilgang vil naturligvis være at fremkalde fejltilstanden på så mange måder som muligt, og derved vil vi enten:
Samlet set fokuserer vores tests på de måder, hvorpå en udvalgt fejltilstand kan opstå. Antag for eksempel, at risikoen var ”manglende evne til at beregne en bilforsikringspræmie korrekt”. I dette tilfælde kunne et passende testmål være ”demonstrer ved hjælp af alle-par-teknikken for inputvariabler, at systemet beregner bilforsikringspræmien korrekt”. Dette testmål kan gives til en tester, som derefter udleder et dækkende sæt testcases ved hjælp af alle par, for eksempel.
Praktiske forhold
Nu til nogle praktiske overvejelser i forbindelse med risikobaseret test.
Hvad hvis interessenterne ikke er interesserede i at hjælpe med risikovurderingen?
Du vil måske opleve, at det er svært at få tid fra interessenterne til at hjælpe dig med at identificere og vurdere risici samt udforme din testplan.
Hvad hvis der er flere testmuligheder for en produktrisiko?
Det er naturligvis næsten altid tilfældet. For eksempel kan du, når du tester en funktion, der giver anledning til bekymring, bruge en hvilken som helst af en række testdesignteknikker eller modellere funktionen på en unik måde og udlede tests fra den model. Der findes en række dækningsmål, du kan bruge til at fastsætte et mål. Du kan teste en funktion manuelt eller ved hjælp af et værktøj eller en anden teknologi.
Vi ser på, hvordan du kan træffe valg, i den næste artikel: ”Hvor meget test er nok?”.
Hvad hvis test (for at håndtere en risiko) koster for meget?
Da der næsten altid findes flere muligheder, og der ikke er nogen grænse for, hvor meget test man kan anvende for at undersøge en risiko og kvalificere en risikovurdering, skal der træffes et valg. Det siger sig selv, at nogle muligheder vil blive vurderet som for dyre. Når du præsenterer muligheder for interessenterne, skal du derfor have mindst én mulighed, der er overkommelig, og én, der muligvis ikke er overkommelig.
Igen: Vi ser på, hvordan du kan træffe valg, i den næste artikel: ”Hvor meget test er nok?”.
More Articles
Hvis vi tester funktioner med høj risiko mere, tester vi så ikke andre funktioner mindre?
Hvis testbudgettet er fastlagt på forhånd for et team, eller teamets størrelse og antallet af testere er fast, er den mængde test, som medarbejderne kan udføre, begrænset (inden for en fast tidsramme eller en tidsafgrænset periode). Hvis vi derfor lægger større vægt på nogle funktioner, må testen af andre funktioner reduceres. Dækningen, eller i det mindste indsatsen på tværs af funktionerne, varierer med risikoen.
Måden at se på dette på er, at når en test mislykkes, og der findes en fejl i systemet, vil den alvorlighed, der tildeles fejlen, sandsynligvis være tæt forbundet med konsekvensen af denne fejl (i produktion). Mere alvorlige fejl bliver rettet, fordi de ganske enkelt er vigtigere for interessenterne.
En produktrisikoanalyse fremhæver de områder, hvor fejl, fordi de er vigtige, har større sandsynlighed for at blive rettet. Ved at bruge en risikoanalyse til at fremhæve, hvor test udføres, og/eller hvor der anvendes mere test, er der derfor større sandsynlighed for, at vi finder vigtige fejl, og mindre sandsynlighed for, at vi finder fejl i funktioner, som interessenterne måske går mindre op i.
Det ville være rart at tro, at vi nogle gange kan teste overalt på en mere ensartet måde. Men når ressourcer og tid er begrænsede (og det er de altid, ikke?), hjælper en risikobaseret tilgang dig med at udnytte testernes tid mere effektivt og hensigtsmæssigt.
Hvad nu, hvis test ikke er den rette løsning?
Før du afsætter tid til at finde frem til en testtilgang for en produktrisiko i detaljer, er det vigtigt også at overveje muligheder, der ikke involverer test. Forestil dig for eksempel, at der er stor bekymring for, at en systemkomponent muligvis ikke vil fungere godt nok i produktion, og at svartiderne eller pålideligheden er utilstrækkelige. Du kunne naturligvis udføre belastningstest og forsøge at fejlfinde dig ud af problemerne. Men andre muligheder kunne være:
- Køb komponenten fra en 3.-part, byg den ikke selv, og undgå risikoen.
- Omdesign arkitekturen, så belastninger fordeles på flere instanser af komponenten.
- Flyt behandlingen til et batchsystem på en kopi af dataene.
- I stedet for at implementere en stor samlet løsning for alle brugere kan du vælge en trinvis tilgang, hvor kunder implementeres region for region, og ydeevnen overvåges nøje.
- Og så videre.
Ofte er en anden fremgangsmåde til at forebygge problemer mere effektiv og økonomisk end at teste for at finde problemerne senere.
Forståelse af testens rolle i risikostyring
Test kan reducere risikoen ved en udgivelse. Hvis vi bruger en risikovurdering til at styre vores testaktiviteter, bliver testernes mål udtrykkeligt at designe test, der opdager fejl, så de kan rettes, og dermed reducere risikoen for et fejlbehæftet produkt.
Fejlfinding reducerer den resterende risiko for fejl under drift, hvor omkostningerne stiger meget kraftigt. Når en test finder en fejl, og den rettes, reduceres antallet af fejl, og dermed falder den samlede sandsynlighed for fejl.
Man kan også se på det på denne måde: Den ’mikrorisiko’, der skyldes fejlen, elimineres. Men det skal huskes, at test ikke kan finde alle fejl, så der vil altid være latente fejl, som forbliver uberørte, og som test ikke har givet direkte information om.
Hvis vi derimod fokuserer på kritiske funktioner og finder fejl i dem, er uopdagede fejl i disse kritiske funktioner mindre sandsynlige. De fejl, der er tilbage i systemets ikke-kritiske funktioner, har mindre alvorlige konsekvenser.
En sidste bemærkning: Selve risikovurderingsprocessen indebærer risiko. Risikovurdering kan både overvurdere og undervurdere risiciene, hvilket kan føre til beslutninger, der ikke er optimale. Risikovurdering kan også bidrage til en skyldskultur, hvis den drives for vidt.
Blandt andre potentielle faldgruber ved risikovurdering skal du forstå, at der ikke findes en absolut risiko, som kan beregnes, efter projektet er afsluttet. Risici er af natur usikre. Ligesom med testens effektivitet kan værdien af en risikovurdering kun fastslås retrospektivt, efter projektet er afsluttet.
Og det var vores manifest for risikobaseret test. Begrebet vil dukke op igen gennem hele serien om ledelse inden for test, så hold øje med flere artikler!
Tilmeld dig QA Lead-nyhedsbrevet for at få besked, når nye dele af serien udkommer. Disse indlæg er uddrag fra Pauls kursus i ledelse inden for test, som vi varmt anbefaler, hvis du ønsker at gå mere i dybden med dette og andre emner. Hvis du gør det, kan du bruge vores eksklusive kuponkode QALEADOFFER og få $60 i rabat på den fulde kursuspris!
