I’ve been having some thoughts about how we could measure the effectiveness of an agile test process.

One of the measures I think could work is ‘Time to defect’ (TTD). That is the time between a coder injecting a bug into the system and the time the official defect reporting the problem arrives back on their desk. The lower the TTD the better.

A low TTD has many benefits, not only does it indicate that the testers are finding defects quickly, but it also gives the coders the chance to fix the problem when the code is still fresh in their minds.

(more…)

I’ve just returned from a two day ‘Disciplined Agile Development Workshop’. Inspiring stuff! It HAS to be the way to go. Short iterations delivering real stakeholder value. Test driven development, continual integration – all that good stuff. But I must admit I have been wrestling with what that means for system test (SVT). My initial reaction was, well that’s easy, everyone else in the development team moves to the agile model and then SVT use the last iteration, when the code has stabilized and all the dependencies have been sorted out, to execute their scenarios, giving the testers several iterations of wonderful ‘prep’ time – much as we did in the waterfall model.

Fortunately I have seen the light!
(more…)

Depending on your point of view, risk is either a good or bad thing. The pessimist sees the doom and gloom of future problems, the optimist delights in the opportunity, the naive ignore risks completely. As a Test Architect, I see risk as one of my most powerful tools in driving a successful test cycle. I have a ‘virtual risk lever’ that I can pull or release depending on the situation. I can use risk to justify priorities and resource, focus attention and articulate a clear business view of our testing. So what do I mean by ‘risk’ in a software testing context?

Taking a simple definition: Risk is the possibility of an event occurring that will have an impact on the achievement of objectives. Risk is measured in terms of impact and likelihood.

To give an example, if a tightrope walker is walking along a wire one foot above the ground then, regardless of the probability, the impact of falling off is minimal. A sprained foot at worst. This could be deemed a low risk activity. If the same performer walks along a wire one thousand feet from the ground the probability of falling off essentially remains the same, but the impact of falling and receiving major injuries is far greater. In this case, broken bones and worse are a certainty. This would then be considered a high risk activity. So we can see that for the same simple activity the risk can vary depending on the situation.

So how can we use risk to drive our testing?

(more…)