May Day: the QA work we want to automate, and the part we don't

May Day is, in most of the world, a holiday about work. About the people who do it, the hours they put in, and the long argument over what a fair day's work looks like.

It feels like a reasonable day for a company building automated QA to say plainly what we think should be automated, and what shouldn't. "AI will replace testers" is a sentence we hear a lot. We don't think it's true, and we're not trying to make it true.

The work we'd happily take off your plate

Some QA work is necessary and joyless. Anyone who's done it knows.

• Running the same regression checklist for the fortieth time. Log in, add to cart, apply coupon, check total, log out, repeat on mobile. A person doing this on a Friday evening is a person who will eventually skip step 7.
• Checking every page for the boring stuff. Broken images, server errors, console errors, missing titles, garbled characters. Nobody should be scrolling through 300 product pages looking for a broken thumbnail.
• Reproducing a bug three times to see if it's real. Important, tedious, and exactly the kind of thing a clean browser session does better than a tired human.
• Writing up the ticket. Steps, URL, screenshot, network trace, browser version. Nobody went into testing because they love filling in the "environment" field.
• Telling a flaky test from a real failure at 2 a.m. Was it the code, or did the staging database hiccup? A system can check that before it wakes anyone up.

This is the work we want Testomatica to do. Not because people are bad at it, but because it's a poor use of people. It's repetitive, it's precise, and it has a right answer. That's what code is for.

The work we don't want to automate

Then there's the part that makes testing a profession and not a chore.

Deciding what matters. Looking at a new feature and asking "who is this for, and what will annoy them?" Noticing that a checkout flow is technically correct and still confusing. Knowing that this customer segment always pastes their VAT number with spaces in it. Saying "I know all the tests are green, but I don't feel good about this release."

James Bach and Michael Bolton draw a line between checking (confirming known expectations, which machines can do) and testing (the human work of exploring, questioning and learning). We wrote about how that shaped our design in Checking vs. testing. The short version: we want machines to take as much checking as possible so that people have more time for testing.

Our agents do explore, and they find things a script wouldn't. But they explore inside a charter, they never judge their own findings, and they never block a release on their own. Humans keep the final sign-off. That's not a temporary limitation we plan to remove later. It's the design.

A fair division

If there's a May Day lesson in all this, it might be that the question isn't "humans or machines?" It's who does which part, and whether the split is fair to the people involved.

A tester who spends their week clicking through the same checklist is underused. A tester who spends their week on the questions nobody else is asking is doing the job they were hired for.

What's one task on your team's QA list that nobody would miss if it disappeared tomorrow?