Risk Management Tools

A risk is a finding and a finding is a risk. A finding can become a risk and a risk can become a finding. Risks are defined as probability or threat of a damage, injury, liability, loss, or other negative occurrence, caused by external or internal vulnerabilities, and which may be neutralized through pre-mediated action. You could say that risks are the Weaknesses and Threats of the SWOT analysis.

So when a risk is recognized this should lead to an action. Measures are taken to avoid, reduce, accept or transfer the risks. The severity of the risk and possible consequences is quantified by “high”, “medium” and “low”. Low could mean that it is not a big risk or there could be a serious risk but it can easily be resolved. Risks can be product related, process related and project related. A project risk could lead to a product risk and vice versa. When the risk is project related it can be development related or testing related.

What we often see is that the project manager and the test manager are both doing risk analysis, independent from each other. They both do this at an early stage of the project. During the project more risks become clear and should be defined, others disappear or are resolved.

Risk analysis and risk management would be done more efficiently if all parties involved would keep these risks together in one project risk database. Of course the configuration should be adjusted to the needs of the project. We could put in columns for severity, priority, project/product/process, requirements/risks/findings etc.

Similar principles we find in findings management. Findings are problems or questions or doubts related to the functioning of the product that is being tested. A finding can be a serious bug but it can also be that the tester misunderstood the functionality or that there is a configuration problem. Anyway, the issue is reported and action will be taken. The matter will be examined and the problem will be resolved. That’s the idea. This idea is pretty much the same as for risk management.

Findings can be reported in every stage of the development project. They are not only reported in the test execution phase but also in the test specification phase, which the test analyst will review when he/she starts defining test cases. Or during the realization phase, the coding.

Most findings registration tools can do what we want: manage both risks and findings. They could even be used to manage the actions from project meetings. So for this purpose a good risks & findings management tool would be enough. A good reason to use the same tool for risk management and findings management is that you keep all the project related issues together. In an issue report or finding you can easily make references to other issues.

A lot of these tools do more than just manage findings. MQC (which recently lost the M because Mercury was taken over by HP) for instance has the possibility to manage requirements (which would only work if you define them directly in MQC, otherwise it is a lot of extra work), create manual and automated script plus the findings management. The findings can be related to the requirements and scripts. QC is a popular tool, although it may do more than you need. Other big names in the tooling world are IBM and Compuware, but there are many more. See for more information on testing tools.

There are a lot of risk management tools around. Risks has become a very popular topic since ISO9001 and especially since SOX. Let's not forget the most important message of ISO9001, SOX and others: you have to prove what you did. That's it. It is not more complicated than that. That means saving everything (inputs and outputs), adding screen shots to findings etcetera. Traceability.

For more info see www.q-course.com and the Q-Course book.