This document provides an overview of risk-based testing (RBT) including the process, examples, and benefits. It discusses how to identify risks, analyze them by considering likelihood and impact, and then mitigate risks through testing. The key aspects of RBT covered include building a risk matrix, prioritizing testing based on risk level, and applying RBT at different scales from large changes to small quick tasks. Overall, RBT is presented as a systematic approach to make testing more efficient and ensure the most critical risks are addressed.

1. Risk Based
Testing
Matrix, Process & Examples
Bassam Al-Khatib
ISTQB Full CTAL Advanced Level &
Certified Ethical Hacker
A new idea toward technical software testing

2. Ground Rules 2
 Silent Mobile phones
 Questions are allowed at all times
 Join Sessions on time
 One meeting No sub-meetings

3. Area & Tools
Expectation? Parking Lot
3

4. Session Description
 This training will help Software Test
Engineers globally to Perform Risk
Based Testing (RBT) during design,
plan and implement testing using
a systematic approach and
applicable techniques
 Trainer: Bassam Al-Khatib
 Duration: 3 hours and 30 minutes
 Prerequisites: Elementary
certificates (Beginners level) in
software testing certificate
4

5. Instructional
Methods
 Following are instructional methods
 Lectures
 Group Discussions
 Individual/group assignments
5

6. Session Objectives
Build
Culture
How to
use?
When to
use?
Outline activities of risk-based approach for planning and executing
technical testing
6

7. What's in it for me?
 This session is a chance for one more deep study for Risk Based
Testing (RBT), by analyzing approach, building risk matrixes, building
RBT activities to form a complete process and showing some
examples accordingly.
7

8. Agenda
 Preface
 How to start with Risk Based testing?
 Risk Management
 Risk identification
 Risk Analysis
 Risk Mitigation
 RBT in the Large & Small
 RBT Benefits
 Conclusion
8

9. Preface
The possibility of negative results, that would
occur and decrease customer perception
of a product quality or project success.
•What Risk Means?
9

10. Preface
 Enhancing the definitions:
 Risk
 Risk Type
 Product Risk
 Project Risk
 Risk Based Testing
10

11. Preface 11
 How do we define RBT?

12. Preface
 RBT is not Bug hunting
 RBT is not exploratory or experience based testing
 RBT is not a requirement based testing
 If you cant calculate risk results then its not RBT
12

13. Preface
In testing software we are concerned with two types of risks :
• Example: A defect that could
cause a product crash during
normal operation
Product
Risk
• Example: A possible staffing
shortage that could delay
completion of a project
Project
Risk
13
- Potential that patch or
fix will not fit for
purpose
- System crash during
normal
operation(software
stability)
- Commitment to
customers or
management
- Staffing shortage
- Poor productivity

14. Preface
 The difference between two types of risks that you can run a test
against the product (software) to define if there any system crashes.
 But project risks are not testable . You cant test for staffing shortage
 In this session our concern is controlling Product (Software) Risks.
14

15. Preface
 Classifying level of risk, the simplest
is to look at two factors:
 The likelihood of the problem
occurring; i.e., being present in the
product when it is delivered for
testing
 The impact of the problem should
it occur; i.e., being present in the
product when it is delivered to
customers or users after testing
During
Testing
Delivery
Risk =
Likelihood
X Impact
15

16. How to Start with RBT? 16
 When ?
 Risk-based testing applied to
the project at very initial level
on any project
 Risk Management how to
start…
 Applying a set of procedures
and practices to identify,
analyze, prioritize and
controlling risk.

17. Risk Management
 Risk Management activities:
 Risk identification
 Risk analysis
 Risk mitigation
Identification
(1)
Analysis (2)
Mitigation
(3)
17

18. Risk Identification
 Identifying risks using the
following techniques:
 Expert interviews
 Independent assessments
 Use of risk templates
 Project retrospectives
 Risk workshops
18

19. Risk Identification
 Identifying risks using the
following techniques:
 Brainstorming ( Effective Test
Planning Meetings)
 Checklists
 Calling on past experience
 Review requirements
specifications (FRS, URS)
19

20. Risk Identification – By Example
 Let us apply some of the mentioned techniques to the following
Example.
 Lets go back to the printed example you have to discuss.
 The output of this group assignment is to record the identified risks.
 Build your FEMA Template [Failure Mode and Effect Analysis]
20

21. Risk Analysis – By Example
 Using the same FEMA template add “Likelihood” and “Impact” to
calculate “Expected Risks”
 You can then graph the Total loss of functionality according to
Likelihood & Impacts
21

22. Risk Analysis – By Example
 Build your risk matrix …
22
Likelihood Level Description
Rare 1 Existing / New feature is not affected by changed code
Unlikely 2 Existing / New feature is affected
Likely/Possible 4 Existing / New feature is modifying current behavior
Certain 8
Existing / New feature is impacted by code change(broken
behavior after the change)
Impact Level Description
Insignificant 1 No need to desing or execute tests
Minor 2 Test should cover Straight foreword scenarios only
Moderate 3 Test should cover Staright foreword and some related features
Major 4 Test should cover ALL
Risk Level Description Color Code
Low 1 to 3 No need to test
Medium 4 to 16 Testing during development phase is enough
High 24-32 Should be tested again during final testing

23. Risk Analysis – By Example
 Likelihood vs Impact
23
1
4
1
8
4 4
2
4
1 2 3 4 5 6 7 8 9 10
Likelihood VS Impact
Series1 Series2

24. Risk Mitigation
 Is the last step after risks being identified and analyzed
 It is the responsibility of Software Test Engineer to mitigate quality risks
via testing like:
 Applying new test types (Security , Performance)
 Use Extra test design techniques throughout the entire lifecycle
 New test cases to be added/removed
 Apply extra regression test for selected areas of functionality
24

25. Risk Mitigation
 It is the responsibility of the Test Manager to use the following
techniques to mitigate Project / Product risks:
 Test environment and tools readiness
 Check staff availability and qualification
 Prevent low quality of inputs to testing
 Prevent overly high rates of change for work products delivered to
testing
 Reduce lack of standards, rules, and techniques for the testing effort.
25

26. Risk Mitigation
 Proactively It is the responsibility of the Technical Test Analyst to use
the following techniques to mitigate Project / Product risks:
 Choose an appropriate test design technique(s)
 Reviews and inspections
 Reviews of test design
 The use of the most experienced people for complex tasks
 The strategies chosen for confirmation testing (retesting) and regression
testing
26

27. Risk Mitigation
 Helpful questions to Answer:
 Were requirements written well?
 Shall we institute reviews to improve their quality?
 Does the designed test demonstrates operation under certain
conditions and does not constitute a proof of correctness under all
possible conditions?
 Can we prioritize test according to level of risk?
 Do we need to reduce test execution time? Are the residual risk is
acceptable?
27

28. Risk based in the Large & Small
 You should decide which approach to go with; which depends on
code change size.
 The presented methodology was for medium to large size changes
 Meanwhile, you still can do the same practice in the small roughly
for quick & small tasks.. See next slide
28

29. Risk based in the Large & Small 29
Who will do the
test ?
What is your
coverage/scope?
Why you are
testing? What are
the risks?
What testing type
do you need?
How will you
decide about exit
criteria?
RBTinthesmall
Select&prioritizetests
Wheretovisitfirst?

30. Risk based in the Large & Small
Pros & Cons
30
RBT in the Large RBT in the Small
Much detailed Short and brief
Time cost Quick
Low residual risks Unexpected residual risks

31. RBT Benefits
RBT will not leave you blind; The higher the test coverage in an
area, the lower the residual risk. The fewer bugs we’ve found
in an area, the lower the residual risk.
Allocating test effort based on risk is the most efficient way to
minimize the residual quality risk upon release (“pick the right
tests out of the infinite cloud of possible tests”)
Measuring test results based on risk allows the
organization to know the residual level of quality risk during
test execution and to make smart release decisions
31

32. RBT Benefits 32
Testing efforts are effectively organized, and level of priority of
each risk item is rated
Discovery of business-critical areas that were missed
No infeasible testing

33. Conclusion
 RBT is a culture that needs to be shared
 RBT makes it easier to decide about product
risks
 Can help to control both testing as well as risks
 RBT will lead to more feasible testing
 RBT can be applied always as per size of
change/fix
33

34. References
Advanced Software Testing V3 ISTQB CTAL – TTA Syllabus
34

35. Thank You!
35