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.
