Risk-Based Testing?
If you are not familiar with Risk-based testing and the three most important concepts, let me give you a refresher. You are working on a project as a Test Analyst. One of your test analyst’s responsibilities is to assess the quality of the product by creating test cases whether manual or automatic or both, finding issues early in the development and testing lifecycle, and clarifying customer requirements using different techniques, one of which I have explained in my blog: requirements engineering.
I’ll focus on creating the test cases and their priority topic in this blog.
As you know, every functionality developed has its risks which in theory, is a negative outcome of a feature. By negative outcome I mean, a false result that is displayed to the end user. Such outcomes can cause massive issues in different domains like fintech, medical, or insurance domain. That’s why the QA engineer’s job is to also prioritize the test cases by their risk. In other words, execute the ones with a higher chance of failure first.
To do this a QA engineer needs to plan a risk-based testing intro to three different concepts:
- Risk identification
- Risk Assessment
- Risk Mitigation
Usually, the test manager is responsible for driving this approach and setting up the guidelines but the one that applies the concepts is called Test Analyst. Determining the appropriate tests, and implementing and executing them is the primary test analyst’s responsibility.
Test Analyst’s Responsibilities in all three concepts
Risk Identification
Here the test analyst can call all the important stakeholders to try to determine the largest number of possible risks. One of the crucial preconditions for doing that is that the test analyst should possess a high degree of business domain knowledge to do the following:
- Using his past expert knowledge and applying it in the current workplace and project
- Conducting interviews with domain experts to gather more info
- Assess the risk by their experience
- Use risk templates
Typically the end users and other domain experts should be the go-to guys for the test analysts with the one purpose of determining areas of highest possible risk. One of the benefits of Agile software development is that this phase is performed very often, every 2 weeks when a Sprint Planning meeting occurs, and all of the team members as well as outside stakeholders can participate and discuss potential risks among other topics.
Risk Assessment
In this phase, the risks found in the first phase are assessed. By assessing I mean, categorizing them and their risk level. The assessment part is usually done by interpreting the likelihood of the problem happening and the level of impact. The test analyst’s responsibilities here are to determine the potential business impact of the problem if it occurs as well as assess the user impact for each risk.
Some of the risks affecting the business determined by the test analyst can be:
- Business loss
- Frequency of feature use
- Fines, loss of licenses
- Customer loss
- Legal sanctions
Risk Mitigation
In the last phase, the test analyst’s responsibilities involve creating test cases to determine if they pass or fail, participating in formal or informal reviews whether that is a requirement review, test case review, or even a test automation code review sessions, implementing according test mitigation activities to handle the risks, re-evaluate knows risks and identify new risks from information gathered during testing.
This way the test analyst will make sure that the quality is on point and that the product risk is therefore mitigated effectively.With every single bug found the risks are reduced because of the raised awareness. If the testers don’t find any bugs then some form of test evidence needs to be reported to show that the system works as it should under specified circumstances.
Conclusion
The test analyst’s responsibilities are not a one-time event as far as handling risk goes. It is a continuous process whether it is a newly planned test cycle in the traditional development approaches or a new sprint in an agile-oriented team. Some important questions should be taken into consideration when a new risk analysis is being performed:
- Has the product changed and introduced a potential risk?
- Are there any new areas discovered that are failure-prone?
- Does fixing a defect create a potential for a new risk to arise?
