After regularly seeing job openings for "QA automation engineer", I wonder why this role is so prominent? (I deliberately assume a specific view in this post, hoping to get interesting replies.)
I feel like this role is inevitably destined to make itself redundant within a typical shift-left, cross-functional team. It has been my experience several times: as part of the process improvements, the test automation responsibility is delegated to the developers (or whole team) in increasing measures. Which is by itself a good thing, but over time the workload slowly diminishes for the QA automation engineer.
Considering a few things:
- Who? Having a dedicated role is likely to lead to knowledge gaps (developers write unit tests, the automation engineer tackles whatever follows in the pipeline). That's a silo to avoid. Isn't it preferrable to have the developers write as much of the testing as possible, so they are all aware how/when/what when it comes to automated (and failing!) tests.
- When? Eventually a shift left is in order (where possible, for somewhat stable features). Why shouldn't the developers also write integration or API tests for their (new) features? More bugs are prevented, and the test runs are kept green. Also the accountability is equally spread among the team.
- How? A decent developer has at least the same coding skills as a decent QA automation engineer (which aren't necessarily former developers). So this is no reason why developers can't write testing libraries and tests.
- What? A fair point would be the testing mindset: what should be automatically checked? However, I believe developers can be supported by any QA already in the team (even non-technical), with some minor research, to determine which cases to automate. Collaboration improves and a QA perspective is consulted, even if the developer does the coding.
However, I can see advantages for this separate role, but also with counter arguments:
- Tooling: a person already experienced in test automation is more aware of the available tools and their (dis)advantages. However, if the team can't decide after researching, I'd still prefer a consultant to set up the most adequate tooling rather than add a long-term role to the department.
- Tester mindset and common sense: applying the correct mindset has already been addressed aboven. Also, while a developer might write fancy code that is totally overkill for the task at hand, testers are often more realist in this regard. However, if the developers are unable to write a decent (and easy to use) testing library, they're probably not the best developers around. Unless they like making things difficult for themselves.
- UI and regression testing: this is the one thing that testers often handle once a feature is up and running, and stable. While perfectly acceptable, there is in essence no reason why the team as a whole can't handle this rather than one person.