Table of Contents
What is Risk-based Testing?
As the name suggests, Risk-based Testing is a form of software testing that is based on risks. Since the risk is a potentially negative outcome of a functionality, Risk-based Testing covers the one with a higher chance of failure. Risk-based Testing must be defined at the earliest stages possible when customer requirements are defined in order to reduce the potential number of errors in the later stages of development and to guide further planning, implementation, and execution processes.
Of course that we cannot have a project without any risks that may affect the release, deadline, budget, and client’s expectation but the goal of Risk-based Testing is to allow the team to have as much risk coverage as possible at the beginning so that we can have balanced and satisfactory results as an outcome.
What are the Risk-based Testing tasks?
Usually, the test managers are the ones responsible for the project risks. They need to appoint someone who is going to drive all those risk-based ceremonies and meetings through the project lifecycle so that the end goal be satisfied. Different risk-based topics can be considered, such as project architecture, environment set-up, functional and non-functional aspects of testing, etc.
To identify risk, a test engineer needs to divide Risk-based Testing into three different tasks:
- Risk Identification
- Risk Assesment
- Risk mitigation
All the above tasks are used constantly throughout the project lifecycle to allow the team to deal with ad-hoc risks that can change priorities and re-evaluate deadlines.
The first task and the first step of risk handling is the identification part. Here, the team, including all the stakeholders are identifying potential risks. This identification process is conducted in a professional environment where every expert in the field gives his opinion on where in the system a possible risk can be identified. Since all of the members in a risk analysis meeting are experts in their field, they can give some valuable thoughts from different perspectives, hence, discovering risks early.
Stakeholders, developers, testers, business analysts, service technicians, all can participate to determine the impact on the product from a risk.
After the risk is identified, it must be investigated accordingly. And by investigation I mean, analyze and determine the impact and likelihood from the risk. Usually, there is a level of likelihood (probability of the failure to happen). Different testing roles contribute to understanding the product risk and business impact from that problem.
Types of risk that can affect the project as a whole can be divided into:
- Project-related risks
- Product-related risks
Project risks are impacting the overall project success. Some project risk examples can be:
- Not enough QA
- Not enough resources or training
- Missing techonology skills
- Issues in team communication
Product risks affect the total number of errors one system can have. Some of them are:
- High number of complex defects found due to technical characteristics
- Large number of changes in teh code
- Complex code and technology
The final step is the mitigation of the risk. Throughout the project lifecycle, a responsible test engineer will set up a guide on how to mitigate risk. This guide can include:
- Creating test cases with the highest importance and priority that asses the areas witht the highest risk
- Executing the tests against those areas, therefore, mitigate and reduce the risk
- Evaluation based on the test execution and using the results as a knowledge to implement mitigation strategies for future risks and decrease the their likelihood
Having a Risk-bask Testing strategy upfront can be very beneficial not only to the team but to the project overall. There is nothing worse than seeing an impact from a risk later in the development stages where the cost to fix is really high. That’s why implementing a risk strategy in different tasks can uncover very important aspects of the system and can increase the confidence in the team that the product is developing in the right direction.
Check out the Technical Test Analyst guide from ISTQB if you want to find more info!
Share This Post
- How to run a Cucumber scenario multiple times?
- How important is Software Testing Life Cycle? (STLC)
- How to ensure that a Risk-based Testing strategy is implemented correctly?
- Compare the 4 main methods from the Cucumber DataTable class and when to use them
- How to write a simple but elegant Selenium and Cucumber framework for UI automation from scratch?