richrtesting

I am currently in the midst of some work intended to bring discussions about quality into the early stages of planning product change.

It is unfortunate that discussing quality can be something of an afterthought in planning software development and change, often sitting somewhere after costs and financial benefits and sometimes after agreeing on the technical solution.

There is often an expectation that quality will somehow have been ‘assured’ by the time the work is done, but far less often are there meaningful discussions earlier on about exactly what quality means, or how it might be threatened by the development and change which is proposed.

Understanding these threats requires discussion about, and analysis of product risk and one of my tasks is to find ways to prompt those discussions and encourage that analysis.

In doing so, I would like to avoid a problem which I have observed in risk analysis, both in groups (for example risk workshops) and for individuals (for example in preparing ‘Risk’ sections of test plan documents). That problem could be described as risk saturation; an attempt to capture any potential danger, no matter how remote the likelihood of it occurring.

Risk saturation is often characterised by a tendency to capture long lists of project risks. The really useful and important product risks might be included, but if they are, they may be buried under a landslide of vague or unhelpful statements.

I also want to promote a more detailed assessment of where and when the risks might materialise and the potential implications if they do. Not only will this help us to understand which of the risks might matter the most, it could also help in understanding what to test, and how to go about it.

I wanted an uncomplicated mechanism to facilitate focused discussion of risk during short group sessions.

To this end, I created a simple image which can be used as a prompt during our discussions; a set of questions which together help address the central question:

The intention of these questions is not to assist in identification of product risk (I have an idea for this which I will return to in a future blog), but to draw out the most pertinent points regarding risks we have identified; helping us to understand whether each risk is worth further consideration, and if so in what way.

I have deliberately positioned the question regarding who could be affected at the top. As I discussed in my blog on ‘Thinking Quality In’, I believe it is crucial that we are considering, at every stage, the people who will use our products and systems. My intention is that this will be the first question which is addressed, and will frame the conversation.

The question on where a risk might occur is intended to prompt thinking about the systems, subsystems or features which might be affected.

Asking about the potential timing encourages consideration of events and triggers which might be important, and the processes or tasks where there may be repercussions.

Together, I believe that these questions will help achieve my objectives of avoiding risk saturation, and improving evaluation of product risk.