How I Decide What Should Be Manual vs Automated

People often ask me, “Should this be automated?”

My answer is always the same: it depends.

Automation is not here to take the place of manual testing. The key is to pick the best tool for each job. Since every test takes time to build, maintain, and review, it should be worth the effort.

When I choose what to automate, I first look at how stable the feature is. If something changes often, automated tests can break and become expensive. In those cases, manual testing works better until things are more stable.

I also think about how often a test will run. Tests that need to run many times, especially across different releases or setups, are great candidates for automation. Regression tests fit this perfectly.

Risk matters as well. Important workflows, such as payments, authentication, and data integrity, should be automated once they are stable. Automation helps ensure consistency and builds confidence where errors could be costly.

But I always keep exploratory testing manual. Tasks that need human judgment, such as checking usability, clarity, or flow, are best done by someone actually using the system.

I pay attention to signal quality too. Automated tests are only useful if their failures are meaningful. If tests often fail due to timing or environment issues, they can create more work than they save.

Automation should support QA, not replace it. I aim for a balance where automation handles the routine parts, and manual testing takes care of the more detailed or complex situations.

When teams automate with care, instead of just out of excitement, they get better coverage, fewer false alarms, and more trust in their test results. That’s the real goal—not just automating for its own sake.