Happy paths should be automated, and that part isn't up for debate. A suite that runs the same core flows on every commit is what actually keeps a release stable, and there's no version of "we'll just check it manually before every deploy" that scales past a small team. Once that's in place, the question is what's actually left for a person to do once the obvious stuff already runs itself.
I keep a bulk-edit feature as the example I come back to. The automated suite covers selecting rows, editing a field, saving, and confirming the change. Green on every run, and it should stay that way. None of that is where I spend exploratory time, since it's already covered and covered well.
Where I actually spend time is the stuff nobody wrote an assertion for, because nobody thought to yet. I select a few hundred rows instead of a few, since that's closer to how someone treats a bulk-edit feature once they trust it. The save button spun and never resolved, with nothing in the UI to indicate anything had gone wrong. The backend had a request size limit that silently dropped the request past a few dozen rows.
That gap isn't a hole in the automated suite so much as the shape of what automation structurally can't reach on its own. A human has to imagine the scenario before anyone can write a test for it, and a scenario like selecting far more rows than the test data ever used isn't something you arrive at by making the existing suite more thorough. You arrive at it by using the feature the way someone under real conditions would, which usually means pushing past whatever amount the test data was written to cover.
The other place a person earns their keep is judgment calls automation can't make. A test can assert that a field shows an error message. It can't tell you the message is confusing, or that the error appears in a spot nobody would look, or that the flow technically works but takes four more clicks than it should. Those aren't failures a script can detect, since there's no clear pass or fail condition to assert on. Someone has to actually use the thing and notice.
I still treat the automated suite as the floor, not something exploratory testing is meant to replace or double-check. The floor is what keeps regressions from shipping. What a session is actually for is the edges nobody imagined yet, and the parts of the experience only a person can judge.
Jeff Thoensen is a Context-Driven QA Engineer focused on automation, API testing, and exploratory testing. Find more at jeffthoensen.com
SOCIAL SHARE CARD GENERATOR