Purpose – The purpose of this document is to provide an approach to Risk-based testing
Intended Audience
Maintenance of the document
Review this document at least once annually and update it. QE Chapter team is a custodian of this document and is responsible for maintaining in centralized document management tool and sharing it with Squads. QE Chapter team will receive project requirements (If any specific) and feedback periodically to review and update the document as required.
Objectives – The objective of defining the Risk-based testing approach is to identify the test cases that are high-risk prone and execute them in the given timeline
Description – Risk-based testing approach is a method of identifying the critical and important tests through the Risk analysis process
Why Risk Based Testing?
Testing without compromising on the quality in Agile sprint is a most challenging activity with very limited time for testing. Agile sprint may not be enough to test each and every combination of tests at times. Quality Engineers need a mechanism to decide which feature to test first, and a Risk-based testing approach is a solution.
In waterfall-based projects, in case of stringent testing timelines, risk-based testing is one of the approaches that is recommended.
Risk-Based Testing Approach
Risk-based testing approach is depicted in the below figure. The approach is defied right from planning to execution and capturing metrics
Business prioritization schema
This represents the schema which defines the weightage of the various identified Risk Factors. Though the Risk Factors identified here are considered exhaustive, additional factors might be added if required. The weightage for the Risk Factor is normally decided in consultation with the Business analyst. Normally for every project, a new set of weightage values are defined.
All weightage values have a range from "Highly Important,” "Important,” "Not so Important," to "Not Required.”
Highly Important: Most important Risk Factor
Not so Important: Least weightage so least important
Not Required: Not required for the project
| Risk | Business Prioritization Schema | Probabilities | ||||
|---|---|---|---|---|---|---|
Risk Factors |
Impact of Failure |
Probability of Failure |
||||
Usage Frequency |
Visible Areas |
Business Crirticality |
Defect Prone Areas |
Changed Areas |
Complexity |
|
Weightage |
Highly Important |
Highly Important |
Important |
Highly Important |
Important |
Highly Important |
The following points explain parameters that will assign weightage to the Risk Factors. However, please note these pointers are only for initiating the discussion with Business Analysts, and these may not be exhaustive.
Impact of Failure:
Maintenance resources to allocate if a fault occurred during production
Legal consequences of not fulfilling government requirements
Consequences of a “bad reputation.”
History transactions
Product is used less frequently
High Sales product
Probability of Failure:
Number of change requests
Sub-functions within a function
Application experience of the designers
Programmer skills
