Test Automation

Tom Breur

26 February 2017

Test automation is a two-edged sword. On the face of it, it makes perfect sense. And oftentimes it does. As you strive to deliver features early, they always and consistently have to be of (high) quality: otherwise the output is either not of value, or your pace will not be sustainable. Those concurrent demands (deliver value early and often, ensure a sustainable pace) are guiding principles, and prevent accumulation of technical debt or software rot. The “pressure” to deliver value early will be enforced by your Customer, and I find that teams are often (overly) eager to show ‘something’ as quick as possible – often at the expense of thorough testing and or refactoring.

Test automation helps to keep the deliverables of high quality. Writing tests upfront can also help tremendously to get clarity on that the product is expected to do, exactly. This is where Specification by Example dovetails nicely with Test Driven Development (TDD). Verifying that all your tests keep running as the build evolves allows you to go faster, and take a little bit more risk: if you make a bad turn, your tests will tell you so – immediately!

One of the areas where I “struggle” with test automation is when business owners, as the Product Owner (Scrum) or Customer (XP), “demand” that test automation is a requirement. Presumably because they “know” it is more efficient. Why do I have a problem with that? Well, that decision is, and should always be, the purview of the team. They are closer (closest) to the work, and that is where these design decisions ought to be made. The team recommends manual, context driven testing? Well, that is their privilege. If they deem that is “the best” route to value creation, no responsible Product Owner or Customer should interfere with that. But that’s just me, of course…