SlideShare ist ein Scribd-Unternehmen logo
1 von 2
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.
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

Weitere ähnliche Inhalte

Andere mochten auch

Conimel terminais2012
Conimel terminais2012Conimel terminais2012
Conimel terminais2012
mapple2012
 
Validation practical definition
Validation   practical definitionValidation   practical definition
Validation practical definition
Johan Hoberg
 
Density Anomaly
Density AnomalyDensity Anomaly
Density Anomaly
twindsor1
 
Olimpus antenas2012
Olimpus antenas2012Olimpus antenas2012
Olimpus antenas2012
mapple2012
 
IA Innovatieve marketingcommunicatie door Annick de Swaef. Sessie 4. KHLeuven
IA Innovatieve marketingcommunicatie door Annick de Swaef. Sessie 4. KHLeuvenIA Innovatieve marketingcommunicatie door Annick de Swaef. Sessie 4. KHLeuven
IA Innovatieve marketingcommunicatie door Annick de Swaef. Sessie 4. KHLeuven
Ikinnoveer
 

Andere mochten auch (13)

A Very Potter Interlude
A Very Potter InterludeA Very Potter Interlude
A Very Potter Interlude
 
Conimel terminais2012
Conimel terminais2012Conimel terminais2012
Conimel terminais2012
 
The Secret of Success
The Secret of SuccessThe Secret of Success
The Secret of Success
 
Validation practical definition
Validation   practical definitionValidation   practical definition
Validation practical definition
 
S.ss702 l 7
S.ss702 l 7S.ss702 l 7
S.ss702 l 7
 
Density Anomaly
Density AnomalyDensity Anomaly
Density Anomaly
 
Olimpus antenas2012
Olimpus antenas2012Olimpus antenas2012
Olimpus antenas2012
 
Erudite financial services pvt. ltd.
Erudite financial services pvt. ltd.Erudite financial services pvt. ltd.
Erudite financial services pvt. ltd.
 
Rosita xii ips 2
Rosita xii ips 2Rosita xii ips 2
Rosita xii ips 2
 
Memory bank
Memory bankMemory bank
Memory bank
 
World Class: Flintknapping the Glowing Rectangle in the New Ubiquity Era
World Class: Flintknapping the Glowing Rectangle in the New Ubiquity EraWorld Class: Flintknapping the Glowing Rectangle in the New Ubiquity Era
World Class: Flintknapping the Glowing Rectangle in the New Ubiquity Era
 
IA Innovatieve marketingcommunicatie door Annick de Swaef. Sessie 4. KHLeuven
IA Innovatieve marketingcommunicatie door Annick de Swaef. Sessie 4. KHLeuvenIA Innovatieve marketingcommunicatie door Annick de Swaef. Sessie 4. KHLeuven
IA Innovatieve marketingcommunicatie door Annick de Swaef. Sessie 4. KHLeuven
 
ПУМС 2011
ПУМС 2011ПУМС 2011
ПУМС 2011
 

Mehr von Johan Hoberg

Mehr von Johan Hoberg (20)

Approaches to unraveling a complex test problem
Approaches to unraveling a complex test problemApproaches to unraveling a complex test problem
Approaches to unraveling a complex test problem
 
A business case for a modern QA organization
A business case for a modern QA organizationA business case for a modern QA organization
A business case for a modern QA organization
 
Signing off on Quality
Signing off on QualitySigning off on Quality
Signing off on Quality
 
Quality Information Coverage - A QI Concept
Quality Information Coverage - A QI ConceptQuality Information Coverage - A QI Concept
Quality Information Coverage - A QI Concept
 
The Bug Backlog - An Evergrowing Mountain
The Bug Backlog - An Evergrowing MountainThe Bug Backlog - An Evergrowing Mountain
The Bug Backlog - An Evergrowing Mountain
 
Quality Intelligence: Transparency & Visibility
Quality Intelligence: Transparency & VisibilityQuality Intelligence: Transparency & Visibility
Quality Intelligence: Transparency & Visibility
 
Building a QA Mindset
Building a QA Mindset Building a QA Mindset
Building a QA Mindset
 
What is QI?
What is QI?What is QI?
What is QI?
 
Building High Quality Software
Building High Quality Software Building High Quality Software
Building High Quality Software
 
Testit 2017 - Exploratory Testing for Everyone
Testit 2017 - Exploratory Testing for EveryoneTestit 2017 - Exploratory Testing for Everyone
Testit 2017 - Exploratory Testing for Everyone
 
Don’t celebrate failure. Don’t celebrate success. Celebrate commitment, owner...
Don’t celebrate failure. Don’t celebrate success. Celebrate commitment, owner...Don’t celebrate failure. Don’t celebrate success. Celebrate commitment, owner...
Don’t celebrate failure. Don’t celebrate success. Celebrate commitment, owner...
 
Moving from scripted regression testing to exploratory testing
Moving from scripted regression testing to exploratory testingMoving from scripted regression testing to exploratory testing
Moving from scripted regression testing to exploratory testing
 
Building High Quality Software
Building High Quality SoftwareBuilding High Quality Software
Building High Quality Software
 
Quality, Testing & Agile Methodologies
Quality, Testing & Agile MethodologiesQuality, Testing & Agile Methodologies
Quality, Testing & Agile Methodologies
 
QI, not QA
QI, not QAQI, not QA
QI, not QA
 
Defining Test Competence
Defining Test CompetenceDefining Test Competence
Defining Test Competence
 
Why all deadlines are bad for quality
Why all deadlines are bad for qualityWhy all deadlines are bad for quality
Why all deadlines are bad for quality
 
QI, not QA
QI, not QAQI, not QA
QI, not QA
 
Do we really need game testers?
Do we really need game testers?Do we really need game testers?
Do we really need game testers?
 
Hardware/Software Integration Testing
Hardware/Software Integration TestingHardware/Software Integration Testing
Hardware/Software Integration Testing
 

Riskanalysen och supertestaren

  • 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