20 Oct 2026 What is a test automation engineer, and what should you hire for?

In short: A test automation engineer builds and maintains automated tests that check your biggest risks on every change. When you hire one, tool knowledge matters less than you think. Tools can be learned in weeks. Risk analysis, test design and understanding your business process take years, and they decide whether your automation protects your releases.

The job ad is usually the easy part. It asks for Playwright or Selenium, maybe Tosca, a few years of experience and an ISTQB certificate. You find someone who ticks the boxes, and a year later you have hundreds of automated tests. Yet releases still feel risky, and nobody can say what the tests actually cover. That pattern starts with how the role is defined, so let’s start there.

What does a test automation engineer do?

A test automation engineer decides which checks a computer should repeat for you, builds those checks and keeps them working. The tests run in your pipeline, every night or on every change, and warn the team when something breaks. The tool is only the means. The real work is choosing what to test. Think of the business rules that cost money when they’re wrong, the links with other systems and the paths your customers use every day. A good engineer also keeps the test set small enough to run fast and stable enough to trust. When a test fails, people should believe it, not shrug and run it again. That means writing tests like good code: readable, reusable and easy for a colleague to change. It also means explaining results in plain words to people who don’t test for a living. Product owners and managers decide whether a release goes out, so they need to understand it.

The title varies. You’ll see QA engineer, SDET, test automation specialist or “testautomatiseerder”. The tasks overlap a lot. What matters is whether the person thinks like a tester first and a programmer second.

Why does hiring on tool knowledge go wrong?

Hiring on tool knowledge goes wrong because the tool is the part that is easiest to learn and easiest to replace. At clients we often see QA hiring focus on Playwright, Selenium or Tosca. Yet risk analysis, test design and understanding business processes matter at least as much. The result is automation without grip. There are plenty of tests, but they check what was easy to automate, not what is risky. Coverage numbers look fine while critical production incidents keep coming.

There is a second effect. A team that hires one tool specialist often ends up with a framework only that person understands. When engineers leave, the knowledge of the automation setup leaves with them. The next hire starts by rebuilding, often in a different tool. The tool changed, but the problem didn’t.

Tools also move fast. Playwright barely existed in many teams a few years ago. Someone who understands testing can switch tools in a few weeks. Someone who only knows a tool can’t easily learn to think in risks.

What skills matter more than the tool?

Five skills decide whether a test automation engineer makes your releases safer. Tool knowledge helps, but it comes after these:

• Risk analysis. Can they tell which part of the system would hurt most if it broke, and test that first?
• Test design. Do they know how to pick a few smart test cases instead of hundreds of similar ones? Think of boundary values and combinations that matter.
• Understanding the business process. Do they ask how an order, a claim or a booking really flows, before they write a single test?
• Maintainable code. Are their tests readable, with clear names and shared building blocks, so a colleague can fix one?
• Explaining results. Can they tell a product owner in two sentences what failed and why it matters?

And ISTQB? The ISTQB Foundation Level certificate shows that someone knows the shared vocabulary of testing. That is useful, because the team speaks the same language. It doesn’t prove someone can design a good test set. Treat it as a baseline, not as proof of skill.

What this looks like in practice: at a government operations centre, a platform kept changing and had no regression tests at all. Our tester combined use case testing and exploratory testing with Selenium automation across browsers. After every test cycle, they gave a release advice. The automation was one part of that work. Deciding what to test and advising on the release was the rest.

How do you test for those skills in an interview?

You test for these skills by giving candidates a small, real problem instead of a tool quiz. Three exercises work well, and each takes about fifteen minutes:

1. A user story. Hand over one story from your backlog and ask: what would you test first, and why? Listen for risk and business impact, not for a long list.
2. A flaky test. Show a test that sometimes passes and sometimes fails. Ask how they would find the cause. Good answers mention test data, timing and the environment before they blame the tool. We wrote about this in why automated tests fail when nothing changed.
3. What not to automate. Ask what they would leave to people. A good engineer names exploratory testing and acceptance testing with users, and can explain why.

Then ask about a test set they built that is still running a year later. Who maintains it now? The answer tells you whether they build for themselves or for the team.

What this means for your team

Write the job ad around risk, test design and your business process, and treat the tool as a detail. Test those skills with a real story from your backlog. And plan for more than one person. A test set that depends on one engineer is a risk in itself: holidays, illness and a new job all stop it. The test strategy should say who owns the automation, not just which tool it uses.

Finding that profile also takes time. In a market where 44.7% of QA teams report being understaffed, months of searching are normal. Add onboarding, building a framework and the maintenance that grows with every release. Sometimes hiring is the right move. Sometimes you need an experienced tester in the team now, and sometimes you need a test set that keeps running without depending on one hire. We do both. Our test consultants join your team, in your tools and your sprints, from test strategy to hands-on testing. Technolution, a client for six years, says our testers “blend very well into our projects”. Read how that works on our QA & Testing Solutions page. And if the real need is a regression suite that keeps running, that is what Test Automation as a Service is for.

Frequently asked questions

Do you need ISTQB to be a test automation engineer?

No. ISTQB shows someone knows the shared language of testing, which helps a team. It doesn’t show they can design a good test set. Use it as a baseline and test the real skills in the interview.

What is the difference between a QA engineer and a test automation engineer?

The titles overlap and companies use them differently. A QA engineer often covers testing in general, from test strategy to manual checks. A test automation engineer focuses on building and maintaining automated tests. In both roles, testing skill matters more than the tool.

Can a manual tester grow into test automation?

Yes, and often with good results. An experienced tester already thinks in risks and knows the business process. Learning to write maintainable test code takes effort, but it is the easier half to learn.

How long does it take to hire a test automation engineer?

It depends on the market and your requirements, but plan for months, not weeks. Add a few months of onboarding before the new hire knows your systems well enough to choose the right tests.