Manual Testing is Dead. Long Live Manual Testing.

Someone writes the obituary for manual testing about once a year. The suite is faster, it doesn't get bored, it runs at 1 a.m. Why is a person still clicking? Then a bug ships that no script had a name for. On a checkout I watched, the card form was fine. Automation loved it. If you entered the card, hit back, and came forward again, the cart total went to zero and the pay button still looked enabled. A customer in Pune paid nothing and got an order confirmation for a full basket. The script never pressed back. A person did, because they were annoyed and poking.

Manual testing didn't lose a contest with automation. They were never in the same event.

Automation is a memory

A good suite remembers the failures you've already paid for. Login. The refund path. The permission check that bit you in March. It runs them the same way every time, including Friday at 6, when a person would rather not. That memory is worth a lot. It is also only a memory. It cannot be curious about a path you didn't write down.

The back button wasn't in the plan. It was a tester having a bad feeling about the form keeping state in two places. You can automate that case after you've seen it. You can't schedule the bad feeling.

What people still find

The production bugs I get asked about are almost never "the button is gone." They're sequences. Back, then forward, and the cart lies. A filter that works until you combine it with the export. A layout that's fine at the width in the design file and wrong on a 360px phone the office doesn't own, where the pay button sits under the keyboard. None of those start as tickets. They start as someone trying to be a slightly difficult customer for half an hour.

A checklist can fake this for a week. Then it becomes the same twelve steps, and the difficult customer retires. The session has to be allowed to wander, with a timebox so it doesn't become a lifestyle.

Split the jobs on purpose

The teams that leak fewer of these bugs aren't the ones who fired the clickers or the ones who refused scripts. They parked the memory in the suite and left the wandering to a person. Regression and smoke on every change. A chartered hour, twice a week, where someone tries to break the thing that just got built, with no script and a note at the end: what they tried, what wobbled, what should become a test so a human never has to catch it twice.

The failure mode is spending the QA week repairing scripts. Selectors drift, someone updates twenty files, exploratory time gets "pushed." Then you're paying a person to be a slow CI job, and the back-button bug has nowhere to live. If the suite needs that much babysitting, fix the suite. Don't spend your only curious hour on it.

The question worth asking in the retro

Not "manual or automated." What share of the week went to remembering old bugs versus looking for a new one? If the split is 90/10, you don't have a manual-testing philosophy. You have maintenance with a job title. Flip it only when the suite can hold the old bugs without a weekly rescue. Until then, every hour you pull into repair is an hour the cart-total bug gets to stay invisible.

A practical split I keep coming back to from that checkout team: the person who found the back button wrote the repro in four lines, and someone else turned it into a script the same day. The human didn't own the script after that. Next session they went after the coupon field, which had the same two-places-for-state smell. That's the loop. Curiosity finds it. The suite adopts it. If the finder also has to maintain every adoption, the loop dies by the third week and you're back to a checklist with a person's name on it.

Keep the person. Point them at the product, not at the framework. Let the suite be the memory. Those are different jobs, and the obituary keeps mixing them up.