Friday, September 23, 2016

Risk Analysis (RA) in software Testing | David Tzemach


Risk analysis is the second phase in a “Risk Management” process, in Risk Analysis we will determine the level of risk that involved in different aspects of both the software and the project, The analysis is made on the identified risks that were described in the first step of RM (Risk Identification).

In the Risk Analysis process, we will need to review each identified risk in the software and prioritizing them in a way that the testing teams will test and remove the most critical risks first.

Risk Analysis techniques

  1. Compare the Risk against the requirements and specification of the tested software, and determine how the risk is affecting them.
  2. Consulting with the technical experts that can tell the technical effort that is needed to remove the risk.
  3. Brainstorming with the Key players that involve in the removal of the risks(Testers,Developers, Managers,etc.).

When should you use “Risk Analysis”?

The answer is “Always”, Risk analysis is a continues process, and should be used on a daily basis, but the main key for success is to start performing it early as possible, early start will highlight the potential risk and may provide the potential to handle it when the impact is still tolerated.

What questions should be asked in RA process? 

How this risk impact the project timelines

  • There is enough time to handle the risk (Coding and Testing).
  • Does this risk affect the timelines of other projects?
  • How the Risk will affect the resource allocation(Working H)?
  • In case we decide to remove the risk, what are the consequences on the project timelines?

What are the reasons that created this risk?


  • Unspecified/unclear/Missing user requirements?
  • Wrong technical Design?
  • Technology limitations.
  • Logical error?

How this risk impact the project/software/business etc.?


Business Level: 

  • The risk may impact the company early commitments.
  • The risk may impact the company share price.
  • The risk may impact the company reputation.

Project Level:

  • Additional resource allocation is needed
  • Removing the risk will need an additional testing cycle.

Software Level:

  • Fixing one risk may lead to additional risks.
  • Fixing the risk may reduce the performance in some functionalities.

What’s the potential for occurrence (Probability) that the Risk will occour ?


Potential level
Almost certain that the risk will not happen
Can happen in very specific circumstances
The chances are 50:50(May happen or not)
Will happen on known terms of use
Certain fact
Almost certain to happen

What’s the impact of fixing this risk?

  • is there any Impact on other areas of the application?
  • Additional development?
  • Additional testing?
  • Changes in design?

What’s the ROI of removing this risk?

The company can handle the risk in a way that the removal the risk will be worth the time and effort.

The company cannot handle the risk at the current time, removing the risk doesn’t worth the invested time that will take to remove it.

Prioritization level

After you answered the list of questions, you now have all the information that you need to see the  “Big picture” and decide how to prioritize the Risks based on skillful decision, the basic priority levels are shown in the following table.

Prioritization level
Tolerable Risk
The risk as a minor or no effect on the project objectives, there is a minor chance of occurrence, the level of concern is almost doesn’t exist.
Low potential
Minor effect , low chance of occurrence, should cause minor concern
Med potential
The risk has the possibility to affect the project, there is a good chance of occurrence
High potential
High probability of occurrence , the risk will have a significant effect on the project, the risk should be under control until removal
Very High probability of occurrence, major impact on the project


  1. Hi. I discovered your online journal utilizing msn. This is a to a great degree elegantly composed article. I will make sure to bookmark it and come back to peruse a greater amount of your helpful data. A debt of gratitude is in order for the post. I'll absolutely rebound. agile software testing


My Presentations