Carnegie Quality

I recently posted a template for a risk management plan. The plan discusses, among other things, how to identify risk. I thought I would spend some space talking about identifying risk from a testing perspective.

But first let me ask a question about why we do risk identification. Is it possible to release a defect-free product? I suppose it depends on your point of view, but speaking practically, the answer is no. In the real-world we have constraints - limited testers, limited schedule, not enough tools, etc… So it is with this realization - no software can be perfect - that risk identification becomes so critical.

Identifying risks on a project lets us answer the question “where do I spend my limited test resources?” I’d like to suggest the following as sources to use when finding risk potentials.

Previous Defect Reports

If you are on a project that has an associated history (e.g. a previous phase), then perhaps the best place to look is the defect history. Which components had the largest number of defects? Which developers had the biggest share of defects? Is there a previous history of defect fixes causing related new defects (if so, then heavy regression testing is called for)?

Extended Team Members

Talk with the team and get their input. Ask the developers (not just the lead) and get their perspective. Talk with the requirements team, with the PM, with the stakeholders. What are their areas of concern?

Change Requests

Change requests are another good source, particularly ones that occur later in the development process.

Project Assumptions

Project assumptions are a great source for not only identifying risks, but also for designing test scripts. What happens when an assumption doesn’t hold true? Does the application handle it gracefully, or just fail?

Status Reports

Do the status reports reveal certain areas of the application that design or development has had issues with?

Requirements

Requirements volatility is a measure of how frequently requirements change over time. Sometimes, this reflects poorly stated requirements that should probably demand more attention during testing (of course, changes could also be the result of stakeholders not knowing what they want). If your team is using a requirements management tool, then getting a report on volatility is fairly straightforward. Even if you don’t have a tool, talk with the requirements engineers and get their input.

Audits

If you are part of an organization that has regular process audits, then their findings are often valuable.

Lessons Learned

Last, but certainly not least, are lessons learned from previous testing efforts. Best practices calls for these to be collected and documented after each project. If you are not doing this (you should be), you can still talk with people to get historical input.

This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 License.