When software releases become ever more frequent, discrete development and operations disciplines converge, and roles and responsibilities begin to blur into what we now call “DevOps”.

One converged practice is Continuous Integration (CI), where code check-ins automatically invoke recompilation and optional deployment. CI is now a very common best practice, widely adopted even where code releases are not all that frequent. Developers appreciate CI’s ability to identify static code integration errors as early as possible, and open-source CI and IDE tools remove most financial impediments.

Another converged practice is Test-Driven Development (TDD), an aspect of Agile, where developers create new tests concurrent with new code. But unlike CI, TDD adoption remains slow, and TTD automation slower still, even at companies where software release frequency is very high and the development process is supposedly Agile.

Why might that be? Let’s consider some of the usual suspects:

– Poor QA talent and skills:

  • OK, maybe the best talent doesn’t go into QA as a career, but isn’t this a bit too much like “blaming the victim”?

– Lack of development tool investment:

  • IDE tools are free (or nearly free), but a lack of investment in tying integration engineering tools together is common, which is why we see CI without automated deployments at many companies.

– Lack of test automation investment:

  • Again, in many cases, the tools themselves are free, but if investment in tool integration for developers is weak, in QA it can be downright non-existent.

– Lack of test environment investment:

  • Also very common, even where virtualization and cloud are the norm, because even when infrastructure ceases to be physical, infrastructure engineering is still complex and takes time.

– Developer obstinance:

  • Exists, but is overrated as a cause. Yes, some coders think themselves too good to write tests, but most developers I know would love to know exactly how to validate their code, and they understand that quality must be built-in from the start. If someone would just tell them how to validate…

– Poor validation requirements:

  • …Bingo. Agile customers are expected to know what they want at a sufficient level of clarity to state both a functional requirement and its validation via stories. But they do not (and perhaps never can completely (c.f. Lehman on “Software Uncertainty”).
  • Most Agile stories are not requirements but hypotheses about what customers may actually want – after something is built that they can interact with.

So why spend more time and money on validation and test automation? Because unfortunately, by the time your requirements really are specified with clarity and customer expectations of quality are high, you will find yourself far behind creating tests and automating them. Our customers often find themselves with a very large technical debt of this nature to pay.

Structural business issues aside, the software community could do a better job of integrating available open source testing automation tools for easier adoption by both development and QA. This is a goal our engineers at THPII are working on.

How well does your test-driven development adoption experience correlate with ours? We always appreciate your comments.