Problem: Risks are cumbersome to identify, and requires grooming before discussion can take place.
Working with risks require that they are well documented and made accessible for the organization to absorb and work with. Grooming the risks takes time, allowing some of the risks to grow into issues, or slip under the radar and avoid getting mitigation tasks in the plans. This means that early identification of risks will make test planning and risk management a lot easier.
Solution: Start with a standard risk list, and build your planning and risk management on that.
In many projects it is the same problems (or variations of same) you will encounter. So you might as well look at the usual suspects. I did that a while back, and concluded that I had to make a standard list to use for input to test plans and risk meetings in the projects I participated in.
Given that test management is my game, the risks focus on test issues and impact on quality, and to make them easily available I divided them into these categories:
Resource related risks:
- Use of undedicated resources
- Poor Productivity in long projects
- Wrong or missing test resources
- Employee Turnover
- Big bang releases
- Overlapping project phases & activities
- Configuration and Change Management
- Risk Management not being done
- There will be a delay in the release of the product
- Gold plating
- Stakeholders and expectations not managed
- Requirements not complete & contain assumptions
- Requirements Inflation
- Specification Breakdown
- Compromising on designs
- Technical risks
- Inter plan dependencies
- Scope is not closed.
- Test foundation not in place
- Test environment & Test data not in place
- Lack of Test Tool usage
Each detailed with the following information: Risks, Event, Possible causes, Effects, Possible measures to facilitate discussion and mitigation.
You can find my standard risk list for projects here.
Note: This is not an invite to stop inventing risks, and run risk management, but it is a fast-track to getting risk management going early in projects. It is an invitation to get the test and QA related risks on of the list and help you write the best test plan ever.
Have a nice day & Happy testing!
*** EDIT: I came across this very comprehensive list of risks in SDL, something that you might find handy: http://www.dtvisiontech.com/2014/11/software-risks-in-software-development.html