Why Great Automation Engineers Should Quit Writing Tests
Manual testing remains the primary entry point into IT for many. I have seen numerous trainees and juniors with a keen interest in development roles during their initial interviews, asking unconfidently, “How can I transition to a developer, designer, or analyst position within your company?” Even if they don’t say it out loud, their goals are clear. This presents a distinct challenge: within just 1–2 months, these candidates may lose motivation to continue in manual QA roles, seeking instead to shift towards other branches. If you have a cross-platform hybrid application with constant changes in design, then maybe this experience could be relevant for your QA team.
Another challenge we’ve encountered is the long hiring period for skilled automation engineers. Initially, we believed that only high-skilled automation specialists could manage the complexity due to the high entry threshold (complex apps, different versions, and instances on Mac/Win/Linux OS, etc.). We considered a different approach: simplifying the outward appearance of complex projects to encourage contributions from various specialists, including manual testers and developers.
From my perspective, the value of a truly proficient automation engineer is often underestimated. There seems to be a popular belief that the natural growth line in IT projects looks like:
This belief tends to elevate senior automation engineers to an almost mythical status. However, as these “unicorns” transition into development roles, the quality of automation frameworks worsens. This is mostly because the structure of the frameworks becomes less effective, the code isn’t reused enough, and there’s often a need to create automated tests from scratch.
Hiring more staff might seem like a solution, but “quantity does not equal quality.” This needs a strong plan for how the system is built and mature ways of working. Essentially, an excellent automation engineer is a developer with a deep understanding of testing and the associated technologies and frameworks.
To make it clearer, I will now break down the typical automation developer growth process into stages:
To implement a strategy for the effective growth of a QA specialist within the company, we revised the existing approach that was leading to negative outcomes. We now provide entry-level employees with sufficient motivation and clear objectives to foster their development.
The concept is based on building a comprehensive and multi-level system that is supposed to be easy to handle internally and to develop further externally. The goal was to use the ‘constructor’, like simple templates for each part of the tested app, to write tests and run them at continuous and nightly branches. We combine people with enough expertise to develop and maintain a strong automation solution in one team. This team was involved in creating a framework and user-friendly interface that includes those helpful tools and modules. This team also provides documentation and collaborates closely with the QA Manual team, informing them about new changes and assisting them in using these tools effectively. We have concluded that the development of such a framework primarily requires engineers from levels 3 and 4. At the same time, automation engineers from the first two stages are responsible for monitoring the coverage of automated checks and analyzing the results of test runs. The framework is simple enough, though proactive juniors from various IT teams (such as analytics, for example) can write such tests if needed.
After almost a year of implementing this approach, I can say that reevaluating roles within our teams has helped us establish more clear goals, utilize potential, and most importantly, improve satisfaction levels among both Manual and Automation Team members. I’m curious about how QAs in other companies have dealt with similar challenges. What have your experiences been?
