Skip to main content

Risk Assessment

  • Risk Assessment is a crucial part of Risk-Based Testing (RBT), focusing on determining the potential risks associated with different parts of a software system. It involves evaluating each identified risk in terms of its likelihood of occurrence and the impact it would have if it occurred. The outcome of risk assessment helps in prioritizing testing efforts and directing resources toward high-risk areas.

Components of Risk Assessment​

Likelihood of Occurrence​

  • This refers to the probability that a defect will occur in a particular part of the system. Likelihood can depend on various factors, such as:
  • Complex code or system architecture is more prone to defects.

Impact of Failure​

  • Impact is the severity of consequences if the identified risk materializes. The impact assessment focuses on what could go wrong and the effect it could have on the system or business. High-impact risks usually involve:
  • Failure in key functionality could result in significant business losses. ie: Payment systems and user authentication.

Risk Exposure​

  • Risk exposure is calculated by combining the likelihood and impact of the risk.

    • A commonly used formula is: Risk Exposure = Likelihood × Impact

  • This helps prioritize risks into categories like high, medium, or low, guiding testing efforts accordingly.

Risk Assessment Process​

Risk Identification​

  • This is the process of identifying potential risks that could negatively impact the project, product, or testing process. Risks can be technical (software failures), operational (incomplete requirements), or external (market changes).

  • As a first step, potential risks are identified through brainstorming sessions, analysis of previous defects, feedback from stakeholders, and by considering system complexities.

Key considerations during this phase

  • Sources of risk: These can include software complexity, new or unproven technologies, integration with third-party systems, or known bugs.

  • Types of risks: Functionality, performance, security, usability, etc.

  • Stakeholders’ input: Involving business analysts, developers, testers, and end-users to identify risks from different perspectives.

Risk Rating and Prioritization​

  • Each risk is rated based on two factors:

    • Likelihood: Assign a rating based on the probability of the risk occurring. ie: From 1 to 5.

    • Impact: Assign a rating depending on the severity of the consequences. ie: From 1 to 5.

  • Risks are typically classified into categories like low, medium, and high severity based on the combination of likelihood and impact.

  • After assigning these ratings, you calculate the Risk Priority Number (RPN), which is the product of likelihood and impact scores.

    • Example:

      • Likelihood = 4 (High)

      • Impact = 5 (Critical)

      • Risk Priority = 4 × 5 = 20 (High priority for testing)

Categorizing Risks​

  • Once risks have been analyzed, they are ranked to determine where testing efforts should be concentrated. The priorities are based on a combination of likelihood and impact.

  • Risks are categorized based on their RPN into different priority levels:

    • High Risk (RPN 16 - 25): These are critical areas that require immediate attention and extensive testing.

    • Medium Risk (RPN 9 - 15): Moderate risk areas that need focused testing but may not be as urgent as high-risk components.

    • Low Risk (RPN < 9): These areas require less focus and can be tested with minimal resources.

  • Risks are can be categorized based on the following types:

    • Business risks: Loss of revenue due to system failure.

    • Technical risks: Software bugs, performance issues.

    • Project risks: Delays, team skill limitations.

    • Product risks: Critical features malfunction.

  • Key considerations

    • Allocate resources and time to testing high-priority risks first.

    • Ensure business-critical functionalities are thoroughly tested, even if the likelihood of failure is low.

Tools / Techniques for Analysis​

  • Failure Mode and Effects Analysis (FMEA): Used to evaluate and prioritize risks based on their potential failure modes.

  • Risk Matrix: A grid used to plot the likelihood and impact of each risk to visualize and categorize them.

Continuous Risk Monitoring​

  • Risks are not static. As development progresses, new risks can emerge, and existing risks can evolve. Regularly reviewing and updating the risk assessment ensures that testing efforts remain aligned with current project realities.

Risk Assessment Example

  • Imagine a full stack web application with both frontend (React) and backend (Node.js) components. Suppose a critical feature is the payment gateway, which integrates with third-party services. Through risk assessment, the following risks are identified:

Payment Integration Failure

  • 4 (due to complex API integration)

UI Button Misalignment

  • 3 (occurs due to frequent UI updates)

Login Feature with OAuth Integration

  • 4 (OAuth integration with multiple providers is tricky)
  • In this case, the payment gateway and login feature are considered high-risk, while the UI button alignment is low-risk. Therefore, testing will focus first on payment integration and login functionality before dedicating resources to less critical areas.

Benefits of Risk Assessment​

  • Prioritized Testing: By focusing on high-risk areas, testing teams ensure that the most important and vulnerable parts of the system are stabilized first.

  • Efficient Resource Use: Resources such as time, budget, and personnel are optimally allocated to the areas where they are needed most.

  • Informed Decision-Making: Stakeholders can make data-driven decisions about the project based on the risk profile, allowing them to balance risk against business priorities.

  • Proactive Risk Management: Identifying risks early and adjusting testing priorities helps reduce the likelihood of encountering critical defects late in the development lifecycle.

  • Improved Product Quality: By addressing high-risk areas, the overall quality of the software improves, particularly in components that have the highest potential for failure.

Risk Mitigation Planning​

  • This phase involves defining strategies to address the identified risks, either by reducing their likelihood or minimizing their impact. Risk mitigation can involve:

    • Preventive measures: Actions to avoid the risk altogether, such as improving code quality or refining requirements.

    • Contingency planning: Having backup plans ready in case the risk materializes. ie: Alternate Test Environments or Fall-back Features.

    • Test planning: Creating detailed test plans for high-risk areas. Testing types could include performance testing, security testing, or stress testing, depending on the nature of the risk.

    • Monitoring and control: Continuously assessing the risk as the project progresses and adjusting the testing strategy accordingly.

    • Mitigation strategies include:

      • Assigning additional resources to high-risk areas.

      • Running more in-depth testing on high-priority risks. ie: Regression Testing and Exploratory Testing.

      • Implementing automated testing for repetitive and critical test cases to reduce human error.

Module Review​

Click to start the definition to term matching quiz
Drag the defintion to the correct term.
Test type item not available at this time.
Click to start the multiple choice quiz
Choose from the listed options below.
Test type item not available at this time.