Risk-based Testing
The Devil is in the Details

1

2013-09-27

PA1

Confidential
Introduction
• Johan Hoberg

• Sony Mobile
▫ ~10 years
▫ Tester, Test Team Leader, Test Architect

• This is a presentation of my experiences
of risk-based testing
2

2013-09-27

PA1

Confidential
Definition
• Risk-based testing (RBT) is a type of software
testing that prioritizes the tests of features and
functions based on the risk of their failure - a
function of their importance and likelihood or
impact of failure.
(http://en.wikipedia.org/wiki/Risk-based_testing)

3

2013-09-27

PA1

Confidential
The Devil is in the Details
• Refers to a catch or mysterious element hidden in
the details
• Derives from “God is in the Details”

▫ Generally attributed to Gustave Flaubert (1821–1880)

• It is easy to ask for efficient, risk-based testing
• It is much more difficult to actually do it well
4

2013-09-27

PA1

Confidential
System Under Test

Configuration 1
Configuration 2

Android Gingerbread Generic
Configuration 3
Android Gingerbread Customer A

Android Gingerbread Customer B
Android Jellybean Generic

Product X
Product Y

Android Jellybean Customer A

Android Jellybean Customer B
5

2013-09-27

PA1

Confidential
System Under Test

6

2013-09-27

PA1

Confidential
Changes in the System
• There is a change introduced somewhere in the
system
• Could be a bug fix, a change request, a new
feature, refactoring, etc.

7

2013-09-27

PA1

Confidential
Scope Selection
• Do you run every available test on every possible
configuration of the system and verify all
interoperability?
• A smart scope is necessary to make it containable
• We must be able to reuse test results between
products, configuration, and branches
8

2013-09-27

PA1

Confidential
Scope Selection based on Risk

Change
Introduced

9

2013-09-27

PA1

System Impact

Risk-based
Scope

Confidential
Complex vs. Complicated
• Complicated
▫ Opposite of simple
▫ Containing intricately combined or involved parts

• Complex
▫ Opposite of predictable?
▫ This adjective means having parts so
interconnected as to make the whole perplexing
10

2013-09-27

PA1

Confidential
Complex System
• A complex system is difficult to predict

• It is therefore difficult to plan which actions to
take to mitigate different outcomes
• It is difficult to plan which tests to run to cover
all potentially relevant defects
11

2013-09-27

PA1

Confidential
Reduce Complexity
Reduce
Complex System
complexity

Very difficult!

Scope Selection
Change

12

2013-09-27

PA1

Confidential
Example
• A change is introduced into the Display Driver
component – What do I need to test?
▫ Camera?
▫ Interoperability with TV and similar devices?
▫ Multimedia
 View pictures, video etc.?

▫ All UI testing?
▫ Other parts of the system?
13

2013-09-27

PA1

Confidential
Reduce Complexity
• Risk Analysis
• Automated Test Framework
• Early Exploratory Testing

14

2013-09-27

PA1

Confidential
Risk Analysis – Input Data
Feature & Hardware Delta
Historical Data
Code Changes
System Dependencies &
Architecture
15

2013-09-27

PA1

•Easy to obtain
•Might give us an indication on
where to start looking, but can
often give false confidence in
scope selection, especially
when it comes to E2E system
test
•Hard to obtain
Confidential
Risk Analysis – Risk Model
Risk
Identification

Probability

Severity (S)
Occurrence (O)
Detection (D)
16

2013-09-27

PA1

Consequence

Mitigation
Plan

Risk Priority Number (RPN) = S*O*D

Confidential
Risk Analysis - Complex vs. Complicated

Risk analysis of
whole system is
complex

17

2013-09-27

PA1

Risk analysis of
sufficiently small
part is more
complicated than
complex
Confidential
Risk Analysis Database
• If each function performs risk analysis on their
components and enters risks in a database this
information could be used on system level to get
better understanding of impact of specific
changes
• Requires a uniform way of handing risk
information
18

2013-09-27

PA1

Confidential
Problems?
• We can get a lot of data that will help us select a
scope – but ultimately we will introduce a lot of risk
if we do not know how the system is designed, and
how different components depend on each other
• To get a complete dependency map of the whole
system requires not only a good risk-handling
infrastructure, but a common effort from a lot of
people
19

2013-09-27

PA1

Confidential
Dependency Map Example
Application

Application

Application

Application
Framework

Application

Application

Application
Framework
Library
Driver

20

2013-09-27

PA1

Confidential
Automated Test Framework
Change + Basic
Risk Analysis

Automated Test
Execution

21

Scope Setting

Test Results
Analysis

2013-09-27

PA1

Test Execution

Confidential
Automated Test Framework
Change

Automated Tests
Executed

Better understanding of
System Dependencies
22

2013-09-27

PA1

Failed Tests
Investigated

Change in component
mapped towards failed tests
in other components
Confidential
Self-learning System
• Over time you will have more and more
information about how different changes impact
the system
• Map code changes to failed tests
• This impact map can further help you
set an efficient scope
23

2013-09-27

PA1

Confidential
Continuous Integration
• The more code changes we have and the more
isolated these code changes are, the easier it is to
create the impact map
• If you only have one integration per month, with
thousands of lines of code changed in different
parts of the system, it will be difficult to draw
conclusions
24

2013-09-27

PA1

Confidential
Problems?
• The information value you receive is dependant
on how good the tests are
• Dependency graph grows over time – in the
beginning there is very little data

25

2013-09-27

PA1

Confidential
Early Exploratory Testing
Change + Basic
Risk Analysis

Exploratory
Testing

26

Scope Setting

Test Results
Analysis

2013-09-27

PA1

Test Execution

Confidential
Codifying Experience
• How do you transfer the knowledge gained from
one tester to the other?
• The understanding about impact and
dependencies we gain from performing
exploratory testing must be stored in a way
which makes it accessible to other testers for
their risk-based scope selections
27

2013-09-27

PA1

Confidential
Manual Dependency Map
• After each exploratory session it is possible to
add information to a dependency map, where
you indicate which changes were made, and
what impact those changes had
• It needs to be done in a way which is quick and
easy, otherwise it will not be done at all
28

2013-09-27

PA1

Confidential
Problems?
• Additional time might be needed before testers
get experience with the new process
• It will be more difficult to time plan activity
before early exploratory testing is done – this
can cause problems with test/project leaders and
managers
• It requires skilled testers
29

2013-09-27

PA1

Confidential
Final thoughts
• Every risk-based scope introduces risk – our
goal is to eliminate any unnecessary risk
• Without skilled testers to write good automated
tests or perform exploratory testing it becomes
very difficult without a very intricate risk/impact
framework
30

2013-09-27

PA1

Confidential
Conclusion
• It is very difficult to perform riskbased testing for a large, complex
system

• It is very easy to ask someone else to
reduce their test scope by
introducing risk-based testing
31

2013-09-27

PA1

Confidential
Contact
• Email
▫ johan.hoberg@outlook.com

• Slideshare
▫ www.slideshare.net/JohanHoberg

32

2013-09-27

PA1

Confidential

Risk-based Testing

  • 1.
    Risk-based Testing The Devilis in the Details 1 2013-09-27 PA1 Confidential
  • 2.
    Introduction • Johan Hoberg •Sony Mobile ▫ ~10 years ▫ Tester, Test Team Leader, Test Architect • This is a presentation of my experiences of risk-based testing 2 2013-09-27 PA1 Confidential
  • 3.
    Definition • Risk-based testing(RBT) is a type of software testing that prioritizes the tests of features and functions based on the risk of their failure - a function of their importance and likelihood or impact of failure. (http://en.wikipedia.org/wiki/Risk-based_testing) 3 2013-09-27 PA1 Confidential
  • 4.
    The Devil isin the Details • Refers to a catch or mysterious element hidden in the details • Derives from “God is in the Details” ▫ Generally attributed to Gustave Flaubert (1821–1880) • It is easy to ask for efficient, risk-based testing • It is much more difficult to actually do it well 4 2013-09-27 PA1 Confidential
  • 5.
    System Under Test Configuration1 Configuration 2 Android Gingerbread Generic Configuration 3 Android Gingerbread Customer A Android Gingerbread Customer B Android Jellybean Generic Product X Product Y Android Jellybean Customer A Android Jellybean Customer B 5 2013-09-27 PA1 Confidential
  • 6.
  • 7.
    Changes in theSystem • There is a change introduced somewhere in the system • Could be a bug fix, a change request, a new feature, refactoring, etc. 7 2013-09-27 PA1 Confidential
  • 8.
    Scope Selection • Doyou run every available test on every possible configuration of the system and verify all interoperability? • A smart scope is necessary to make it containable • We must be able to reuse test results between products, configuration, and branches 8 2013-09-27 PA1 Confidential
  • 9.
    Scope Selection basedon Risk Change Introduced 9 2013-09-27 PA1 System Impact Risk-based Scope Confidential
  • 10.
    Complex vs. Complicated •Complicated ▫ Opposite of simple ▫ Containing intricately combined or involved parts • Complex ▫ Opposite of predictable? ▫ This adjective means having parts so interconnected as to make the whole perplexing 10 2013-09-27 PA1 Confidential
  • 11.
    Complex System • Acomplex system is difficult to predict • It is therefore difficult to plan which actions to take to mitigate different outcomes • It is difficult to plan which tests to run to cover all potentially relevant defects 11 2013-09-27 PA1 Confidential
  • 12.
    Reduce Complexity Reduce Complex System complexity Verydifficult! Scope Selection Change 12 2013-09-27 PA1 Confidential
  • 13.
    Example • A changeis introduced into the Display Driver component – What do I need to test? ▫ Camera? ▫ Interoperability with TV and similar devices? ▫ Multimedia  View pictures, video etc.? ▫ All UI testing? ▫ Other parts of the system? 13 2013-09-27 PA1 Confidential
  • 14.
    Reduce Complexity • RiskAnalysis • Automated Test Framework • Early Exploratory Testing 14 2013-09-27 PA1 Confidential
  • 15.
    Risk Analysis –Input Data Feature & Hardware Delta Historical Data Code Changes System Dependencies & Architecture 15 2013-09-27 PA1 •Easy to obtain •Might give us an indication on where to start looking, but can often give false confidence in scope selection, especially when it comes to E2E system test •Hard to obtain Confidential
  • 16.
    Risk Analysis –Risk Model Risk Identification Probability Severity (S) Occurrence (O) Detection (D) 16 2013-09-27 PA1 Consequence Mitigation Plan Risk Priority Number (RPN) = S*O*D Confidential
  • 17.
    Risk Analysis -Complex vs. Complicated Risk analysis of whole system is complex 17 2013-09-27 PA1 Risk analysis of sufficiently small part is more complicated than complex Confidential
  • 18.
    Risk Analysis Database •If each function performs risk analysis on their components and enters risks in a database this information could be used on system level to get better understanding of impact of specific changes • Requires a uniform way of handing risk information 18 2013-09-27 PA1 Confidential
  • 19.
    Problems? • We canget a lot of data that will help us select a scope – but ultimately we will introduce a lot of risk if we do not know how the system is designed, and how different components depend on each other • To get a complete dependency map of the whole system requires not only a good risk-handling infrastructure, but a common effort from a lot of people 19 2013-09-27 PA1 Confidential
  • 20.
  • 21.
    Automated Test Framework Change+ Basic Risk Analysis Automated Test Execution 21 Scope Setting Test Results Analysis 2013-09-27 PA1 Test Execution Confidential
  • 22.
    Automated Test Framework Change AutomatedTests Executed Better understanding of System Dependencies 22 2013-09-27 PA1 Failed Tests Investigated Change in component mapped towards failed tests in other components Confidential
  • 23.
    Self-learning System • Overtime you will have more and more information about how different changes impact the system • Map code changes to failed tests • This impact map can further help you set an efficient scope 23 2013-09-27 PA1 Confidential
  • 24.
    Continuous Integration • Themore code changes we have and the more isolated these code changes are, the easier it is to create the impact map • If you only have one integration per month, with thousands of lines of code changed in different parts of the system, it will be difficult to draw conclusions 24 2013-09-27 PA1 Confidential
  • 25.
    Problems? • The informationvalue you receive is dependant on how good the tests are • Dependency graph grows over time – in the beginning there is very little data 25 2013-09-27 PA1 Confidential
  • 26.
    Early Exploratory Testing Change+ Basic Risk Analysis Exploratory Testing 26 Scope Setting Test Results Analysis 2013-09-27 PA1 Test Execution Confidential
  • 27.
    Codifying Experience • Howdo you transfer the knowledge gained from one tester to the other? • The understanding about impact and dependencies we gain from performing exploratory testing must be stored in a way which makes it accessible to other testers for their risk-based scope selections 27 2013-09-27 PA1 Confidential
  • 28.
    Manual Dependency Map •After each exploratory session it is possible to add information to a dependency map, where you indicate which changes were made, and what impact those changes had • It needs to be done in a way which is quick and easy, otherwise it will not be done at all 28 2013-09-27 PA1 Confidential
  • 29.
    Problems? • Additional timemight be needed before testers get experience with the new process • It will be more difficult to time plan activity before early exploratory testing is done – this can cause problems with test/project leaders and managers • It requires skilled testers 29 2013-09-27 PA1 Confidential
  • 30.
    Final thoughts • Everyrisk-based scope introduces risk – our goal is to eliminate any unnecessary risk • Without skilled testers to write good automated tests or perform exploratory testing it becomes very difficult without a very intricate risk/impact framework 30 2013-09-27 PA1 Confidential
  • 31.
    Conclusion • It isvery difficult to perform riskbased testing for a large, complex system • It is very easy to ask someone else to reduce their test scope by introducing risk-based testing 31 2013-09-27 PA1 Confidential
  • 32.
    Contact • Email ▫ johan.hoberg@outlook.com •Slideshare ▫ www.slideshare.net/JohanHoberg 32 2013-09-27 PA1 Confidential