Thursday, 7 October 2010

Product Risk Management

I'm just updating content for a training course, and I know I spend a lot of time conveying the importance of testing etc etc, but to do so in the most succinct and digestible way, to ensure the thought or lesson objective is retained.

I'm currently trying to communicate the importance of risk-based test strategies, and one of the biggest concepts ofr me is that "The main purpose of testing is to mitigate risk, therefore our testing strategy should be focused on risk mitigation, rather than purely requirements conformance".

The basis for this is my perception that the majority of testing is founded upon the idea that the requirements as defined are to be treated as 'gospel' and therefore deviation from the requirements alone is all that is required to ensure successful delivery.

In actual fact, it is the tacit knowledge; the undocumented requirements that are seemingly obvious to end users and seemingly invisible to others, that should be captured and assessed. Such things as performance, useability, security, compatibility, in fact all the other abilities, should be factored in.

So, my question, is if testing is about finding defects against system, is there a more elegant and or accurate way to describe a test strategy as the artefact that documents the focus of testing as identifying the most critical defects which would expose the system to the biggest risks.


No comments:

Post a Comment