Agile Test Improvement: contradiction or two sides of a coin?

How valuable is thinking about test process improvement in a time and age where Agile is rapidly becoming the dominant mindset for software development? Are we evolving so fast that an approach towards test process improvement like TPI NEXT^®, which was successfully launched in 2009, has become all but obsolete 4 years later? I think not.

Testing is an inextricable part of agile development. It can be done badly, just as it can be done well or even very well (very badly is also possible ;-)).

Every beginning is hard, so when you and your organization set out to practice agile development, you probably won’t get it right on the first time. There is room for (test process) improvement, but how does this ‘improvement room’ relate to existing models like TPI NEXT? Is the basic paradigm of such an ‘old school model’ not waterfall? And by implication unsuited for an agile way of working?

So, can we apply a model like TPI NEXT in an organization that’s turning agile?

The answer is “Hmmm … Yes and No”.

No, in so far that in a truly agile environment focusing on just one aspect of the entire development process is sub-optimizing by default. This applies just as much to testing as to e.g. requirements management or software design. But who dares to state that he or she is working in a “truly agile environment”?!  The crux being ‘environment’: are you truly confident that not only you and your development team can act agile, but that the same applies to ‘all the others’ in your organization?!

So Yes as well, since it provides ideas and guidelines as to what ‘good testing’ means and as to where and how to align agile practices with not-so-agile practices. Indeed, one of the core concepts of TPI NEXT is the Enablers, which pay special attention to the interaction of testing and non-testing activities.

And let’s keep in mind that when you – even for a moment – hesitated to answer the question full heartedly with “No, impossible!” the answer, at least partly, is “Yes”.

Key to this all is the underlying assumption that we want to get better at what we are doing and that we all understand and appreciate the direction we’re collectively heading. In this respect ‘waterfall supporters’ that refuse to follow an organizations growth towards agility – or even actively oppose it – are just as undesirable as ‘agile advocates’ with no eye for the ideal pace of an organization to grow into an agile community.

So, to stay in line with the Agile Manifesto: while there is value in the contradiction, we value the “two sides of a coin” approach more!

Epilogue: having said all the above, I’m very interested in real life cases of struggling with testing and Agile. I would like to call upon you – testers and non-testers, Agile adopters or not (yet) – to share and exchange thoughts on your Agile testing challenges. Be it on this forum or on a more personal note through mail or phone.

 

More information:

Ben Visser is a highly experienced test manager and test consultant. In a career of over 15 years as a tester, he has fulfilled a wide range of test functions, from programmer of automated scripts, to test manager of a large international program. He has worked in traditional waterfall developments as a change manager responsible for test and acceptance environments, as well as model-based testing.

Based on this extensive experience, he co-authored Sogeti’s TMap NEXT® Business Driven Test Management (Nov 08) and more recently TPI® NEXT.

Philippe has worked with architecture related assignments since 1998 and as a educational facilitator since 2000.