Manual testing vs automation testing: what to automate and what to keep manual

One of the first questions teams ask when they start taking quality seriously is whether they should move to automation testing. The honest answer is that manual testing and automation testing do different jobs. A good software QA process uses both, and the skill is in deciding where each one belongs.

What manual testing is good at

Manual testing means a QA engineer uses the software the way a real user would, with judgement. That judgement is the point: a person notices that a button is confusing, that an error message does not help, or that a flow technically works but feels wrong.

• Exploratory testing of new features, where the expected behaviour is still settling
• Usability and visual checks that a script cannot judge
• One-off checks, such as a data migration or a configuration change
• Complex scenarios that would cost more to automate than to run a few times by hand

What automation testing is good at

Automated tests are code that checks the software. They are slower to write than a manual test is to run once, but after that they run in minutes, on every change, without getting tired or skipping steps.

• Regression testing: confirming that what worked yesterday still works today
• API testing, where requests and responses can be checked precisely
• Checks that must run on many browsers, devices or data sets
• Performance and load testing, which cannot be done by hand at all

How we decide what to automate

We ask three questions about each test case. Will it run many times? Is the expected result stable and clear? Would a failure here be expensive, such as a broken checkout, login or invoice? When the answer to all three is yes, the test is a strong candidate for automation. When the feature is still changing every sprint, we usually keep testing it manually until it settles.

Automate what must never break. Explore what has just been built.

Start with the critical paths

Teams that try to automate everything at once usually end up with a large, flaky suite that nobody trusts. We start with the handful of user journeys that make or lose money, automate those at the API and end-to-end level, and run them on every pull request. Coverage then grows sprint by sprint.

Tools we use

For browser automation we mostly use Playwright, with Cypress and Selenium where a project already uses them. API tests are written in Postman or directly in the test framework, load tests in JMeter or k6, and mobile tests with Appium. The tool matters less than the discipline: stable test data, clear ownership, and failures that are investigated the same day.

The short version

• Keep exploratory, usability and one-off checks manual
• Automate regression, API and cross-browser checks on critical paths
• Add automation gradually and fix flaky tests immediately
• Treat test code with the same care as product code