The document discusses risk management in software testing projects. It defines risk management and identifies key risks in testing like lack of tester training. It outlines the stages of risk management - risk assessment and risk control. Risk assessment involves identifying, analyzing and prioritizing risks. Risk control involves mitigating risks through actions, planning for significant risks, monitoring risks, and communicating risks. The project manager is responsible for leading risk management.

1. Poornima Holla

2. What is Risk Management? Risk management means the actions taken to avoid things going wrong on a software development project, things that might negatively impact the scope, quality, timeliness, or cost of a project. Testing is a process designed to minimize software risks.

3. Responsible for Risk management The project manager is usually the most appropriate risk management person because he knows the entire product. In testing, test manager’s responsibility to determine how to apply the test methodology to achieve the greatest level of confidence in the application under development. It is recommended that brainstorming sessions are held at the start of the project with all the members of the project team to identify all the risks.

4. Why to manage risk and what are the benefits? Risk Management enables risks to be identified and mitigated or eliminated before they become problems. Any project is subject to risks. Risk Management will assist projects to become more successful. By completing all the components in the two stages of Risk Management, The management, the project team and the business users may have increased confidence that: The project will be delivered successfully; Surprises will be kept to a minimum; Risks will be effectively managed and mitigated in a timely manner.

5. Benefits: Projects that utilize Risk Management to manage their risks are more likely to receive benefits such as: adherence to user requirements; higher quality deliverables; maintenance of project schedules; prevention of schedule slippage; Reduction of project costs. Acceleration in project completion

6. Risk management in testing Risk analysis is one of the task in the test planning activity. The test manager is responsible for identification of potential risks that might impact testing. The objective of performing risk analysis as part of test planning is to help allocate limited test resources to those software components that pose the greatest risk to the organization. Testing is a process designed to minimize software risks. To make software testing most effective it is important to assure all the high risks associated with the software, will be tested first.

7. Stages of risk Management There are two Stages in the process of Risk Management: Risk Assessment Risk Control

8. Risk Assessment Risk Assessment

9. Risk Assessment Risk Assessment is the first of two stages in Risk Management and includes three main steps as follows: Identify : Review all the project plans and identify areas of uncertainty. Analyze : Define how the identified areas of uncertainty could effect the performance and success of the project in terms of scope, quality, duration and cost. Prioritize: Prioritize the risks in terms of those risks that: must be eliminated (resolved) completely due to their extreme impact to the project; are important enough to demand regular monitoring and reviewing; are deemed to have a minor impact and will not require detailed monitoring; and should not be totally ignored but demand less attention. These steps are to be repeated in an iterative process until all known risks are addressed.

10. What are Project Impacts? All steps of the Risk Assessment are to be addressed in terms of the impact to the project's scope, quality, time or budget. Project Scope can be defined as the identified tasks and activities that need to be performed in order to deliver the required features and functions of a product. Quality can be defined as accepted standard of performance or deliverable that satisfies the expectations. Time can be defined as the either the period of the project or the amount of effort budgeted or assigned to each project task and activity. Budget can be defined as the agreed or contracted amount of the project.

11. Risk Identification Risk Identification consists of determining which risks are likely to affect the project and then defining the characteristics relating to each risk. Risk identification is not a one-time process. It should be performed on a regular basis throughout the course of the project. Identification of risks should be an ongoing question at each project status meeting. Risk identification needs to address both internal and external risks.

12. How to identify the Risks: Risks can be identified by utilizing the following processes: Review known list(s) of project risk factors and sources; Review project plans and schedules; Review chosen technology architecture; Review requirements; Interview project team members; Conduct brainstorm session(s) with project team. It is important to note that "The project will not be completed on time" is not a risk. It is an impact. This risk should be expressed as “Complications in completing the task # 35 may have been overlooked"

13. Some possible project risk areas are: Not appointing an executive member as Project Sponsor; Not appointing a Project Manager to the project; Not clearly and accurately defining the project scope (requirements); Not having a clearly defined technical environment; Not clearly and accurately estimating project tasks and / or costs; Not defining and forming a project team with all the appropriate skills and roles; The proposed technology has less functionality than promised; The length of a project or project phase;

14. Possible risk in Testing Not Enough Training/Lack of Test Competency Us versus Them Mentality Lack of Test Tools Lack of Customer and User Involvement Not Enough Schedule or Budget for Testing Rapid Change Testers are in A Lose-Lose Situation

15. Risks Analysis / Category Before risks can be mitigated, they need to have their degree of severity analyzed. Perform an analysis of the identified risks and categorize them according to the likelihood of their occurrence against their impact to the project. This can be completed by using the four quadrant chart shown below. List each risk and decide on the likelihood of its occurrence and identify its impact on Scope, Quality, Time and/or Budget.

16. The categories from this Analysis described as: HIGH Likelihood and HIGH Impact: These are critical risks that will have a severe impact and are more likely to occur. LOW Likelihood and HIGH Impact: These are significant risks that are not likely to occur but will have a material impact to the project if they do. HIGH Likelihood and LOW Impact: These are significant risks that may be able to be avoided with careful planning and monitoring. Those that do occur however will have a low project impact which is likely to be manageable. LOW Likelihood and LOW Impact: Although these risks should still be monitored to ensure that they do not change category, the amount of time devoted to these should be proportionate with their likelihood and impact.

17. Risks Priority Using the risk categories, prioritize each risk for action in the order that it is to be addressed (1 to 4). Prioritization of risks enables the Project Manager and project team to focus on the areas that are most likely to have the greatest impact to the project.

18. Risk Control Risk Control

19. Risk Control Risk Control is the second stage in Risk Management and includes four main steps as follows: Risk Mitigation: Identify the necessary actions that can be carried out in advance to reduce (or eliminate) the impact of the risk. Risk Planning: Develop an emergency plan for dealing with significant risks. Risk Monitoring: Monitor and track all the risks identified and manage them to successful resolutions. Risk Communication: Formally document and communicate the project risks to the project team and project decision makers.

20. Risk Mitigation Risk identification, analysis and prioritization is only beneficial if actions are defined and executed to mitigate the risk. Risk mitigation actions must be defined individually for each risk. In some cases, immediate action will be necessary. For other risks, future plans and considerations will be more appropriate. Risks can be mitigated not only by eliminating the risk but also by reducing their degree of occurrence and/or lessen the Impact to the project. It can be broken down into two components: Risk Elimination Risk Reduction

21. Risk Elimination: Aggressive, proactive risk mitigation for top priority (1) risks is essential to achieve the full benefits of Risk Management. For these critical risks it is ideal if the risks can be eliminated entirely as they will have the greatest negative impact to the project. Example : Risk: Project Sponsor has not been appointed. Priority:1 , High impact to the success of the project. Mitigation: Appoint an executive member, with available time to devote to the project as Project Sponsor. By carrying out this Risk Elimination mitigating action, the risk is completely removed from the project.

22. Risk Reduction: A reduction of the degree of occurrence, or lessening of the impact, can be attained by actions early in the project. Example : Risk: Lack of training for testers Priority:2 , Low Likelihood and High Impact. Mitigation: training should be provided prior to testing.

23. Risk Planning A plan of action should be prepared for each high priority risk that is not able to be proactively eliminated. An action plan will enable the project to recover from or survive a risk's occurrence (a problem). A plan should be prepared for each risk, identifying: The problem description; The Risk Monitor, who is to be responsible for carrying out the plan and ensuring that the project survives the problem. The key identifiers that will announce the problem as having occurred The activity (ies) to be performed to resolve, reduce and or eliminate the problem; The measurements that will announce the problem as resolved (if known). High priority risks are still likely to remain a High Risk. Even after being addressed once, it may still re-occur at some time in the future (eg: Staff leaving the project).

24. Risk Monitoring Each risk that requires mitigation plan to be prepared should be assigned to a member of the project team to monitor. The Risk Monitor will be responsible to the Project manager for monitoring the risk, reporting any change in condition, taking the agreed contingency action (Plan) if the risk occurs. Monitoring of Project Risks can be achieved by using the following actions: Include risk mitigation tasks in the project schedule; Define appropriate risk milestones; Review risk tasks regularly in project status meetings; Perform inspections on risk status.

25. Risk Communication Project decision makers and project team members are more likely to respond to formally written information than on verbally communicated project concerns. A formally documented process will enable anyone involved or interested in the project to be aware of the project risks. It also assists the Risk Monitor's commitment to the monitoring and mitigation of an individual risk.

26. Example Sl. # Risk Element Risk Mitigation actions 1 Wrong algorithm, too many revisions in the requirement specification documents, and/or document versions not controlled properly. Review requirement specification documents properly by the domain expert, before baseline and maintain the version control. 2 Generation of output taking unusually long time (beyond the time the algorithm is expected to take). For every feature, make a reasonable and realistic estimate of the time needed to generate output. Get the code tested for any possible bugs (redundancies, infinite loops, lack of or inaccurate initialization, etc.).

27. Sl. # Risk Elements Risk Mitigation actions 3 Existing feature(s) becoming inaccessible or getting disabled without apparent reason, on adding a new feature. Check for all possible dependencies with existing features before or while coding. Get the code/product tested at every stage of development (unit, integrated, alpha, beta, etc.). 4 Output format, options, dialog box structure, menu structure, look-and-feel, etc. being inconsistent with existing features. Note the output format, options, dialog box structure, command syntax and usage, menu structure, look-and-feel, etc. of existing features. Adopt a style that is common. 5 Key staff leaving the organization at critical times in the project. Assign more than one person to work on a feature.

28. Sl. # Risk Elements Risk Mitigation actions 1 Tester not having knowledge of product Thorough training need to be given 2 Test cases are not ready Allocate test engineer in the beginning of the project.