1. Riskanalysen och Supertestaren
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 resul tatet 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 in te 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.
2. 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 urva l 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 oli ka 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.
/Johan Hoberg