Riskanalysen, och urvalet av tester för att mitigera identifierade risker, är kritisk om man jobbar med riskbaserad testning. Sannolikheten att ett fel har introducerats i ett komplext system vid någon slags förändring är en viktig del av denna riskanalys. Sannolikheten kan bedömas baserat på en mängd olika parametrar. Dessa parametrar kan vara allt från kodändringar, beroende mellan komponenter, och historisk felbenägenhet, till operativsystem och hårdvara. Vilka parametrar som är intressanta beror på kontexten. Efter att riskanalysen är genomförd bör resultatet påverka urvalet av tester som exekveras.
Tyvärr är detta sista steg ofta lång ifrån trivialt. En supertestare kan direkt avgöra hur olika risker slår på urvalet av tester, men för oss som ligger någonstans i mitten av normalfördelningen är det inte alltid lika lätt. Ju mindre domänkunskap och ju mindre testerfarenhet, desto svårare att göra denna bedömning.
Frågan är om det går att bryta ner detta steg till någonting mer konkret. Något som är greppbart för nya testare, eller testare som saknar den nödvändiga domänkunskapen. Nedan följer ett exempel på en sådan nerbrytning.
Första steget kan vara att klargöra hur de risker som identifierats ska bedömas. Hur vet jag om en ändring är stor eller liten, att ett område har många eller få beroenden, eller om ett område är historiskt felbenäget eller inte? Det behövs kriterier för alla parametrar så att det går att kategorisera deras värde. Över X antal rader kod modifierade är en stor ändring. Mer än Y beroenden kategoriserar en komponent som att den har många beroenden. Mer än Z fel det senaste året indikerar ett felbenäget område. Och så vidare. Hur dessa kriterier bestäms är så klart helt beroende av kontexten.
Om det visar sig att det har skett mycket ändringar i ett visst område, en stor ändring i ett område med många beroenden, eller det går att se på historisk data att ett visst område är felbenäget – hur påverkar detta vårt urval av testfall?
Andra steget är alltså att lista konkreta konsekvenser av de identifierade riskerna. Om en ändring i en komponent kategoriseras som stor bör jag förändra mitt urval av testfall enligt handlingsplan A. Om ett område kategoriseras som historiskt felbenäget bör jag förändra mitt urval av testfall enligt handlingsplan B. Om en ändring sker i en komponent som kategoriseras som att ha många beroenden bör jag förändra mitt urval av testfall enligt handlingsplan C. Handlingsplanerna är också de väldigt beroende av kontexten.
Hade vi alla varit supertestare med rätt domänkunskap så hade detta varit överflödigt. Men om man inte är en supertestare kan man lätt bli överväldigad av uppgiften om någon ber om ett riskbaserat urval av testfall baserat på ett antal olika parametrar. Genom att koppla ihop riskanalysen och urvalet av testfall med klara kriterier för riskparametrarna och tydliga handlingsplaner för olika parameterkombinationer kan det göra uppgiften lite mer hanterbar.
Riskbaserad testning kan utformas och utföras på en mängd olika sätt i olika kontexter, och denna artikel täcker bara en liten del av ämnet, men den speglar några av mina tankar kring en del av den problematik jag har stött på i min vardag.
Hej Johan,
Skulle du kunna förtydliga lite vad du menar med en handlingsplan? Som jag läser det så verkar det som att en handlingsplan är en viss delmängd av en redan existerande samling testfall, stämmer det? Jag misstänker att jag feltolkar dig lite. Är handlingsplanen begränsad till just testfall, eller kan det lika gärna finnas tester som ska automatiseras eller köras med begränsade instruktioner eller charters? Om den är begränsad till testfalls-baserade tester, bör den i så fall ta ställning till olika typer av testtekniker som testfallen bör skrivas med?
En annan fråga: Vad skulle t.ex. handlingsplan C ha för karaktär? Det vill säga, hur ser ett sådant urval ut om man skulle beskriva det? (exempel på beskrivningar jag fiskar efter: stort, litet, brett, djupgående, scenario-baserat, utforskande, fritt, tidboxat, detaljerat, osv)