Who Writes the Automation?

Consider two types of automation: unit tests, and end-to-end (E2E) tests.

Current practice is to have the developers themselves write unit tests, especially when doing test-driven development (TDD). Unit tests are fast and lightweight and generally built into the product build process, so failures either happen on the developer’s workstation before new code is shared with the team, or as part of an integration build or other build which happens as part of the dev team flow and prior even to deployment. This tight cycle reinforces the value of developers writing their own unit tests. The risk is when the unit test depends on the implementation of the unit; this might block the refactoring capability that unit tests should offer, but also calls into question the value of the unit test itself; it might be measuring something other than product value. A perspective from somebody other than the owner of the product unit is therefore helpful as a way of limiting risk.

A Current trend is having the developers themselves write E2E test automation as well. The developers are more likely to have the software development chops needed, and their deep product knowledge might speed things up.

Testing and test automation done well is a more challenging and open-ended responsibility than pure software development, because there are more unknowns, abstractions, and dependencies to consider. The developer focuses on creating and shipping a good product and that is hugely difficult and often takes immense training as well, but then measuring the quality of the product is a different task and sometimes even presents a conflict with the developers’ focus.

For example, if someone in a test role files a bug on performance of the product, the bug might prompt an action item for refactoring work and hence delay for the developer role in meeting goals. Such a bug is a good thing for product quality generally because consideration of the bug by the larger team is one of the steps towards shipping a good product as balanced with business needs. However, that step might never happen if the person who might initiate it is the same person who might be conflicted by it; it is simply human nature to overlook it in that case, even assuming the best of intentions.

If the test team is able to create and maintain the E2E automation and meet the other requirements as described by MetaAutomation, then better that they do it and give the developers more time and focus to create a great product.