Risikoer har, dersom de materialiserer seg, en negativ innvirkning på prosjektene våre. Risikostyring handler om å tenke gjennom hvilke risikoer som finnes, og iverksette tiltak for å redusere sannsynligheten for at de oppstår, eliminere dem eller redusere innvirkningen de har på interessentenes mål.
I noen virksomheter praktiseres risikostyring med ingeniørmessig og matematisk presisjon. Innen programvare er det ikke mulig å være særlig presis. De fleste organisasjoner praktiserer fortsatt ikke risikobasert testing systematisk. Men det finnes en god grunn til dette: Når risikoer i programvareprodukter først er identifisert, er de ofte svært vanskelige å vurdere.
Fra et test- og kvalitetssikringsperspektiv er en risiko en «sviktmodus man bør være bekymret for». Risikobasert testing er praksisen med å modellere potensielle sviktmoduser i systemet som produktrisikoer for å understøtte avgrensning, skalering og prioritering av testing.
I denne artikkelen vil jeg presentere et manifest for risikobasert testing. Vi skal se på klassisk risikostyring og hvordan vi kan tilpasse den slik at den blir nyttig for testere. Til slutt skal vi se på noen praktiske forhold og hensyn som vil hjelpe deg med å ta i bruk din egen metode for risikobasert testing.
- Prosjekt-, prosess- og produktrisiko
- Et manifest for risikobasert testing
- Den klassiske tilnærmingen til risiko
- Produktrisiko og testing
- Praktiske forhold
- Forstå testingens rolle i risikostyringen
Prosjekt-, prosess- og produktrisiko
Det finnes hundrevis av bøker om risiko og risikostyring som beskriver en rekke tilnærminger til håndtering av risiko på prosjektnivå. Vanligvis fokuserer disse tilnærmingene på det vi vil kalle prosjekt- og prosessrisiko, med kanskje én enkelt risiko med en tittel som «manglende oppfyllelse av krav». Det er ikke særlig nyttig å ha én enkelt kravrisiko, siden det ikke er slik at du kan prioritere én risiko for testing.
Det finnes tre typer programvarerisko.
Prosjektrisiko: Disse risikoene gjelder prosjektet i dets egen kontekst. Prosjekter har vanligvis eksterne avhengigheter, for eksempel tilgang på kompetanse, avhengighet av leverandører, faste tidsfrister eller begrensninger som en fastpriskontrakt. Eksterne avhengigheter er prosjektledelsens ansvar.
Prosessrisiko: Disse risikoene gjelder først og fremst prosjektets interne forhold, og prosjektets planlegging, overvåking og styring blir gransket. Typiske risikoer her er undervurdering av prosjektets kompleksitet, arbeidsinnsats eller nødvendig kompetanse. Intern styring av et prosjekt, som god planlegging, fremdriftsoppfølging og kontroll, er alt sammen prosjektledelsens ansvar.
Produktrisiko: Produktrisiko er det viktigste risikoområdet for testere. Disse risikoene gjelder produktdefinisjonen, stabiliteten til kravene (eller mangelen på stabilitet), produktets kompleksitet og hvor utsatt teknologien er for feil.
Fra nå av konsentrerer vi oss om produktrisikoer. Vi bruker begrepet produktrisiko på følgende måte:
Et manifest for risikobasert testing
I prosjekter der det vil bli tatt risikoer (noe vi mener gjelder alle prosjekter), må testere synliggjøre risikoene for ledelsen og foreslå pålitelige testmetoder for å håndtere disse risikoene gjennom hele prosjektet.
Dette er ledelsens oppgave – å utføre og/eller føre tilsyn med følgende oppgaver innen risikobasert testing:
Den klassiske tilnærmingen til risiko
Det finnes mange varianter, men den klassiske tilnærmingen til risiko forsøker å være kvantitativ.
Have an account? Log In
Sannsynlighet, konsekvens og eksponering
For å vurdere en produktrisiko må vi forstå hvilken konsekvens den aktuelle feilmodusen har. Hvis en feil oppstår, sier vi at risikoen materialiserer seg. Deretter spør vi «hvor alvorlig er risikoen?», også omtalt som eksponering.
For å beregne eksponeringen vurderer vi risikoen i to dimensjoner:
- Sannsynligheten (eller muligheten) for at en risiko materialiserer seg. Denne verdien uttrykkes vanligvis som en prosentandel mellom (men ikke inkludert) null og 100 prosent.
- Konsekvensen (eller virkningen eller tapet) av at en risiko materialiserer seg. Dette er den potensielle kostnaden for skaden dersom denne feilmodusen oppstår.
Eksponeringen til en risiko – hvor alvorlig en risiko er – beregnes som produktet av sannsynligheten og konsekvensen.
Den klassiske tilnærmingen til risiko mangler ofte den teknologiske støtten som trengs for effektiv håndtering. Moderne løsninger for testhåndtering fyller dette gapet ved å tilby funksjoner som er tilpasset risikobasert testing.
Kvantitativ eller kvalitativ poenggiving
Det er ofte vanskelig å forutsi den potensielle kostnaden ved en feil. Uten ytterligere informasjon er det også nesten umulig å forutsi sannsynligheten for en feil med særlig sikkerhet. Derfor benytter de fleste fagpersoner semikvantitative eller kvalitative skalaer for sannsynlighet og konsekvens.
Det er vanlig å bruke numeriske intervaller fra én til fem for begge skalaene, noe som gir mulige eksponeringsverdier fra én til tjuefem. Men få testere, utviklere eller interessenter tildeler disse tallene med særlig sikkerhet, så det er vanlig å gradere risikoeksponeringen direkte ved hjelp av en skala fra 1 til 5, eller – enda enklere – en vurdering med rød, gul eller grønn. Noen går så langt som å si at risikoer enten er innenfor eller utenfor omfanget, men vi vil hevde at dette er en overforenkling.
Uansett om du kvantifiserer risikoene eller bruker fargekoder, er det kritiske aspektet ved risikovurderinger ikke poenggivningen, men samtalene og diskusjonene du har når poengene tildeles og diskuteres.
Hvis du blir bedt om å gi risikoer en poengsum med større presisjon enn skalaer fra én til tre (eller fem hvis det er helt nødvendig), bør du seriøst vurdere om tallene du tildeler, har noen reell verdi.
Numerisk poenggiving kan gi et inntrykk av vitenskapelig grundighet, men hvis tallene er gjetninger, lurer du deg selv. Hvis tallene avdekker meningsforskjeller, for eksempel at en bruker sier «fem» og utvikleren sier «én!», finnes det grunnlag for en samtale, ettersom forventningene eller oppfatningene tydeligvis er forskjellige.
Vær forsiktig med å bruke en enkel ordning der risikoer enten er innenfor eller utenfor omfanget. Det kan være tydelig hvilke bekymringsfulle risikoer som skal håndteres gjennom testing. Prosjekter lærer imidlertid over tid, og ofte oppstår forsinkelser, så kompromisser må inngås. Hvis risikoene ikke prioriteres på en eller annen måte, må du gjennomgå alle bekymringsfulle risikoer for å avgjøre hvilke som må tas ut av eller inkluderes i omfanget.
Vi skal diskutere avgrensning, prioritering og skalering mer detaljert i senere artikler, så følg med.
Produktrisiko og testing
Diskusjonen om (produkt)risikoer vil avdekke interessentenes frykt for sannsynligheten for feil i kritiske deler av prosjektet eller systemet. Når vi har en liste over produktrisikoer, hvordan omsetter vi den til handling og konkrete planer for testing? Før vi kan svare på det spørsmålet, må vi forstå litt bedre hvordan testing påvirker eller innvirker på risikovurderingene våre.
Testing reduserer ikke risiko – den gir grunnlag for risikovurderinger
Du hører ofte folk hevde at «testing reduserer risiko». Det stemmer ikke – testing kan noen ganger øke risikoen. Mantraet om at testing reduserer risiko, skyldes manglende forståelse av både risiko og testing.
La oss si at vi har identifisert en risiko for at en funksjon eller funksjonalitet kan svikte. Vi utformer en test og kjører den. Testen kan bestå eller mislykkes. Hvordan vil en bestått eller mislykket test påvirke risikovurderingen vår?
For det første har tester ingen effekt på vår forståelse av konsekvensen av en feil. Konsekvensen av en feil er som den er, og testing endrer ikke dette.
Det finnes fire relevante testresultater og påvirkninger på risikosannsynligheten. Disse er oppsummert i denne tabellen:
| Sannsynligheten for risiko øker | Sannsynligheten for risiko reduseres | |
| Testen består | Nei. En bestått test kan bare gjøre oss sikrere på at en feilmodus ikke vil oppstå. (Dette forutsetter at testene våre er meningsfulle.) | Ja, etter hvert. Når vi kjører stadig flere tester som består, og utforsker ulike scenarier, avtar sannsynligheten for feil. |
| Testen mislykkes | Muligens, avhengig av feilen. Men sannsynligheten reduseres over tid. Vi forutså at denne feilmodusen ville oppstå; valget av test er dermed bekreftet. Heldigvis kan vi rette dette nå og fokusere testingen på å redusere risikoen for andre feil av denne typen. | Lite sannsynlig, med mindre risikovurderingen vår var feil. |
Ved å kjøre tester som vi forbinder med en bestemt risiko, får vi stadig mer informasjon som kan forbedre risikovurderingen vår. Hvis tester mislykkes, er valget vårt bekreftet. Når vi retter feilen og tester på nytt, bør risikovurderingen vår reduseres når testene består. Men hvis vi fortsetter å finne nye eller flere feil, kan det hende at vi vurderer risikoen som høyere.
Nå som du forstår testingens potensial til å gi informasjon til risikovurderingen vår, kan vi se på hvordan tester spesifiseres ut fra risikobeskrivelser.
Risikobasert testplanlegging
Som testere må vi, når vi har identifisert en produktrisiko som bør undersøkes, utforme et sett med tester som viser at den aktuelle feilmodusen er mindre sannsynlig. Testtilnærmingen vår vil selvsagt være å fremprovosere feilmodusen på så mange måter som mulig, og dermed enten:
Samlet sett fokuserer testene våre på måter en valgt feilmodus kan oppstå på. Anta for eksempel at risikoen var «manglende evne til å beregne en bilforsikringspremie korrekt». I dette tilfellet kan et passende testmål være «demonstrere ved hjelp av alle-par-teknikken for inndatavariabler at systemet beregner bilforsikringspremien korrekt». Dette testmålet kan gis til en tester, som kan utlede et dekkende sett med testtilfeller ved hjelp av alle par, for eksempel.
Praktiske forhold
La oss nå se på noen praktiske hensyn knyttet til risikobasert testing.
Hva om interessentene ikke er interessert i å bidra til risikovurderingen?
Det kan være vanskelig å få tid fra interessentene til å hjelpe deg med å identifisere og vurdere risikoer og utforme testplanen din.
Hva om det finnes flere testalternativer for en produktrisiko?
Dette er selvsagt nesten alltid tilfelle. For å teste en funksjon som bør undersøkes, kan du for eksempel bruke en av flere testdesignteknikker, eller modellere funksjonen på en unik måte og utlede tester fra denne modellen. Det finnes flere dekningsmål du kan bruke til å sette et mål. Du kan teste en funksjon manuelt eller ved hjelp av et verktøy eller annen teknologi.
Vi skal se på hvordan du kan ta slike valg i neste artikkel, «Hvor mye testing er nok?».
Hva om testing (for å håndtere en risiko) koster for mye?
Siden det nesten alltid finnes alternativer, og det ikke er noen grense for hvor mye testing man kan utføre for å utforske en risiko og informere en risikovurdering, må man ta et valg. Det sier seg selv at noen alternativer vil bli vurdert som for dyre. Når du presenterer alternativer for interessentene, må du derfor ha minst ett alternativ som er overkommelig, og ett som kan være uoverkommelig.
Igjen: Vi skal se på hvordan du kan ta slike valg i neste artikkel, «Hvor mye testing er nok?»
More Articles
Hvis vi tester funksjoner med høy risiko mer, tester vi vel andre funksjoner mindre?
Hvis testbudsjettet er fastsatt på forhånd for et team, eller teamstørrelsen og antallet testere er fast, er mengden testing folk kan utføre begrenset (innenfor en fast tidsramme eller tidsavgrenset periode). Hvis vi legger mer vekt på enkelte funksjoner, må testingen av andre funksjoner derfor reduseres. Dekningen, eller i det minste innsatsen på tvers av funksjoner, varierer med risikoen.
Måten å se dette på er at når en test mislykkes og en feil blir funnet i systemet, vil alvorlighetsgraden som tildeles feilen, sannsynligvis være nært knyttet til konsekvensen av denne feilen (i produksjon). Mer alvorlige feil blir rettet fordi de ganske enkelt er viktigere for interessentene.
En produktrisikoanalyse fremhever områdene der feil, fordi de er viktige, har større sannsynlighet for å bli rettet. Ved å bruke en risikoanalyse til å fremheve hvor testing gjennomføres, og/eller hvor mer testing utføres, er det derfor større sannsynlighet for at vi finner viktige feil, og mindre sannsynlighet for at vi finner feil i funksjoner som interessentene kanskje bryr seg mindre om.
Det ville vært fint å tenke at vi noen ganger kan teste overalt på en mer jevn måte. Men når ressurser og tid er begrenset (og det er de alltid, ikke sant?), hjelper en risikobasert tilnærming deg med å utnytte testernes tid mer effektivt og hensiktsmessig.
Hva om testing ikke er det riktige tiltaket?
Før du bruker tid på å utarbeide en detaljert testtilnærming for en produktrisiko, er det viktig at alternativer til testing også vurderes. Tenk for eksempel at det er stor bekymring for at en systemkomponent kanskje ikke vil yte godt nok i produksjon, og at svartidene eller påliteligheten er dårlige. Du kan selvfølgelig gjennomføre lasttester og forsøke å feilsøke deg ut av problemene. Men andre alternativer kan være:
- Kjøp komponenten fra en 3. part, ikke bygg den selv og ta risikoen.
- Omarkitekturer løsningen slik at belastningen fordeles på flere komponentinstanser.
- Overfør behandlingen til et batchsystem basert på en kopi av dataene.
- I stedet for å gjennomføre en alt-i-ett-implementering for alle brukere, kan du ta en trinnvis tilnærming ved å implementere kunder region for region og følge ytelsen nøye.
- Og så videre.
Ofte er en annen fremgangsmåte for å forhindre at problemer oppstår, mer effektiv og kostnadseffektiv enn å teste for å finne problemene senere.
Forstå testingens rolle innen risikostyring
Testing kan redusere risikoen ved en lansering. Hvis vi bruker en risikovurdering til å styre testaktivitetene våre, blir testernes mål uttrykkelig å utforme tester som oppdager feil, slik at de kan rettes, og dermed redusere risikoen for et feilbehengt produkt.
Feildeteksjon reduserer den gjenværende risikoen for feil i drift, der kostnadene øker svært kraftig. Når en test finner en feil og den blir rettet, reduseres antallet feil, og dermed reduseres også den samlede sannsynligheten for feil.
Man kan også se på det på denne måten: «mikrorisikoen» som skyldes denne feilen, elimineres. Men det må huskes at testing ikke kan finne alle feil, så det vil alltid finnes latente feil som ikke blir berørt, og som testingen ikke har gitt noen direkte informasjon om.
Hvis vi derimot fokuserer på kritiske funksjoner og finner feil i disse, er uoppdagede feil i disse kritiske funksjonene mindre sannsynlige. Feilene som finnes igjen i systemets ikke-kritiske funksjoner, har mindre alvorlige konsekvenser.
En siste merknad: Selve prosessen med risikoanalyse innebærer risiko. Risikoanalyse kan både overvurdere og undervurdere risikoene, noe som kan føre til mindre enn perfekte beslutninger. Risikoanalyse kan også bidra til en skyldfordelingskultur hvis den drives for langt.
Blant andre mulige fallgruver ved risikoanalyse må du forstå at det ikke finnes noen absolutt risiko som kan beregnes etter at prosjektet er over. Risikoens natur er at den er usikker. Akkurat som med effektiviteten av testing kan verdien av en risikoanalyse bare fastslås i ettertid, etter at prosjektet er over.
Og det var vårt manifest for risikobasert testing. Konseptet vil dukke opp igjen gjennom serien om ledelse innen testing, så følg med på flere artikler!
Meld deg på QA Lead-nyhetsbrevet for å få beskjed når nye deler av serien publiseres. Disse innleggene er utdrag fra Pauls kurs i ledelse innen testing, som vi på det varmeste anbefaler hvis du vil gå dypere inn i dette og andre temaer. Hvis du gjør det, bruk vår eksklusive kupongkode QALEADOFFER for å få $60 i rabatt på full kurspris!
