Thursday, July 24, 2014

4 Steps to Risk-Based Software Testing

Risk-based testing is the approach that allows us to plan our testing efforts in a way that reduces the residual level of product risk when the system is deployed. A risk-based approach helps you to understand the risks at the initial stage so that the mitigation strategy will be scheduled and implemented. Test effectiveness indicates the level of effort that is required in order to mitigate the risk of implementing a change. The higher the test effectiveness required, the more rigorous the test and evaluation activities should be. The following factors are used in determining the required test effectiveness:
  1. Impact
  2. Probability of Failure
  3. Regression
  4. Recovery
1. Determine Impact by Analyzing: (1. Min, 2. Low, 3. Medium, 4. High, 5. Severe)
Impact refers to the potential damage that the business might suffer if the intended functionality is not delivered. When assessing impact, the chances of the change negatively affecting other functions/features are not considered as that is captured under a separate attribute (Regression). The higher the impact, the more rigorous the tests should be. For example, if a simple report is being implemented and is used by only few users, then the potential damage would be minimal and therefore the impact assessment should result in a rating of ""min"".

The following checkpoints should be considered when assigning a rating for the impact factor:

  • A. Is the solution component a primary function/feature of the solution (i.e. must have vs. Nice to have)?
  • B. Is the solution component independent or other business processes dependent on it?
  • C. Does the data pertaining to transactional volume, financial and other operational considerations indicates significant utility?
  • D. Is the Solution component used by important stakeholders (Large customers, Regulatory etc.)
  • E.Is the impact to external stakeholders or Internal?
  • F.Is the impact to a single business unit vs. multiple business unit?
  • G. Number of stakeholders/users that might be impacted?
  • H. Impacts based on implementation and roll out strategy. For example, some process may not be executed immediately after implementation
  • I. How frequently is the solution component used?
  • J. Real time vs. Batch (Real time generally leads to immediate impacts and therefore more risky)

2. Determine probability of failure by analyzing: (1. Min, 2. Low, 3. Medium, 4. High, 5. Severe)
Probability of failure is an assessment of overall risk-based on various consideration like the complexity of the solution, ambiguity in requirements, complex logic etc. The following checkpoints should be considered when assigning a rating for complexity:
  • A. Technologies used (New technologies lead to higher risk)
  • B. Level of Customization (Higher customization leads to higher complexity)
  • C. Complex logic and business rules
  • D. Real time vs batch. Real time typically would be more risky as impacts are immediate
  • E. Higher defect density as perceived from prior testing engagements
  • F. Development effort (The larger the development, the more potential for failure) 
  • G. Ambiguity in requirements
  • H. Complexity of solution
  • I. Rushed schedule
  • J. Dependency on integration with external systems/partners

3. Determine Regression Impact (1. Min, 2. Low, 3. Medium, 4. High, 5. Severe)
Regression impact is the impact to the existing business processes and functions and is weighted very heavily in terms of the overall determination of the test effectiveness required. This is also the most important focus of the service validation and test group.
  • A. Changes to high risk areas
  • B. Changes to highly integrated areas (same code is shared by multiple business units/processes etc)
  • C. Lack of clear definition of the scope of changes (like support packs without clear release notes etc)
  • D. Scope of regression based on the change

4. Determine Recovery Effort/Difficulty from Potential Failure (1. Min, 2. Low, 3. Medium, 4. High, 5. Severe)
When determining the test effectiveness required to mitigate the risk of the change, the ability to recover from a potential failure needs to be considered. Even if a failure occurs, if recovery is possible quickly, then the risk is mitigated to an extent. However, if recovery is very difficult then the test effectiveness needs to be high if the solution component is critical to operations.
  • A. Existence of work around if potential failure occurs
  • B. Existence of back out procedure and ease of performing back outs
  • C. Ability and turnaround time to fix problems in case of failure
  • D. Is the failure reflected real time or is it more batch oriented
  • E. Existence of alerts or early warning indicators to aid proactive intervention

Risk Based Testing – An Example:


Prolifics specializes in providing end-to-end testing and test automation solutions that are backed by a unique service framework, proven test accelerators and one of the highest defect removal efficiency rate in the industry. Our highly skilled team of testing specialists help to enhance IT productivity and improve application quality, saving millions of dollars through early detection and scope coverage.

To learn more, visit http://www.prolifics.com/quality-assurance-testing.

Jagan Erra is a Delivery Manager in the Testing Practice at Prolifics. With over 15 years of experience, Jagan has a proven ability to identify, analyze and solve problems to increase customer satisfaction and control costs through expertise in program development and management, IT quality processes, models - ITIL, ISO, client training and cross-functional team leadership.