I think balance is important. Whenever I teach people about BDD or automated testing, we make a list of the costs and benefits of test automation.
The lists typically look something like this:
Benefits:
- thorough analysis of a requirement
- confidence to refactor
- quick feedback about defects
- repeatable test
- living / trustworthy documentation
- frees up manual testers for more interesting exploratory testing
Costs:
- time spent leaning how to write a test
- time spent writing the test
- waiting for the test to run
- time spent maintaining the test
- having a false sense of security when am automated test is passing
The benefits are great, but don’t underestimate the costs. If your team are in the early stages of adopting test automation, you’re going to invest a lot of time in learning how to do it well. You’ll make some mistakes and end up with tests that are hard to maintain.
Even once you’re proficient, it’s important for each test to justify its existence in your test suite. Does it provide enough of a benefit to justify the investment needed to write it, and the ongoing maintenance cost? Is there a way to bring down the ongoing cost, for example by making it faster?
I also find that listing costs and benefits helps to tackle skepticism. Having a balanced discussion makes space for everyone’s point of view.
I’m teaching a public BDD course in London, 4-6 December. If you’d like to take part you can sign up here: