Manual Versus Automated Testing

Manual versus automated testing is often framed as if one should replace the other. In practice, strong teams need both.

“Use the robots for what the robots are good at: repeatable, fast, automated checks. Use people for the judgement, context, and curiosity that automation cannot replace.”

Automation is excellent for repeatability. It is what gives teams fast feedback on critical user journeys, APIs, regressions, and deployment confidence. If something needs to be checked frequently and the expected result is clear, it is probably a good candidate for automation.

Manual testing matters for different reasons. Good QA testers are often among the people who know a product best, because they spend so much time moving through its workflows, edge cases, and failure points. That makes manual testing especially valuable for uncovering awkward behaviour, usability issues, and the kinds of quality problems that are hard to reduce to a script. Human judgement still matters, especially when a feature is new, complex, or still evolving.

One of the mistakes I’ve seen many teams make is assuming everything should be automated. Quite often that view comes from founders or other non-technical stakeholders, and that's usually not a problem of intent so much as a gap in understanding. It's often a great opportunity to explain that effective automation is about value, confidence, and maintainability, not automating every possible check for the sake of it.

Some checks are too brittle, too expensive to maintain, too low-value, or too dependent on human interpretation to justify the effort. Automating the wrong things creates noise, slows teams down, and gives a false sense of coverage.

The goal for me is not maximum automation. The goal is the right balance.

Good quality strategies use automation to protect the product and give confidence in new deployments, and manual testing to understand it. When those two approaches work together, teams move faster and with more confidence.