Task 3-Manual Testing: Explain different Risk Factors that should included in /test plan.

Q3.

The Test Plan (sometimes also referred to as a QA Test Plan) can be seen as the instruction manual or guide for your testing effort. It describes the objectives of testing (what are you planning to verify and/or validate), the scope of testing (what will and will not be tested), together with the general and sometimes detailed schedule of the activities you want to perform (how and when are you testing).

Test plans should list the risks foreseen in the project and their respective levels so that testing can be prioritized by risk.

Perhaps the most important part of a test plan is the definition of resources needed. Resources can be seen as human (such as the people involved in the test) and technical (such as test environments, test tools, and test data).

Risk Analysis Requirements

There are a few requirements that need to be met before your risk analysis can be successful. We list some of them for your reference:

• Risk Identification: A thorough examination of the project to identify all possible risks, including technical, operational, and business-related risks.

• Risk Assessment Metrics: A standardized method for evaluating the likelihood and potential impact of each risk.

• Risk Prioritization Criteria: A defined set of criteria for prioritizing risks based on their severity, likelihood, and potential consequences.

• Risk Mitigation Strategies: Clear strategies for mitigating or reducing the impact of identified risks.

• Risk Monitoring Procedures: A system for continuous monitoring and tracking of identified risks throughout the project’s lifecycle.

• Risk-Driven Testing Strategies: Incorporation of risk-based testing into the test strategy to focus testing efforts on the highest-priority risks.

Defining and Determining Risk in Software Testing

Risk in testing is the occurrence of unexpected events that impact the software application's success and quality. Such events might have happened in the past or may be an issue for future occurrences. This may affect the cost, technicality, and quality of the standard of the software application.

The risk may include errors, issues, vulnerabilities, and defects that negatively impact the software application's functionality. The main purpose of risk assessment is to find and evaluate such risks and determine their level for prioritization of testing efforts.

Types of Software Risk

While several scenarios exist to give rise to risk occurrences, they fall into varying categories as per what they affect. Software risks can manifest in various forms, and understanding these types of risks is crucial for effective risk management in software development.

Technical Risks

As per its name, technical risks consist of complex and often uncertain defects in design, functionality, system performance, and data. It encompasses all the technical aspects of a project, from challenges arising from software complexity and new or unproven technologies to integration difficulties, performance bottlenecks, and security vulnerabilities.

Schedule and Resource Risks

It includes risks associated with project scheduling and resource allocation, including constraints on resources (such as hardware and human resources), changes in project scope, tight deadlines, and dependencies on third-party components or services.

Operational Risks

Any risk arising from operational aspects of a project, including potential operational failures (e.g., lack of disaster recovery plans), differences between testing and production environments, and geographical factors affecting data centers, come under this type.

Business Risks

Business risks are risks arising from changes in market conditions, economic factors affecting budget or funding, and competitive forces influencing the project’s success.

Organizational Risks

These are the risks related to changes in project or team leadership and team dynamics, including conflicts and communication issues.

External Risks

It consists of risks associated with external factors, including third-party risks linked to vendors or services outside the project team’s direct control.

Levels of Risk

When you think of levels of risk, the low, moderate, and high terms come to mind. However, in the real software testing scenario, the risk level is determined by two dimensions: probability and impact.

Probability: It measures the likelihood of an event occurring, typically expressed as a percentage or qualitative scale. It answers the question: “How likely is it to happen?” It ranges from 0 to 100%. The probability can never be 0% because it indicates that there is no risk, and it can never be 100% as it indicates that it is no longer a risk but a certainty.

Impact: Risk, by default, brings a negative impact to any project. It assesses the consequences or severity of an event, usually quantified in monetary, temporal, or qualitative terms. It answers the question: “What would be the extent of its effect?”

By taking into account these two factors, you can calculate the level of the risk:

Level of Risk in Software = Probability of Risk Occurring X Impact of the occurred risk

Thereafter, based on the final result, the risks are classified as low, moderate, and high. Let’s look at an example. Suppose a critical module of software relies on a third-party library known for occasional security vulnerabilities. Below is the assessment:

Risk Assessment:

Probability: You estimate a 20% probability of a security breach happening due to past incidents with the library.

Impact: A security breach could result in data exposure and significant financial losses, potentially leading to a project delay.

Risk Level Calculation:

Probability (20%) x Impact (High) = Risk Level (High)

In this case, the calculated risk level is “High,” indicating that this risk warrants immediate attention and robust mitigation strategies, such as thorough security testing, monitoring for library updates, and considering alternative libraries.

How to Perform Risk Analysis in Software Testing?

Risk analysis is a highly critical aspect that causes any software to lose its quality and credibility if not done right. Developers and testers often analyze the source code and the corresponding front-end features to understand the interactions between different components. All this review results in identifying risks and figuring out the mitigation process.

Risk analysis is a 3-step process:

Identify the Risks

First, you need to identify the risk, which comes in several forms. The main two classifications are project risk and product risk.

Project risks are associated with uncertain scenarios that can impact the project’s progress. Product risks refer to the possibility that the system might fulfill certain customer expectations or might fail to work as intended. Understanding these risk types and classifying the identified risks accordingly will help you to move toward the right solution. For more context, focus on segmenting risks as per their type, which we have discussed above.

One example of this could be that the Simply Travel site lacks sufficient security functions. This risk would be a product and technical risk.

Analyze the Impact of the Risk

A risk’s impact is determined as per how much damage it could do to the system. A security risk is certainly a huge red flag. Yet, we need to analyze the impact by calculating the levels of the risks. For this, we need probability and impact value. Both these parameters range within High, Medium, and Low values. The security risk discussed in the above example would be awarded a High value for probability and impact, making it an immediate threat to the system. Based on this classification, you would need to look for a solution urgently. Let’s look at a few more possible risks and classify them accordingly for a broader understanding:

Formulate and Implement Risk Mitigation Measures

Risk mitigation comes in varying forms as per the identified risks and the decision of the people involved. Project managers ideate and formulate strategies to resolve the risks. They can go with a range of options, including avoiding the risks, looking for a solution, transferring the risks to other resources, or planning to contain it with sufficient resources/budget. In parallel, proper documentation and monitoring of the risk is necessary to keep it within control.

Now that you have a practical idea about risk analysis let’s see how Test sigma helps you do that. Suppose you are checking the UI of this site. Upon adding the necessary inputs, such as Origin, Destination, and Date of Departure, as per the expectation, a list of all the available flights must be displayed.

Best Practices for Software Risk Analysis

Performing effective risk analysis in software testing is crucial for identifying and mitigating potential issues. Here are nine best practices to follow:

• Start risk analysis during project initiation. Identify and document potential risks and uncertainties as early as possible.

• Consider technical, operational, and business-related risks. Ensure you have a holistic view of potential issues.

• Categorize risks by type (technical, schedule, operational, etc.) to facilitate better risk management and prioritization.

• Conduct regular risk reviews at various project stages, including planning, execution, and closure.

• Develop clear and actionable mitigation plans for high-risk items.

• Define criteria for assessing and categorizing risks, including probability, impact, and risk levels (low, medium, high).

  Risk analysis involves identifying, assessing, and managing potential risks that could impact testing projects. A risk matrix is a visual tool that prioritizes risks based on their likelihood and impact. It simplifies risk communication, aiding in decision-making by highlighting high-priority risks that require immediate attention and mitigation.
  Risk management is a multifactorial concept that requires attention and effort. Especially when it comes to testing software, there will be risks even in such an optimal process as automated testing. Thus, risks in software testing can lead to serious financial costs, a downfall of reputation, and unhappy customers. Therefore, proper management is one of the key conditions for avoiding them.

  What determines effective risk management in software testing? In general, it is based on:

  • Planning.

  • Suitable documentation.

  • Correct team building and training.

  • Arrangement of priorities and parameters.

  • Monitoring.

  • Analysis.