"Should we automate this?" comes up in almost every sprint, and the honest answer is usually less exciting than either camp wants it to be. The manual vs automated testing debate is mostly a false choice: they are different tools for different risks, and the actual skill is knowing which risk you are holding right now.
Four questions that settle manual vs automated testing
- How often will this exact check repeat? A smoke flow that runs on every merge is a machine's job; running it by hand is a waste of a human. A one-off check for a data migration is not worth a script that will never run again.
- How stable is the feature? Automating a screen that changes every sprint means rewriting the test every sprint. I wait until a flow has survived a couple of releases untouched before I invest in automating it.
- What does failure cost? Login, checkout, anything that loses data or money: automate it and run it constantly, because these are the checks that must never be skipped under deadline pressure. A cosmetic issue on a settings page can wait for the next human pass.
- Does the check need judgment? A script can assert that a button exists. It cannot tell you the flow is confusing, the copy is misleading, or the layout looks wrong.
What human eyes are for
Automation verifies what you predicted; exploratory testing finds what you never thought to predict. Most of the worst bugs I have caught came from exploratory sessions, not scripts: a mirrored RTL layout that every automated check sailed past, a keyboard covering the pay button on one screen size, a crash after backgrounding the app mid-flow. A script only fails where you told it to look. Human time is too expensive to spend re-running the same checklist every week, and exactly expensive enough to spend on questions nobody has asked yet. That is the whole trade in one sentence.
The automate-everything trap
Teams that chase full automation usually end up with a suite that takes hours, flakes daily, and gets ignored, which is worse than having no suite at all, because it trains everyone to shrug at red builds. When I built our mobile suite in Maestro, I deliberately automated only the smoke flows and the stable regression paths, and that alone cut our regression testing time roughly in half. The restraint was the feature. Every test we chose not to write was maintenance we never paid for, and the suite stayed trustworthy enough that a failure still means something.
A decision list your team can steal
- Automate: release-blocking flows that repeat every build, like login, checkout, and core create-read-update-delete paths.
- Automate: anything you have manually tested the same way more than five times against a UI that has stopped moving.
- Automate: tedious setup work, like seeding accounts and test data, even if the checks themselves stay manual.
- Keep manual: brand-new features, until they survive a couple of sprints without a redesign.
- Keep manual: visual layout, RTL and localization checks, usability, and anything answering "does this feel right?"
- Delete: any automated test that flakes twice without a real bug behind it. Fix it or remove it; a flaky test is a broken alarm.
Run the list in order. If a check hits an "automate" line and the feature is stable, script it. If it hits a "keep manual" line, schedule real exploratory time for it instead of feeling guilty about the coverage report.