Risk management and testing

Risk aversion is the name of the game. That is what we do in QA; we help determine risks and work through some mitigation or treatment.

Throughout a project, there are different views of risk and the ones that get the most important notice is for the overall project itself. What is the chance for the organization or customers? What are the financial impacts? The ROI? There are plenty of risks identified, and decisions made.

Now the project has started, and things move along until, bam, something happens, and a bottleneck or worse, a complete stop occurs, and the project is in danger. It happens a lot. So why? With all the risks assessed at the beginning of a project, things are overlooked or improperly assessed?

From experience, most of these issues occur either just before or during the execution of any testing. The environment is incomplete. Test data not there. Partners not ready to test. These are just a few reasons that I have come across where things go wrong.

Is it something that someone in QA did not foresee? No, we all have identified risks before in any planning. What I feel the issue is that nobody listened until it was too late. I have had a lot of conversations with senior management on why things are the way they are. Those are not fun conversations; it usually ends up that the identified risks did not get recognized or that it was too late to do anything. Often the latter is the case.

So what can we do? The status quo is not going to work. Senior leadership needs to have a better understanding of the entire picture before making decisions. Do they need to see all the details? No, they need to understand that there are some potholes in the path they want to take, and they can figure out how to navigate them. In the Value of QA post, I go into detail how knowledge management can improve everything across an organization and how QA has a clearly defined role in doing so.

QA: Quality Assurance: Trying to avoid issues from happening. There is no reason why risks to testing initiatives should not be identified in a project’s risk assessment. Senior management makes assumptions that testing efforts will be straightforward once development is complete. Then they start getting anxious when it doesn’t. As a discipline, we should be preparing them for those moments.

Now is identifying the risks all that is needed? No, there must be a plan. Well two actually: A mitigation plan and a treatment plan.

Mitigation plans should be relatively easy. What are you going to do to make sure this doesn’t happen? It takes a little forethought and in the end has a good chance of working out.

Where I see things that need work is a treatment plan. I have rarely seen a treatment plan outside of what I do. Blame tends to take precedence over planning. There is no need for that. There is no reason a treatment plan can b the start. What would a treatment plan do? Well first off, it would reduce the noise as to who is to blame and should get right to the solution.

Having a plan A and B is excellent, yet having other scenarios thought of is better. I am not saying think about every possible scenario. There is no time for that. Going with the more probable situations is the best way then having a high-level plan of attack for the improbable scenarios. Just a here are the steps we will follow to get us back on track.

Risk treatment seems to be something that in QA should get more focus. Using that and getting more involved with stakeholders sooner will help overall with avoiding the big potholes, or at least having the material with you to keep things moving forward.