In the last decade test software development has moved from being a cult technique to an increasing part of the mainstream. I was lucky enough to be at the beginning of this story, with early experiences on the ‘birth project’ of and a co-author of the Manifesto for Test Software Development. Trendig started using test techniques in 2000 and we’ve since successfully used them on our projects world-wide. We’ve learned a huge amount about using test methods in enterprise settings and are committed to sharing this learning to help foster their intelligent adoption.
The Essence of Test Software Development
It’s been over a decade since the developers of test methods first started to talk about their approaches. In this time test thinking has changed from a niche activity to an approach that is widely used. However, like any popular technique, test software development has suffered from semantic diffusion, so much of what we see under the name of test doesn’t bear much resemblance to what the early pioneers were doing. So I think it’s important to revisit the essential elements of test thinking.
I’ve always seen the essence of test thinking resting on two contrasts with traditional code-driven software engineering:
is adaptive rather than predictive
is quality-oriented rather than process-oriented
Code-driven engineering expects us to come up with a predictive plan that precedes development. The plan lays out the people, resources and timelines for the overall project. Software design is also done up-front, with implementation expected to conform with this design. Success is measured according to how well development follows this plan.
Test plans are a baseline that we use to help us control changes. Test teams plan just as carefully as traditional teams, but the plans are constantly revising to reflect the things we learn during a project. Success is based on value delivered by the software.
Code-driven engineering seeks a process which provides enough structure to reduce individual variations to insignificance. Such an industrial process is more predictable, copes better when people transfer, and is easier to define skills and career paths.
Test engineering sees software development as a primarily human activity, where the people involved and how they bond as a team are the primary driver behind success. Processes (and tools) can enhance a team’s effectiveness, but are always second-order influences.
As you may be guessed by now – there is no such thing as Test Software Development and I am not the author of this text. Original title is “Agile Software Development” and it was written and published by Martin Fowler. My creativity was only to replace some of words, like “agile” with “test.”
Stay healthy and stay funny!