Checklist for Projects Risks

 Here is a checklist based on few common issues observed in software testing projects. Note that a Yes response to each question indicates the expected state, a No response indicates a risk.

Using a checklist (like the below one) would enable you to identify open risks in any software testing project quickly.

Personnel Risks
1. Are the required people available for the duration of the project? Are they available at the required project sites?
2. Are the required people committed to the success of the project?
3. Do the available people have the required skill set and required prior experience? If not, can the skill set and experience be first built and then used within the project time frame?
4. Are the people tracked and managed?
5. Is the management committed to this project?
6. Are the down-stream users available for reviews?
7. Is the team communicating within itself and with other groups? Is the team free from unresolved conflicts?

Schedule Risks
8. Are the effort and duration estimates realistic? Are these estimates acceptable?
9. Is the scope frozen?
10. Is the project free from late changes to the test requirements?
11. Is the project free from external delays?
12. Are the schedule activities and deliverables on track?

Budget Risks
13. Is the funding for the project secure?
14. Have the costs of the required project assets remained the same (i.e. not increased or become nonviable)?

Scope Risks
15. Is the scope of test defined and agreed?
16. Are the test requirements frozen?

Quality Risks
17. Are the software requirements well-understood?
18. Is the software test strategy capable of meeting the objectives of the business, the users and the project?
19. Is there a well-understood process for software test?
20. Are reviews by the users (including administrators), clients and management positive?

Technical Risks
21. Have the pre-project activities found to be viable?
22. Are the test automation tools well-understood?
23. Is the test environment available? Is it sufficient for each test requirement?
24. Are the software test deliverables (e.g. test cases, test scripts, test environments, bug reports and test reports) reviewed and accepted?
25. Is the test management system well-understood?

Risk Treatment : Each risk in the risk list is subject to one or more of the following Risk Treatments.

 a. Risk Avoidance: For example, if there is a risk related to a new component, it is possible to postpone this component to a later release. Risk Avoidance is uncommon because it impacts the project objectives e.g.  delivery of new features. 

 b. Risk Transfer: For example, if the risk is insufficient security testing of the system, it may be possible to hire a specialized company to perform the security testing. Risk Transfer takes place when this vendor is held accountable for ample security testing of the system. Risk Transfer increases the project cost.

 c. Risk Mitigation: This is a common risk treatment. The objective of Risk Mitigation is to reduce the Risk Impact or Risk Probability or both. For example, if the testing team is new and does not have prior system  knowledge, a risk mitigation treatment may be to have a knowledgeable team member join the team to train others on-the-fly. Risk Mitigation also increases the project cost.

 d. Risk Acceptance: Any risk not treated by any prior treatments has to be accepted. This happens when there is no viable mitigation available due to reasons such as cost. For example, if the test environment has only  one server, risk acceptance means not building another server. If the existing server crashes, there will be down-time and it will be a real issue in the project.