When it comes to building and launching new software products, businesses need to have confidence that they are fit for purpose and will perform as expected. As we explored in our blog on the importance of software testing, this is why robust quality assurance procedures, software testing and program evaluations need to be carried out. During this testing period, the term ‘risks’ is used to describe the possible problems and challenges that have the potential to slow down or completely derail an organisation from achieving its project objectives.
However, what do risks in software testing actually look like? What determines the level of scale of potential risks? And how does a process of risk management help to mitigate these risks? In this blog post, we answer all of these questions and more as we investigate the field of identifying and managing risks in software testing.
What is risk in software testing?
As touched upon above, risk in the context of software testing encompasses the occurrence of uncertain and/or previously undetected events, problems and challenges with a software program that have the potential to negatively impact the user and their organisation.
When identifying, analysing and forecasting potential risks, determining the level of threat they hold and the possible negative consequences they could bring enables software testers to assess the chances of these risks posing a serious problem before working to mitigate them. As we discuss in more detail below, this process is called risk management in software testing.
When it comes to software testing, all risks fall into one of two categories. These are:
Product risks
These are risks associated with problems, faults and/or system failures that are related specifically to the software program you are testing. Examples of product risks include, the presence of complex features that could impact the product, such as an upgrades or systems migrations, the introduction of new technologies used in the software, such as unfamiliar programming languages or integration features, or general problems relating to system functionality, reliability, usability security, maintainability or performance.
Project risks
These are risks related to problems that can arise during the development and creation of the software rather than the actual product itself. These could be caused by either internal or external factors including delays in development, lack of budget for testing or fixes, and a shortage of staff capable of identifying and/or fixing potential product risks, to name just a few.
What determines the level of risk in software testing?
Once potential risks have been identified in the software testing process, next it is important to determine the level of this risk – this process is called risk analysis and risk-level appointment.
Determining the level of risk usually involves trying to assess not only the likelihood of an identified risk from actually occurring, but also the potential magnitude the consequences this risk could have on an organisation and its stakeholder, should it occur. Both likelihood of occurrence and potential magnitude of impact can be measured through the frequency of occurrence and simulated impact that can be observed under test conditions. As mentioned above, influencing factors when it comes to product and project risks include the presence of complex technology, legacy issues, general programming problems, personnel and training issues among software developers and testers, and unforeseen delays to the project as a whole.
Once risks are identified through testing and analysis, they can then be assigned a ‘level of risk’ based on a set of pre-conceived criteria. For example, ‘High’, ‘Medium’ and ‘Low’ risks may be categorised based on the guidelines set out below:
High
The impact of this risk would be very damaging and potentially non-tolerable. Ultimately, a risk of this scale could see the organisation make a loss should it occur. If a high risk is identified and cannot be solved, the software project may be too big of a risk to complete.
Medium
Problems, challenges or glitches labeled as ‘medium risk’ may be tolerable but are certainly not desirable. These risks may see financial loss in the short-term, however, if a solution can be found, the positives of finishing the software project will outweigh the negative risks.
Low
‘Low’ risks can almost be classed as inconveniences or minor snags rather than actual threats to the project. Little to no financial loss would be seen in the event of one of these risks playing out.
What is risk management in software testing?
To put it simply, risk management in software testing is the term used to describe the entire process of identifying, analysing and ultimately attempting to mitigate the impact of potential risks related to a software development project before they can negatively affect an organisation and its stakeholders.
1. Risk identification
As touched on above, this stage of the risk management process involves identifying both project and product risks. This can be done with the help of techniques such as using specialist risk templates and databases, interviewing a wide range of stakeholders involved in the software development project at all stages of development, and using workshops, retrospectives and focus groups with as many people involved as possible.
2. Risk analysis
As the name suggests, this next stage involves studying the risks identified and, as explained above, assigning each one a level of risk. Once the level of risk has been determined through testing and forecasting analysis, it’s time to move onto the third and final stage.
3. Risk mitigation/contingency
Only once all perceived risks have been identified and analysed can you start to plan for a mitigation of these potential risks. Many risks identified will likely be small, preventable and easy to remove quickly. If a risk has been identified that cannot be easily mitigated, a contingency plan may need to be devised. With this in mind, contingency plans that aim to reduce the consequential impacts of risk on an organisation, its stakeholders and its finances, should it occur, should be put in place during this stage of the risk management process.
