I build software to automate UI testing. I like watching a machine run a regression suite while the rest of us get on with our day. So when I ask whether we still need human QA, I know what some people expect me to say: automate the rest.
It is a fair challenge. Agents can explore an app, suggest checks, execute them, and sort through failures. After asking whether we still need test cases, I had to ask the same question about the person who creates and reviews them. If the machine can do all the visible work, what exactly is left for a QA engineer?
"Humans will always be important" is a pleasant sentence, but it does not help a team decide what to automate on Monday morning. So let us look at the work, including the parts I would gladly give away.
The Work We Should Hand Over
There is plenty of QA work I would happily give an agent: generating test ideas, preparing test data, exploring screens, rerunning smoke and regression checks, grouping similar failures, and collecting screenshots and logs. If it can turn a pile of red results into a short list of likely regressions, that saves a tester from spending the morning sorting noise.
I've been reaching out to a lot of QA people lately to understand where test automation is heading as AI gets better. A LinkedIn discussion about AI QA agents echoed something I keep hearing: give agents repetitive regression work, bug-fix checks, and the first pass at sorting failures. Use the time saved to test new features and ask whether a passing test was meaningful in the first place. Those are concrete uses for automation, not a ceremony to prove a human was present.
For established behavior, a good test can run over and over. Repeato Studio can record UI flows and check visible content; its CLI can run the same workspace in a batch on a team's CI agent. The report gives a person evidence to inspect when something fails. That is exactly the sort of repeatable work software should carry.
A Green Test Can Still Be Wrong
Suppose a checkout test opens the cart, taps Pay, and sees an order confirmation. Green. But the discount was applied twice. Or the total is correct for the test account and wrong for customers paying in another currency. The test did what it was told. The question is whether anybody told it enough.
An agent can propose an assertion. It can even write one. But somebody needs to ask where the expected total came from, what happens when a card expires, and which combinations of account, currency, and promotion are worth testing. A plausible assertion is not a product requirement. If the same agent invents the expected result and then congratulates itself for observing it, we have built a very efficient loop around an assumption.
This was the point of the earlier article: an autonomous crawler can find dead ends and suspicious changes, but comparing screens does not tell it whether a change is correct. Better exploration gives us more observations. It does not automatically give us a better definition of success.
Human QA Is More Than the Last Approval
It would be tempting to make the human role a final sign-off button. That is too late. A QA engineer is useful before the test runs, when requirements are still vague and the team can still change them.
Consider a new messaging feature. A scripted check might prove that one user can send a message and another can see it. A tester asks what happens when the receiver switches devices, loses connectivity, receives the same notification twice, or blocks the sender while a message is in flight. Those questions come from understanding the users and the failure modes, not from repeating the happy path more quickly.
In those conversations, the human work comes up earlier than the final report: risk assessment, exploratory testing, unclear requirements, and challenging an agent's assumptions. I would add one more job to that list: deciding when a test has become obsolete. A suite can be green because it still checks yesterday's product perfectly.
The Boundary Will Move
I do not think today's division of labor is permanent. Agents will get better at exploring, setting up data, identifying meaningful changes, and proposing checks. Some decisions that currently require a person will become routine once the team has written down the rule and the evidence needed to apply it.
That is good news. It also means the human job is not a protected list of tasks. It is the responsibility to keep examining the system: Which risks have we missed? Which checks can we trust? Which failures are acceptable? What evidence would change our minds about releasing?
There is a practical test for any claim that an AI agent can replace QA: give it a new feature with an incomplete specification, a passing but shallow suite, and a release deadline. Ask it what should block the release and why. Then ask who is accountable when that answer is wrong. Until those questions have convincing answers, removing the human QA role is mostly a way to make the uncertainty less visible.
So yes, we still need human QA. We should also make humans spend less time replaying known steps and more time finding the assumptions nobody thought to write down. The machine can run the checks. The tester makes sure they are the right checks.