Agile Risk-based Software Testing

Risk can be a part of life and it is a component of a software project too. Anything can fail at any time.

As Murphy’s law states — “Things will go wrong in any given situation if you give them a chance”.

But if you’re prepared and you recognize what it takes to overcome those challenges, then it’s not a risk or the severity of it is mitigated. Risk management prepares us to foresee the probabilities of several risks, have mitigation plans in place, and effectively forestall.

What are the risks associated with software?

Risk is the potential loss or damage which may endanger the objectives of or the deliverables promised to the project stakeholders. Test Management consists of a series of activities. Risk Analysis should be one of the first activities that a Test Manager should include when he decides to plan the testing activities. Risks need to be prioritized before the start of the testing phases. Early risk detection will help QA to avoid potential losses in the future. Modules with higher risk need to be tested prior. Software risk analysis looks at code violations that present a threat to the protection, performance, or stability of the code among many other things.

What is the need for Risk Analysis?

Risk Analysis has made the professional experience of testers simpler and more remunerative. Once you get to know the risk areas, it becomes easier to formulate plans and curb them successfully. It is not possible for the QA team to do a complete risk analysis during the actual testing process or at the time of delivery. It’s always better to perceive what can really fail in the application before it goes into production. Implementing risk analysis in software testing consistently requires an accelerated evaluation of the source code to spot how it collaborates with other integrated components of the application. When a test plan has been created, risks involved in testing the product are to be taken into consideration together with the chance of the damage they will cause to your software.

The terms risk and uncertainty are often used one in the place of the other even if they are not the same. Risk is something quantifiable while uncertainty is not measurable and the probabilities of the possible outcomes are not known. The software functionaries are prioritized by outward-looking risk analysis where the software engineers, together with the risk analyst, assign values to metrics like size, complexity, quality, cost, and others in order to find the Risk Exposure value for each functionality.

Here we list the possible risks that are most commonly encountered in software projects:

• New Hardware
• New Technology
• New Automation Tool
• The sequence of code delivery
• Availability of application test resources

Software Testing activity is planned to improve the quality of software products by analyzing the amenability of software products with its blueprint specification. Now, let us look at certain risks that are unavoidable. They are listed below:

• Change in requirements or incomplete requirements
• Time allocation for testing
• Delayed code deployments
• Urgency from a client for delivery
• Defect Leakage due to the application size or complexity

Risk Categories

• Schedule Risks

Schedule risk is the software testing risk related to the schedule plan and resource allocation of the project. When determining overall project risk, the Project Manager must assess the risk associated with the schedule. Schedule Risks are of high priority as it can cause a massive loss to the company or even shut down the project. The project time schedule must be estimated based on the number of resources allocated to the project.

• Budget Risk

All software development companies always need to pull in money after accounting for all expenses as they cannot survive without this profit money. Budget risk is the software testing risk associated with the profit levels of an organization. Expansion of project scope, underutilization of resources, incorrect project budget plan, and wrong financial tracking of the project can lead to additional charges.

• Operational Risks

This software testing risk is also known as Procedural risk. It is associated with procedures, systems, or policies of software development and maintenance. Faulty implementation of process plans, lack of team coordination, absence of harmony within the team, and miscommunications are categorized under Operational Risk.

• Functional risks

These are the software testing risks that are also termed as Technical risk or performance risks and are related to the performance and functional abilities of the software. Lack of team performance, insufficient technical knowledge, budget anomaly, and lack of quality in work contribute to functional risk.

• Programmatic Risks

Programmatic risks are the software testing risks arising from external factors beyond the operational limits. These risks are unavoidable as they cannot be anticipated with surety in advance. Change in government policy, Economic meltdown of the firm, Pandemic resulting in economic loss all comes under Programmatic risks.

What are the risk magnitude indicators?

The Risk Magnitude is just the sum of the severity magnitude and the likelihood magnitude values for the occurrence of a risk.

Low Impact, Low Probability

Risks that can be briefed as both low impact and low likelihood of occurrence are substantially imperceptible and can usually be eliminated from active deliberation. The project manager needs to monitor these factors amply to determine that the impact or likelihood does not increase.

High Impact, High Probability

Risks that are traced as both high impact and high likelihood, often cause a project to be discontinued or to fail if it is continued despite these risks. Risk management does not mean that no risks would occur during the course of the project. What it does is for the team to have plans in place to accommodate and successfully terminate or manage risks as far as possible, if it occurs.

Low Impact, High Probability

Low-impact, high-probability risks are those mainly due to ambiguities about a number of components that may be independent of minor risks but when accumulated could amount to a significant risk. Each of these uncertainties, taken alone, would have little impact on the project. However, taken together, there is the possibility that many of the estimates of these factors would prove to be considered detrimental to the project.

High Impact, Low Probability

High-impact, low-probability events are of limited occurrences, and therefore it is very difficult to assign probabilities to them based on historical records. Data do not exist for this risk category and so subjective estimates of probabilities are necessary. However, the goal is not the technical determination of the accurate probability of unusual events but the determination of what management actions should be taken to monitor, manage, and mitigate such risks.

The perspective of Risk Assessment

Risk assessment is the process of identifying and subsequently analyzing the identified risk to determine its level, typically by assigning likelihood and impact ratings. Risk assessment itself has multiple aspects and hence it is important to segment further the factors influencing risks, the risk estimation technique used to estimate and evaluate the risk, the scale type that is used to determine the risk exposure of the project, and also the degree of automation for risk assessment.

There are three perspectives of Risk Assessment:

Effect — To assess risk by Effect. In case you identify a state, chance, or action and try to determine its impact.

Cause — Find out the root cause of the risk. Initialize scanning the problem and reach to the purpose that would be the foremost probable reason behind that.

Likelihood — To assess risk by Likelihood is to mention that there is a probability that a client requirement might not be satisfied.

Risk Mitigation or Acceptance, which is better?

This places Risk-Based Testing as being the most suitable testing process for projects following Agile. It targets to provide the test results in the lowest possible time. Creating a list of risks is a good starting point, but it isn’t enough in itself. Teams need to come up with an action plan per risk, which helps to manage them effectively. QA team needs to carry out tests and make the most vital changes in a time-bound manner.

Mitigation and contingency are crucial for managing the risks in any circumstance. Mitigation is the step taken to limit the impact and imperfections caused by an unfavorable occurrence. Contingencies are alternate steps prepared if a prepared plan does not work. Contingency planning is an important step to lessen a software testing risk. There need to be different contingency plans to keep your product secure and endure through the risks if and when they occur.

Risks that involve a high probability impact for both financial loss and damage, should be ideally avoided. Risks that may have a lesser probability of taking place but would have a hefty financial impact should be mitigated by being shared or transferred, e.g. by purchasing insurance, forming a partnership, or outsourcing. With some risks, the outlay involved in mitigating the risk is more than the cost of tolerating the risk. In this situation, the risks should be endorsed and attentively monitored. The foremost common mitigation strategy is risk limitation, i.e. businesses take some sort of action to deal with perceived risk and regulate their exposure. Risk limitation usually employs a few risk acceptance methods and certain risk avoidance measures.

Measures to control the project risks

It’s always better to find a way to limit the risk occurrence than to accept, mitigate, or completely overcome it after it has occurred. For this to be the norm, it is recommended to initiate risk management in the planning phase of the project. Risk Assessment review meeting must be conducted along with the development team. Profile for Risk coverage is formed by mentioning the importance of each and every area. Allocate more testers to work on High-risk modules. A risk assessment database must be created; this helps in future maintenance activities and management reviews. Risk magnitude indicators must be provided for the identified risks; as testing must be proceeded with based on the magnitudes assigned. All modern companies use brainstorming sessions to facilitate the free flow of information.

Experiences are our greatest asset as it provides us with a wealth of information and valuable lessons helping to prevent the same mistake from being incurred in the future. Continuous improvement, proper planning, adhering to process and learning from past mistakes is imperative to become more adept in limiting and dealing with risks and to deliver a successful product to the clients and end-users.

Author: Aswathy Ramachandran
Stream: QA