QA-automation in a modern development?

Question

I've heard that the QA-automation is gradually becoming a developer's work. More tests tend to be done on the lower levels of the Testing Pyramid. The automation of the end-to-end level, which is now done by QA-automation engineers, will be the responsibility of developers (just as it is now with unit-tests). Automation QA-engineers will gradually be replaced by developers. Do you think it is so?

I have concerns about this because testing, automated or not, still requires testing mindset and skills, designing test plans, and so on and developers just have another mindset and skills.

Answer 1

I think it's generally true that the line between "developer" and "tester" becomes more blurry, and this is a good thing. However, even if the same person is writing production code and tests, that doesn't eliminate the need for testing specialists or experts.

The biggest concern is the maintenance of the testing frameworks. Just like the product, the test infrastructure needs to be maintained. There could be new versions of the libraries and tools to be evaluated and pulled into the project, requiring changes. Tools can become obsolete and superseded by other technology. The testing tools need to be integrated with various CI/CD pipeline parts to give visibility to the teams. Having a person or team of people to own the test automation framework and tools would likely fall onto a specialist team responsible for keeping up-to-date with the latest knowledge in this domain.

In addition to maintaining the existing tools, there is a forward-looking aspect for both tools and processes. Monitoring what the current state-of-the-art is in testing and test automation can help the organization maintain a competitive advantage. The core developers are probably looking at the tools, technology, and ways of working needed to design, build, deliver, and maintain the core product and remain competitive, but someone needs to do that for the testing framework. Again, a specialist team can take on this work, and it pairs nicely with routine maintenance of the tools.

Someone needs to be able to teach the developers what is necessary to use the automation tools. Whenever the tools or the process changes, the developers don't inherently have this knowledge. Having someone who can work with each of the development teams to keep their skills current as the environment changes is vital.

Some level of independence may also be necessary, depending on the organization's environment. Even if developers are taking part in writing automated tests, especially at the system and acceptance levels, having a non-developer review the tests against the requirements and ensure that they are good, high-quality tests can be the test specialist's role. The same person can be involved earlier on in the requirements and design activities to ensure that the outputs are clear and testable, and any interesting test cases are captured early on. This goes to having a tester's mindset to find the test cases that truly exercise the system beyond just coverage metrics.

Overall, I don't see QA automation engineers being replaced by developers. Instead, I see a shift in focus away from exclusively manual testers to people with a strong test mindset involved throughout the development life cycle. These people would lend expertise in test tools and processes to the developers and ultimately take ownership of product quality through a collaborative relationship with the developers. It takes a lot of skills to build software, and having a cross-functional team requires having all of those skills available in a way that enables others to level up to support the broader objectives.

Answer 2

I've been hoping to see this happening for years, but haven't noticed any of such changes. The opposite of that - I see more and more of AQA jobs. Even when it comes to very technical parts - they are often done (always poorly) by a manual QA who was trained in automation instead of a seasoned developer specializing in testing.

Test automation is both:

• Challenging - it requires good OOP and architectural skills*
• And diligence, patience

Also it doesn't look as attractive in CV as a yet another framework/tool in the list of skills. All of this makes it very hard to convince developers to learn and do proper test automation.

For testers on the other hand often automation seems like the next step. And the job market makes it very attractive too. And so many of them quickly move on to automation. Which is a shame since some of these people were very good manual testers.

So hopefully this will become a trend some day, but unfortunately this won't happen any time soon.

As for the mythical "testing mindset" - it's all about the role. I've been both in Test and Dev roles and I can tell you - this completely changes your perspectives. Simply because your main function changes and you have different priorities, different things to pay attention to.

It's only when you mix the roles it becomes hard to do both - because you always feel like core development has higher priority and you want to spend more time on it (especially when deadlines are approaching). But it's not impossible - on my current project all developers automate tests themselves (even end-to-end ones), this seems to be working pretty well in my particular team. It took some convincing though.

*There reason you need architectural skills:

1. The idea of Test Pyramid is to write fewer tests at high level (Selenium, etc) and write more at lower levels (unit, component tests). For those tests to be well written we need to be able to write production code in a testable way. AQA needs to be able to teach and enforce developers to do so. And then ideally - to make them write tests for their code. For that AQA needs to have good architectural skills and be an authority for developers.
2. In middle-level tests we want to invoke the frameworks that developers use so that those in turn invoke our production code. And then be able to check the results. For that oftentimes you need a deeper understanding of those frameworks than what a typical developer knows.
3. In most cases the hardest part of testing is preparing test data. Complicated software will have lots of inter-connected objects that need to be created/stored. A naive approach that most developers/AQAs choose is hardcoding data, but this doesn't scale well when the product grows. At some point a question of dynamic/randomized data generation will be raised - and this is a pretty complicated task for which you need very good OOP skills. I often find myself spending more energy designing such code as opposed to the production code.

Answer 3

Automation QA-engineers will gradually be replaced by developers.

Software automation is a branch of software development. So creating the automated tests already requires a "programmer". (I'm aware that some automated testing software provide a GUI - but to create sophisticated tests you'll always need to tweak/create code.)

But running the tests and analyzing the results and even deciding which tests to code, needs a QA-like mindset. As you noted, software engineers are usually not trained in this skill.

That's besides for the "problem" that getting programmers to write the tests for their software has the same problem as getting them to manually test their own software. The programmers "know" what to test and what not to test, thereby often missing crucial components or test cases.
These can be cases they are terrified of testing or - on the other extreme - cases that they are convinced are too simple/safe to test. Not to mention the edge cases that, if they forgot to code them they will also forget to write code to test.

So, no, it's not going to happen that programmers will fully replace QA-automation engineers.