Ledarskap inom testning: riskbaserad testning
Redaktörens anmärkning: Välkommen till serien Ledarskap inom testning från mjukvarutestningsgurun och konsulten Paul Gerrard. Serien är utformad för att hjälpa testare med några års erfarenhet – särskilt de som arbetar i agila team – att lyckas i roller som testledare och testchef.
I föregående artikel tittade vi på vikten av testmodeller. Här ska vi fördjupa oss i riskbegreppet och presentera ett manifest för riskbaserad testning som du kan tillämpa i din egen metod för riskbaserad testning.
Anmäl dig till nyhetsbrevet The QA Lead för att få meddelanden när nya delar av serien publiceras. Dessa inlägg är utdrag ur Pauls kurs i ledarskap inom testning, som vi varmt rekommenderar om du vill fördjupa dig i detta och andra ämnen. Om du gör det kan du använda vår exklusiva kupongkod QALEADOFFER för att få $60 rabatt på ordinarie kurspris!
Risker får, om de förverkligas, en negativ effekt på våra projekt. Riskhantering innebär att fundera över vilka risker som finns och vidta åtgärder för att minska sannolikheten för dem, eliminera dem eller minska deras påverkan på våra intressenters mål.
I vissa verksamheter bedrivs riskhantering med teknisk och matematisk precision. Inom mjukvara är det inte möjligt att vara särskilt exakt. De flesta organisationer bedriver fortfarande inte riskbaserad testning på ett systematiskt sätt. Men det finns goda skäl till detta: när risker i mjukvaruprodukter väl har identifierats är de ofta oerhört svåra att bedöma.
Ur testnings- och kvalitetssäkringsperspektiv är en risk ett ”felmoder som man bör vara orolig för”. Riskbaserad testning är en metod där potentiella felmoder i systemet modelleras som produktrisker för att stödja avgränsning, dimensionering och prioritering av tester.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
I den här artikeln presenterar jag ett manifest för riskbaserad testning. Vi ska titta på klassisk riskhantering och se hur vi kan anpassa den så att den blir användbar för testare. Slutligen ska vi gå igenom några praktiska aspekter och överväganden som hjälper dig att tillämpa din egen metod för riskbaserad testning.
- Projekt-, process- och produktrisk
- Ett manifest för riskbaserad testning
- Det klassiska angreppssättet på risk
- Produktrisk och testning
- Praktiska aspekter
- Förstå testningens roll inom riskhantering
Vi använder denna definition av risk: En risk är ett hot mot ett eller flera av intressenternas mål för ett projekt och har en osäker sannolikhet.
Projekt-, process- och produktrisk
Det finns hundratals böcker om risk och riskhantering som beskriver många olika angreppssätt för att hantera risker på projektnivå. Vanligtvis fokuserar dessa angreppssätt på det vi kallar projekt- och processrisker, kanske med en enda risk med en titel i stil med ”underlåtenhet att uppfylla kraven”. Att ha en enda kravrisk är inte särskilt användbart, eftersom det inte är så att du kan prioritera en risk för testning.
Det finns tre typer av mjukvarurisker.
Projektrisk: Dessa risker rör projektet i dess eget sammanhang. Projekt har vanligtvis externa beroenden, till exempel tillgång till kompetens, beroende av leverantörer, fasta tidsfrister eller begränsningar som ett avtal med fast pris. Externa beroenden är projektledningens ansvar.
Processrisk: Dessa risker rör främst projektets interna delar, och projektets planering, uppföljning och styrning granskas. Typiska risker här är underskattning av projektets komplexitet, arbetsinsats eller den kompetens som krävs. Den interna hanteringen av ett projekt, såsom god planering, uppföljning av framsteg och styrning, är projektledningens ansvar.
Produktrisk: Produktrisk är det huvudsakliga riskområdet för testare. Dessa risker rör produktens definition, kravens stabilitet (eller brist på stabilitet), produktens komplexitet och teknikens benägenhet att ge upphov till fel.
Från och med nu koncentrerar vi oss på produktrisker. Vi använder begreppet produktrisk på följande sätt:
En produktrisk representerar en felmod eller ett felmönster som skulle vara oacceptabelt i en produktionsmiljö.
Ett manifest för riskbaserad testning
I projekt där risker kommer att tas (vilket vi anser gäller alla projekt) behöver testare synliggöra riskerna för ledningen och föreslå tillförlitliga testmetoder för att hantera dessa risker under hela projektet.
Detta är ledningens uppgift – att utföra och/eller övervaka följande uppgifter inom riskbaserad testning:
Det klassiska sättet att se på risk
Det finns många variationer, men det klassiska sättet att se på risk försöker vara kvantitativt.
Sannolikhet, konsekvens och exponering
För att bedöma en produktrisk måste vi förstå vilken konsekvens det aktuella felsättet får. Om ett fel inträffar säger vi att risken materialiseras. Därefter frågar vi ”hur allvarlig är risken?”, vilket annars kallas exponering.
För att fastställa exponeringen bedömer vi risken utifrån två dimensioner:
- Sannolikheten (eller möjligheten) att en risk materialiseras. Detta värde uttrycks vanligtvis som en procentsats mellan (men inte inklusive) noll och 100 procent.
- Konsekvensen (eller påverkan eller förlusten) av att en risk materialiseras. Detta är den potentiella kostnaden för skadan om detta felsätt inträffar.
Exponeringen för en risk – hur allvarlig en risk är – beräknas som produkten av sannolikheten och konsekvensen.
Exponering = Risksannolikhet X Riskkonsekvens.
Det klassiska sättet att se på risk saknar ofta det tekniska stöd som krävs för effektiv hantering. Moderna lösningar för testhantering fyller denna lucka genom att erbjuda funktioner som är anpassade för riskbaserad testning.
Kvantitativ eller kvalitativ bedömning
Det är ofta svårt att förutsäga den potentiella kostnaden för ett fel. Utan ytterligare information är det också näst intill omöjligt att med någon större säkerhet förutsäga sannolikheten för ett fel. Därför använder de flesta yrkesverksamma halvkvantitativa eller kvalitativa skalor för sannolikhet och konsekvens.
Det är vanligt att använda numeriska intervall från ett till fem för båda skalorna, vilket ger möjliga exponeringsvärden från ett till tjugofem. Men få testare, utvecklare eller intressenter tilldelar dessa siffror med någon större säkerhet, så det är vanligt att helt enkelt gradera riskexponeringen direkt med en skala från 1 till 5, eller — ännu enklare — genom en röd, gul eller grön bedömning. Vissa går så långt att de bara säger att risker ingår i omfattningen eller ligger utanför omfattningen, men vi menar att detta är en alltför stor förenkling.
Oavsett om du kvantifierar riskerna eller färgkodar dem i tabellen är den avgörande aspekten av riskbedömningar inte poängsättningen, utan de samtal och diskussioner som uppstår när ni tilldelar och diskuterar poängen.
För att felcitera Eisenhower: riskplanen är ingenting, riskplaneringen är allt.
Om du ombeds att poängsätta risker med större precision än skalor från ett till tre (eller fem om det verkligen krävs) bör du allvarligt överväga om de siffror du tilldelar har något verkligt värde.
Numerisk poängsättning kan ge intryck av vetenskaplig stringens, men om siffrorna bygger på gissningar lurar du bara dig själv. Om siffrorna synliggör meningsskiljaktigheter, till exempel när en användare säger ”fem” och utvecklaren säger ”ett!”, finns det anledning till ett samtal eftersom förväntningarna eller uppfattningarna uppenbarligen skiljer sig åt.
Var försiktig med att använda ett enkelt system där risker antingen ingår i omfattningen eller ligger utanför den. Det kan vara tydligt vilka risker som ska hanteras genom testning. Projekt utvecklas dock över tid och försenas ofta, vilket innebär att kompromisser måste göras. Om riskerna inte prioriteras på något sätt måste du granska alla risker som berörs för att avgöra vilka som kan behöva tas bort från eller läggas till i omfattningen.
Vi kommer att diskutera avgränsning, prioritering och skalning mer i detalj i kommande artiklar, så håll utkik.
Produktrisk och testning
Diskussionen om (produkt)risker kommer att synliggöra intressenternas farhågor kring sannolikheten för fel inom kritiska delar av projektet eller systemet. När vi har en lista över produktrisker, hur omsätter vi den i åtgärder och specifika testplaner? Innan vi kan besvara den frågan måste vi förstå lite bättre hur testning påverkar eller inverkar på våra riskbedömningar.
Testning minskar inte risker – den ger information till riskbedömningar
Du hör ofta människor säga att ”testning minskar risker”. Det stämmer inte — testning kan ibland öka risken. Mantrat att testning minskar risker bottnar i en bristande förståelse för både risker och testning.
Låt oss säga att vi har identifierat en risk för att någon funktion kan sluta fungera. Vi utformar ett test och kör det. Testet kan godkännas eller underkännas. Hur skulle ett godkänt eller underkänt test påverka vår riskbedömning?
För det första påverkar tester inte vår förståelse av konsekvensen av ett fel. Konsekvensen av ett fel är vad den är, och testning förändrar inte det.
Det finns fyra relevanta testresultat och deras påverkan på risksannolikheten. Dessa sammanfattas i denna tabell:
| Riskens sannolikhet ökar | Riskens sannolikhet minskar | |
| Testet passerar | Nej. Ett godkänt test kan bara få oss att känna oss säkrare på att ett fel inte kommer att inträffa. (Detta förutsätter att våra tester är meningsfulla.) | Ja, så småningom. När vi kör allt fler tester som passerar och utforskar olika scenarier minskar sannolikheten för fel. |
| Testet misslyckas | Möjligen, beroende på vilket fel det gäller. Men sannolikheten minskar med tiden. Vi förutsåg att denna feltyp skulle inträffa; vårt testval har därmed bekräftats. Lyckligtvis kan vi åtgärda detta nu och fokusera vår testning på att minska risken för andra fel av denna typ. | Inte särskilt sannolikt, såvida vi inte gjorde fel i vår riskbedömning. |
Genom att köra tester som vi förknippar med en viss risk får vi allt mer information för att förfina vår riskbedömning. Om testerna misslyckas har vårt val bekräftats. När vi åtgärdar felet och testar igen bör vår riskbedömning minska när testerna passerar. Men om vi fortsätter att hitta nya eller fler buggar kan vi omvärdera risken som högre.
Tänk på följande: om du kör ett test och resultatet inte påverkar din sannolikhetsbedömning åt något håll – då är det förmodligen ett värdelöst test.
Nu när du förstår testningens potential att informera vår riskbedömning kan vi titta på hur tester specificeras utifrån riskbeskrivningar.
Riskbaserad testplanering
När vi som testare har identifierat en produktrisk som bör uppmärksammas behöver vi formulera en uppsättning tester som visar att den aktuella feltypen är mindre sannolik. Vår teststrategi kommer självklart att vara att framkalla feltypen på så många sätt som möjligt, och genom detta antingen:
- uppleva fel, upptäcka buggar och åtgärda dem (vilket minskar risken för den feltypen), eller
- uppleva att testerna passerar, varpå vår tilltro till att en feltyp är mindre sannolik ökar.
Sammantaget fokuserar våra tester på olika sätt som en utvald feltyp kan uppstå på. Anta exempelvis att risken var ”att inte beräkna premien för en motorförsäkring korrekt”. I detta fall kan ett lämpligt testmål vara ”visa, med hjälp av all-pairs-tekniken för indata, att systemet beräknar motorförsäkringspremien korrekt”. Detta testmål kan ges till en testare som sedan tar fram en heltäckande uppsättning testfall med hjälp av all-pairs, till exempel.
Praktiska aspekter
Nu till några praktiska överväganden kring riskbaserad testning.
Vad händer om intressenterna inte är intresserade av att hjälpa till med riskbedömningen?
Det kan vara svårt att få intressenterna att avsätta tid för att hjälpa dig att identifiera och bedöma risker samt utforma din testplan.
Vad händer om det finns flera testalternativ för en produktrisk?
Så är det förstås nästan alltid. För att testa en funktion som inger oro kan du exempelvis använda någon av flera olika testdesigntekniker, eller modellera funktionen på ett unikt sätt och ta fram tester utifrån den modellen. Det finns flera olika täckningsmått som du kan använda för att sätta ett mål. Du kan testa en funktion manuellt eller med hjälp av ett verktyg eller annan teknik.
Vi tittar på hur du kan göra sådana val i nästa artikel, ”Hur mycket testning är tillräckligt?”.
Vad händer om testning (för att hantera en risk) kostar för mycket?
Eftersom det nästan alltid finns alternativ och det inte finns någon gräns för hur mycket testning man kan tillämpa för att undersöka en risk och informera en riskbedömning måste ett val göras. Det säger sig självt att vissa alternativ kommer att bedömas som för dyra. När du presenterar alternativ för intressenterna behöver du därför ha minst ett alternativ som är överkomligt och ett som kan vara oöverkomligt.
Återigen: vi tittar på hur du kan göra sådana val i nästa artikel, ”Hur mycket testning är tillräckligt?”.
Om vi testar funktioner med hög risk mer, testar vi då andra funktioner mindre?
Om testbudgeten är fastställd för ett team, eller om teamets storlek och antalet testare är fast, är mängden testning som personerna kan utföra begränsad (under en given tidsperiod eller tidsboxad period). Om vi lägger större vikt vid vissa funktioner måste därför testningen av andra funktioner minska. Täckningen, eller åtminstone arbetsinsatsen för olika funktioner, varierar med risken.
Det här kan ses som att när ett test misslyckas och en bugg hittas i systemet är den allvarlighetsgrad som tilldelas buggen sannolikt nära relaterad till konsekvensen av det felet (i produktion). Allvarligare buggar åtgärdas eftersom de helt enkelt är viktigare för intressenterna.
En produktriskanalys synliggör de områden där buggar, eftersom de är viktiga, sannolikt kommer att åtgärdas. Genom att använda en riskanalys för att synliggöra var testning sker och/eller var mer testning tillämpas ökar alltså sannolikheten att vi hittar viktiga buggar, samtidigt som sannolikheten minskar att vi hittar buggar i funktioner som intressenterna kanske bryr sig mindre om.
Det vore trevligt att tänka att vi ibland kan testa överallt på ett mer jämnt sätt. Men när resurser och tid är begränsade (och det är de alltid, eller hur?), hjälper ett riskbaserat arbetssätt dig att utnyttja testarnas tid mer effektivt och ändamålsenligt.
Tänk om testning inte är rätt åtgärd?
Innan du lägger tid på att i detalj utforma ett testupplägg för en produktrisk är det viktigt att även alternativ som inte innebär testning övervägs. Anta till exempel att det finns en stor oro för att en systemkomponent kanske inte kommer att fungera tillräckligt bra i produktion och att svarstiderna eller tillförlitligheten är dåliga. Naturligtvis kan du utföra belastningstester och försöka felsöka dig ur problemen. Men andra alternativ kan vara:
- Köp komponenten från en tredje part, bygg den inte själv och ta inte risken.
- Gör om lösningens arkitektur så att belastningen fördelas över flera komponentinstanser.
- Flytta bearbetningen till ett batchsystem som använder en kopia av data.
- I stället för att genomföra en storskalig implementering för alla användare på en gång, använd ett stegvis arbetssätt där kunder implementeras region för region och prestandan övervakas noggrant.
- Och så vidare.
Ofta är en annan åtgärd för att förhindra att problem uppstår mer effektiv och ekonomisk än att testa för att hitta problemen senare.
Förstå testningens roll i riskhanteringen
Testning kan minska risken med en lansering. Om vi använder en riskbedömning för att styra vår testaktivitet blir testarnas mål uttryckligen att utforma tester som upptäcker fel så att de kan åtgärdas och därigenom minska risken för en felaktig produkt.
Feldetektering minskar den kvarvarande risken för fel i drift, där kostnaderna ökar mycket kraftigt. När ett test hittar ett fel och det korrigeras minskar antalet fel och följaktligen minskar den övergripande sannolikheten för fel.
Man kan också se det så här: den ”mikrorisk” som beror på felet elimineras. Men man måste komma ihåg att testning inte kan hitta alla fel, så det kommer alltid att finnas latenta fel som förblir orörda och som testningen inte har gett någon direkt information om.
Men om vi fokuserar på kritiska funktioner och hittar fel i dessa, är oupptäckta fel i de kritiska funktionerna mindre sannolika. De fel som finns kvar i systemets icke-kritiska funktioner får mindre allvarliga konsekvenser.
En sista anmärkning: själva riskanalysprocessen är riskfylld. Riskanalys kan både överskatta och underskatta riskerna, vilket leder till mindre än perfekt beslutsfattande. Riskanalys kan också bidra till en skuldbeläggande kultur om den drivs för långt.
Bland andra möjliga fallgropar med riskanalys måste du förstå att det inte finns någon absolut risk som kan beräknas efter att projektet är avslutat. Riskernas natur är att de är osäkra. Precis som med testningens effektivitet kan värdet av en riskanalys endast fastställas i efterhand, när projektet är avslutat.
Och det var allt för vårt manifest för riskbaserad testning. Konceptet kommer att återkomma genom hela serien om ledarskap inom testning, så håll utkik efter fler artiklar!
Anmäl dig till nyhetsbrevet från The QA Lead för att få meddelanden när nya delar av serien publiceras. Dessa inlägg är utdrag ur Pauls kurs Ledarskap inom testning, som vi varmt rekommenderar om du vill fördjupa dig i detta och andra ämnen. Om du gör det kan du använda vår exklusiva kupongkod QALEADOFFER för att få $60 rabatt på kursens fullständiga pris!
