May Day: the QA work we want to automate, and the part we don't
May Day is about work and the people who do it. A good moment to be clear about which parts of QA we want machines to take, and which belong to people.

Happy Fourth of July. Somewhere today there's a grill warming up, a cooler that's slightly too small, and a neighbor testing fireworks a full six hours before dark.
There's also, almost certainly, a spreadsheet open on someone's laptop. Two hundred rows. "Log in with valid credentials." "Add item to cart." "Apply discount code SUMMER10." "Check order confirmation email." A column for pass, a column for fail, a column for notes that nobody reads after the release goes out.
The manual regression checklist. We've all lived under its rule.
To be fair to the checklist: it exists because someone got burned. Every row is a little scar. "Check that the discount applies to sale items" is there because once, it didn't, and someone found out from an angry email.
And it works, sort of. A careful person walking through two hundred rows will catch real problems. The trouble is everything around that.
It takes a day, so it only runs before big releases. Teams shipping several times a day, especially with AI writing a good share of the code, don't have big releases anymore. They have a steady stream of small ones, and the checklist can't keep up.
It also wears people down. By row 140 even a great tester is skimming. Nobody can stay sharp through the same 200 steps every week, and nobody should have to.
And it only checks what someone already thought of. The checklist is a list of yesterday's bugs.
If we were writing our own small declaration, it would say something like this: the repetitive checks belong to code.
"Add item to cart and confirm the total" is a check. It has a clear input and a clear expected output. It should run on every deploy, in a few seconds, for free, without anyone giving up an afternoon. That's what deterministic gate tests are for, and it's why regression in Testomatica uses no model at all.
Converting a checklist is mostly unglamorous work. Row by row: is this a check, with a definite right answer? Then it becomes a test. Is it really a judgment call, like "does the checkout feel clear"? Then it doesn't belong in an automated gate, and pretending otherwise just produces flaky tests.
Independence from the checklist isn't independence from people. Quite the opposite.
When the repetitive rows are handled by code, the human time that used to go into them is free for the work only people do well. Looking at a new feature and asking "what would confuse someone here?" Trying the strange path. Noticing that the discount banner technically works but reads like a trick. That's testing in the sense James Bach and Michael Bolton meant when they separated it from checking, and it's the part we don't want to automate away.
Agents sit somewhere in between. They can explore and suggest, and some of what they find becomes new code checks. But they don't replace a person's final say on whether something is good enough to ship.
So maybe the better framing is a transfer of power, not an uprising. The checks go to code. The judgment stays with humans. And the spreadsheet finally gets to retire.
If your team still has one, here's a small holiday project for next week: open it, pick the ten rows you dread most, and ask which of them have a single right answer. Those are your first ten tests.
We're onboarding a small group of teams that ship with AI.
Get early access