Friday, September 23, 2016

Risk Analysis (RA) in software Testing | David Tzemach

Overview

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).
תוצאת תמונה עבור ‪software risk assessment flow‬‏


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


Examples:
  • 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?


Examples:

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


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


Examples:

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 ?


Example:


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


What’s the impact of fixing this risk?


Examples:
  • 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?


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

Negative 
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
Description
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
Unacceptable
Very High probability of occurrence, major impact on the project

2 comments:

  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

    ReplyDelete

My Presentations