Manual vs automated testing
Manual testing is a person operating the software and judging what they see; automated testing is a script operating the software and asserting on the result. Manual testing is cheap to start and expensive to repeat, and catches what nobody anticipated. Automated testing is expensive to start and cheap to repeat, and catches only what somebody wrote an assertion for. A test effort is split by that difference.
The longer version
The two differ in what they cost and when. A manual test costs a tester's time every time it runs, and nothing to create beyond writing the case. An automated test costs developer time to write and maintain, and close to nothing per run. So a check that will run once, or a few times, is cheaper by hand; a check that will run on every build for a year is cheaper as code. That is the arithmetic, and it decides most of the split before any question of skill or judgement is reached.
The second difference is what each can detect. A script checks the assertions it contains and is blind to everything else: a layout that has shifted, an error message that is now misleading, a flow that works but takes twice as long as it did. A person notices those without being told to and also misses things a script never would, such as a number that is wrong in the fourth decimal on every hundredth run. Automation is precise and narrow; manual testing is broad and inconsistent. The mistake in most comparisons is to treat automation as manual testing done better, when it is a different instrument that answers a different question.
All-manual teams repeat the same regression checklist every release until nobody running it is looking any more, and regressions ship through a checklist that passed. All-automation teams ship features that pass every assertion and confuse every user, because nobody with judgement operated the product before release. The working division gives repetition to automation, in particular regression and smoke checks, and judgement to people: new features, exploratory sessions, usability and acceptance. The boundary moves over time as manual findings become automated regression cases, which is the intended direction.
Common questions
When should a test be automated instead of run manually?
When it will run repeatedly on the same product with the same expected result, as regression and smoke checks do. Automate a manual case once it has stabilised and been run enough times to know it is worth keeping. Leave manual the checks that need judgement or that will run only a handful of times.
Which is better, manual or automated testing?
Neither is a version of the other. Automated testing is cheaper per run and precise about what it asserts; manual testing is cheaper to start and notices what no assertion covers. A team that picks one loses either the ability to regress safely or the ability to notice that a feature is wrong in a way nobody scripted.
Can automated testing replace manual testing completely?
A script checks only what somebody wrote it to check, so the judgements that no assertion captures, whether a screen makes sense, whether an edge case behaves reasonably, whether the product is ready, stay with people. Automation replaces the repetitive part of manual testing and leaves the investigative part, which then gets more of the tester's time.
What kinds of bugs does manual testing find that automation misses?
Anything without an assertion written for it: a layout that has shifted on a narrow viewport, an error message that is now misleading, a flow that works and takes far too many steps, a combination of inputs nobody anticipated, a feature that meets its criteria and still makes no sense. A person compares the product with expectations that were never written down, which is the whole of what a script cannot do.
What kinds of bugs does automated testing find that manual testing misses?
Small regressions in paths nobody visits by hand any more, a value wrong in a late decimal place, a check that has to run on every build and every browser in the matrix, and any failure that appears only on the hundredth identical repetition. A script never gets bored, never skips a step and never assumes the last build was fine, and those are exactly the conditions under which a tester stops looking.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.