A better way to Test – 6
In our last blog we discussed, as the last point in our list, testing to risk.
If you have the risks listed, explained, classified, calculated, ordered and entered into a database, it may be easy to attach testcases to them and determine when you have addressed the risk with testing. Not all risks can be efficiently addressed by testing, it is simply one of the possible techniques to be used.
However, people rarely agree on the risks and, as mentioned above, not all risks can be addressed by testing. So this needs to be flexible.
If you don’t have your risk recorded then the testcases may still be built to address perceived risks but they may be difficult to justify. Having both sides of the need (the risk and the testcase) can make each justify the other.
Once we have this for one release of the software, the only question is whether we can continue using the same testcases from release to release. Risks will change, some will disappear or be downgraded, new ones will appear or the ones we missed last time will be included for future releases. Like all project requirements, nothing is ever perfect and we progress (sometimes unevenly) to an end result of coverage that is sufficient for the project. Of course something will always surprise us.
The key consideration is not to become inured to the other methods of addressing risk – testing is not the end solution for everything.
Take a look at some of the seminars that we offer that address this situation and see if they apply to your situation. Testing can be better.
Contact us for further information.
Photo by Samuel Zeller on Unsplash