When should we NOT automate a test in our regression suite?

Question

Leadership pushed a "100% automated regression" mandate. I've been in QA long enough to know that's usually a bad idea, but I need a concrete list of "don't automate this" cases to push back with. What's your rule of thumb for what stays manual (or exploratory) forever?

seed-marcus-s · Accepted Answer

"100% automated regression" is a productivity trap. Here's my "don't automate" list, with the reasoning you can hand to leadership:

**1. Anything that changes weekly.**

Onboarding wizards, marketing pages, promotional banners, A/B tested flows. Automation cost > manual cost when the target moves faster than your suite can adapt.

**2. Visual polish and UX judgment.**

"Does this feel right?" is not automatable. Snapshot tests catch pixel diffs, not "this animation is jarring". Reserve human eyes for perceived quality.

**3. Exploratory testing of new features.**

Automation confirms known behavior. Exploration discovers unknown behavior. Automating exploration = confirming what you already thought, missing what you didn't. Every new feature deserves 2–4 hours of unscripted use before you write a single automated test.

**4. Complex setup / rare edge cases.**

A bug that requires "database in state X, user 3 days into trial, timezone Pacific, feature flag Y half-rolled" — 4 hours to automate, runs once a year. Manual repro + monitoring is cheaper.

**5. Physical / sensory / hardware.**

Camera quality, audio pipelines, haptics, print output, physical devices. Automation exists but has diminishing returns; humans catch what synthetic checks miss.

**6. Security testing (mostly).**

Automate the known-CVE and dependency scanning. Manual pentesting for logic flaws — the interesting bugs don't show up on Burp active scan.

**7. Anything that would take longer to automate than to