Per Erik Strandberg /cv /kurser /blog

Introduktion

Riskbaserad Testning hjälper till att minimera och bekämpa produktrisker från början av projektet. En riskbaserad prioritering av tester säkerställer att de delar av produkten med högst risk testas mest. (Min översättning av en bra och kort sammanfattning av vad Riskbaserad Testning är, från Boken Software Testing Foundations.)

Vad är en risk?

Ett centralt begrepp inom riskbaserad testning är såklart risk - och vi repeterar lite snabbt vad risk innebär innan vi fortsätter.

Definition av Risk

RBSC lägger till (i en av deras många filmer på sin Youtube kanal (se [1]) att risk

I min hjärna är jag tyvärr väldigt svengelsk i min terminologi så jag tänker i risk item och risk level. Min hjärna klarar inte heller av att prata om möjligheter som risker så för enkelhets skull är min definition följande: risk - en osäkerhet som kan hindra dig från att nå dina mål.

Dualiteter i begreppet risk

Slutsatsen är att man ibland pratar om risker som möjliga händelser - till exempel: "Problem efter uppdatering från version 1.0 till 1.1" eller "Utvecklare Urban förlänger sin sjukskrivning". Men också som ett mått. Måttet är ofta en multiplikation av ett mått på sannolikhet och ett annat mått på effekten eller förödelsen som skapas om händelsen inträffar. Ofta använder man lite godtyckligt värden från 1 till 3 (eller 1 till 5, eller 1 till 10) på de olika faktorerna. Jag brukar tänka hög, låg, medium för det är enkelt och antyder inte att man kan ha så bra precision. Exempel:

Man bör även skilja på produktrisker (som ibland kallas kvalitetsrisker) och projektrisker. En projektrisk är till exempel "Utvecklare Urban förlänger sin sjukskrivning" och inget som blir bättre av att vi till exempel testar mjukvaran lite bättre. Kvalitetsrisker är till exempel "Problem efter uppdatering från version 1.0 till 1.1" och här kan man undersöka om man kan göra något åt risken.

Överraskning!

Ibland när man pratar om risker så kan en slags överraskningsfaktor eller detektionsfaktor tas med - vi har till exempel lättare att upptäcka att bensinen tar slut i bilen och vi hinner kanske åtgärda det lättare, än om ett däck exploderar.

Riskanalys

Här börjar jag blanda in tankesätt från testhållet, men tanken är att först diskutera riskanalys i allmänhet.

Lite motivation

Boken The Economics Of Software Quality har en stor katalog av kunskap och nämner 65 tekniker för att förbättra kvalitet i mjukvara - inte bara tekniker för test. När det gäller riskanalys som sådan (inte i samband med test) för de fram två typer av riskanalys: automatiserad och manuell. Den automatiserade riskanalysen listar de som den femte bästa tekniken för att förebygga defekter (de använder måttet defect prevention efficiency - DPE) och ger en automatiserad riskanalys en DPE på 48%, som är bättre än statisk kodanalys, men inte lika bra som formell granskning (se för övrigt One Does Not Simply Document Code och Testing In Visual Studio Part 1 för två aspekter på statisk kodanalys, samt Metod För Formell Granskning för mer om granskning).

Manuell riskanalys hamnar på plats 28 med en DPE på 22% (bättre än dagliga scrum-möten, men inte lika bra som CMMI nivå 3, eller informell granskning). Intressant i sammanhanget är att användandet av standarder ger en DPE på 10% och en plats 51 av 65, men de sista platserna har en negativ DPE...

(Jag måste själv erkänna att jag inte tagit reda på vad de menar med manuell och automatisk riskanalys, men konstaterar att det är bra skit oavsett!)

När det gäller riskanalys i allmänhet så nämner författarna att tekniken i allmänhet funkar dåligt ihop med agila utvecklingsmodeller - något som störde mig en hel del, mer om det senare. Deras tips är att göra en riskanalys på kraven - gärna innan man avslutar kravarbetet.

Riskanalys - tankesätt

Nu blandar jag in lite tankesätt från litteraturen kring Riskbaserad Testning - men jag tror just dessa bitar gäller all riskanalys. Till exempel så nämner den underbart vackra Software Testing Standard Iso Iec Ieee 29119 i avsnitt om testplanering att man bör göra riskanalyser. Om vi börjar med att kika på hur de tycker man ska göra en testplan i testplaneringsprocessen som finns i 29119 del 2. När vi testplanerar ska vi göra nio saker (men inte nödvändigtvis i denna ordning):

  1. Förstå kontexten
  2. Organisera testplanerandet
  3. Identifiera och analysera risker
  4. Identifiera riskmitigeringsprocesser
  5. Anpassa teststrategi
  6. Bemanning och schema
  7. Få testplanen på pränt
  8. Få konsesus på testplanen
  9. kommunicera testplanen göra den tillgänglig.

När det gäller hur vi gör aktiviteterna som handlar om risk lär vi oss följande:

Vi undersöker de tre viktigaste stegen (riskidentifiering, riskbedömning och riskminskning) lite till.

Riskidentifiering

Att identifiera risker är endast att hitta möjliga händelser (man vinner ofta på att vänta med att kvantifiera riskerna). Det kan vara ett kreativt arbete - man kan få hjälp och stöd av att göra intervjuer, ha oberoende granskare, använda olika mallar eller checklistor, genomföra en workshop, brainstorming eller att läsa projektrapporter från tidigare liknande projekt. Även retrospectives kan vara ett bra tillfälle att lista och samla på potentiella risker.

Man bör ta tillvara på så många olika kompetenser som möjligt när man identifierar risker - och få intressenternas syn.

En bra idé är att kategorisera riskerna för att få en slags känsla för täckningen och spridningen på riskerna - detta är även en chans att se till att man inte har dubbletter.

I vissa fall kan det vara relevant att undersöka följdfel av en inträffad händelse för att få en större förståelse av risken - konsekvensanalys (Urban fortsätter vara sjukskriven och gör att även Kalle blir utbränd). Eller att ta reda på villkor som kan trigga händelsen - orsaksanalys (Version 1.1 har fått in patchar som bara funkar på Windows).

http://www.pererikstrandberg.se/blog/orsaker-konsekvenser.png

Mina riskidentifieringar har varit breda och spretiga. Jag har intervjuat folk, undersökt källkodsförändringar, tagit del av projektplaner och tittat på testrapporter från tidigare releaser - vilka risker var kvar som inte hade släckts.

Riskbedömning

När riskerna är identifierade kan riskerna skattas för att senare kunna jämföras med varandra. Det är antagligen så att projektets finansiärer, testare, utvecklare, användare och arkitekter har olika syn på hur stora sannolikheterna och effekterna är - så genom att sammanväga deras syn får man ett bra medelvärde.

Kursplanen från ISTQB/SSTB nämner att sannolikheten för att en risk ska inträffa beror på tekniska risker och beror på till exempel:

Man kan tänka att sannolikheten motsvarar sannolikheten att systemet innehåller buggar relaterat till riskhändelsen när testning börjar.

ISTQB/SSTB nämner också att konsekvensen beror på affärsrisker:

Jag har inte gjort riskbedömning i storforum utan satt mig med en kunnig utvecklare när jag undersöker sannolikhet och sen med en marknadsrepresentant för att undersöka konsekvens.

Riskminskning

Risker brukar typiskt hanteras på ett av fyra sätt:

  1. Undvika: man minskar sannolikheten för en risk med förebyggande åtgärder (ställer sig mellan två större träd när det åskar).
  2. Reducera: man minskar effekten av en risk (klär på sig ringbrynja som ska fungera som Faradays bur).
  3. Överföra: man låter någon annan ta risken - eller köper en försäkring (man hyr någon som får gå ut i åskan i stället för att man själv gör det).
  4. Acceptera eller ignorera: man tar smällen om den kommer.

Genom att testa områden i systemet kan man påvisa defekter och möjliggöra riskminskning. Om ett område testas utan att hitta defekter har man visat att under de omständigheter som rådde när testet genomfördes så fungerade systemet korrekt - på så sätt har man minskat risken.

I testcyklerna utförs nya riskanalyser och testning utförs med fokus på nya produktrisker eller risknivåer som ändrats mycket, samt mot instabila områden i systemet eller områden som har låg testtäckning.

Man kan med fördel mäta riskminskning eller risktäckningsgrad och rapportera dessa mätetal och även undersöka kvarvarande risken.

Riskbaserad testning

Okej, nu har vi gått som katten kring het gröt ett tag. Äntligen är det dags att undersöka riskbaserad testning!

Historik

Under 1980-talet jobbade Barry Boehm (se Wikipedia [2]) och Boris Beizer (se Wikipedia [3] - det handlar inte om Pierre Bézier som bland annat uppfann Bézierkurvor: [4]) oberoende av varandra inom området risk och mjukvara. Både Boehm och Beizer gjorde viktiga upptäckter inom mjukvaruutveckling - till exempel uppfann Boehm spiral-modellen som är en slags iterativ risk-minimerande utvecklingsmodell. Beizer uppfann band annat konceptet risk-driven integration. Båda nämnde att man ska ta hänsyn till risk vid mjukvarutestning men gick inte djupare än så.

På 1990-talet utforskade bland annat Rick Craig, Paul Gerrard, Felix Redmill och Rex Black (Black är författaren till bland annat Boken Advanced Software Testing) oberoende av varandra riskbaserad testning.

Under decenniet som följde blev riskbaserad testning en erkänt kompetent metod och används nu mycket framgångsrikt.

Varför är en riskbaserad teststrategi bra?

Boken Agile Testing menar att testning minskar risk: vi får hjälp att identifiera och minska risker när vi testar. De värsta riskerna kan vi täcka med utforskande tester (till exempel Session Based Exploratory Testing). Och om en testare inte kan komma vidare i sin testning på grund av oklara krav (ja, ja, user stories på scrumspråk) är det en god idé att be om ett exempel.

Boken Advanced Software Testing är ganska fokuserad på Riskbaserad Testning och ägnar 90 sidor åt det (dock så är många av sidorna ägnade åt tabeller och fallstudier). Här nämns även Failure Mode and Effects Analysis (FMEA) som har fått minskat fokus i senare certifieringar för att bli en Istqb Advanced Level Test Manager sedan boken skrevs. Författaren beskriver hur risker kan guida testning på ett par viktiga sätt:

  1. Vi kan allokera testresurser i proportion till produktrisker. Min erfarenhet annars är att det är ganska svårt att Beräkna Testinsats. Vi kan dessutom planera för att testa de värsta riskerna först. Och om vi har något att säga till om vid planering av implementation kan vi rekommendera att reparera högriskområden först.
  2. Alla projektrisker vi hittar kan eskaleras - risknivån kan kommuniceras.
  3. Testrapportering kan ske i termer av initial risk och residual risk. Riskanalysen kan även tillåta metriker som kan vara intressant: buggar funna per risknivå och så vidare.

Andra vinster som lyfts fram är att när testresurserna har dränerats så vet vi att vi lagt insatsen på rätt saker - de minst farliga riskerna är kvar. Det är även ganska lätt att kommunicera med stakeholders (intressenter på svenska) i termer av risk.

Andra motiveringar kommer från Software Testing Standard Iso Iec Ieee 29119, som nämner riskbaserad testning:

ISO/IEC/IEEE 29119 berättar att man kan använda sig av riskanalys i flera olika lager i organisationen (här kommer tänket från del 2: testprocesser igen). Till exempel kanske organisationen gör riskbedömning på huruvida man uppfyller laga krav för medicinsk utrustning; på testledningsnivå kan riskanalysen användas för att styra hur testningen ska genomföras, vilken insats som ska ges till olika testnivåer (integrationstester, systemtester, etc). Under genomförandet är riskbaserad testning en form av riskmitigering.

Kategorier

Rex Black RBSC (som jag refererar till återkommande här) listar på sin hemsida [5] ett antal kategorier man kan använda som checklista i sin kravanalys: Funktionalitet, Last, Stabilitet, Stress och felhantering, Datumhantering, Sämre än konkurrenter, Underhåll, Användbarhet, Datakvalitet, Prestanda, Internationalisering, Kompatabilitet, Säkerhet, Installation och migration, Dokumentation, samt Interface.

Vill man gå "all in" på riskkataloger är Boken The Economics Of Software Quality en bra källa - de 160 mjukvarurisker att tänka på - till exempel nummer 67 som handlar om bloat.

Riskbaserad testning är upprepad riskanalys

En riskbaserad teststrategi har i princip tre steg som utförs med jämna mellanrum:

  1. Riskidentifiering
  2. Riskbedömning
  3. Riskminimering

Viktigt att poängtera är att man behöver uppdatera riskanalysen med jämna mellanrum. Till exempel vid viktiga milstolpar i en sekventiell utvecklingsmodell: när kravspec'en blir godkänt. Kör man agilt/iterativt kanske det är läge att lägga en timme per sprint i samband med sprintplanering. Kanske har nya risker dykt upp? Kanske har man mer kunskap nu?

I många utvecklingsmodeller som till exempel V-modellen (som jag kikar på när jag spånar på en Agil Testprocess), kan det vara lämpligt att genomföra riskanalys parallellt med krav- och/eller designspecifikation. På det sättet kan man även få chansen att täppa till stora risker med uppdaterade krav/design.

När man uppdaterar sin riskanalys över tid kanske man får en plot i stil med bilden nedan. Bilden visar att releasens risker ökar efter att den första riskanalysen är avklarad - detta för att vi börjar testa och hittar nya problem. Men den kvarvarande risken minskar så småningom till en nivå som beslutsfattare tycker är ok.

http://www.pererikstrandberg.se/blog/risk-over-time.png

Viktigt att notera är alltså att vi kommer hitta fler risker - så vi kan inte bara ha riskbaserade strategier utan vi måste även ha reaktiva strategier, och/eller uppdatera den riskbaserade testningen på ett reaktivt sätt.

Riskmitigering med Test

Som redan nämnt bör tekniken för att mitigera riskerna bero på kontexten och storleken på risken. Sannolikt är det så att små risker kan negligeras i många projekt. Typiskt bra metoder är:

En mall för kalkylblad

Jag vet att det ska finnas mjukvaruverktyg som stöd för riskanalyser, men jag har använt kalkylblad och lagt in lite enkla formler - typiskt något sånt här:
http://www.pererikstrandberg.se/blog/risk-based-testing.png

Agil risk-baserad testning

Senare i år kommer vår vän Rex Black att hålla ett webbinarium om just agil riskbaserad testning - när han hållit det ska jag helt klart se till att se det och uppdatera den här texten med hans oändliga visdom, och så några av mina egna erfarenheter såklart!

[To be continued]

Läs mer

Tillhör Kategori Mjukvara
Tillhör Kategori Test
Se också Agil Testprocess
se också Agila Testkvadranter