Manual testing
Manual testing is software testing performed by a person who operates the product directly, following test cases or exploring freely, and judges the result with their own eyes rather than through a script. The tester clicks, types, reads and compares what happened with what was expected, and files a bug when the two differ. No test code runs; the person is the test harness.
The longer version
A manual test session starts from a test case, a checklist or a charter, and proceeds through the product as a user would. The tester follows the steps, watches for the expected result, and also notices what the case never asked about: a delay, a misaligned label, an error message that makes no sense, a flow that works but feels wrong. That second kind of observation is the reason manual testing exists. A script checks what it was told to check; a person checks that too and also notices what the author of the check did not anticipate.
Manual testing is set against automated testing, where a script drives the product and asserts on the result, and the confusion is to treat manual as the primitive version of automated. The two test different things: a script repeats a known check identically on every build, a person judges whether a new screen is usable or an edge case the spec forgot behaves sensibly. The full comparison is under manual vs automated testing. Two other neighbours sit inside manual testing: exploratory testing, where the tester designs the next check from the result of the last one rather than from a script, and user acceptance testing, which is manual testing done by the people who will live with the product.
Manual testing breaks down under repetition and under vagueness. Repeating the same regression checklist on every release is where testers stop looking and start ticking, and the checklist passes while the product regresses; that work belongs in automation. Vagueness is the other failure: a manual test with no expected result written down produces a pass that means the tester was not surprised, which is not the same as correct. The output of manual testing is the bug report, and its quality is the whole value of the session: a defect noticed but reported without the steps, the browser and a screenshot costs the developer the reproduction the tester already did once.
Common questions
What is the difference between manual testing and exploratory testing?
Exploratory testing is one form of manual testing. In scripted manual testing the tester follows written cases with expected results and reports where the product departs from them. In exploratory testing the tester designs each check from what the last one revealed, guided by a charter rather than a script, and writes the cases down afterwards if at all. Both are done by a person; they differ in whether the plan exists before the session.
Is manual testing still needed?
A script can only check what somebody wrote it to check. Whether a new screen makes sense, whether an unexpected combination of inputs behaves reasonably, and whether the product feels finished are judgements a person makes. Manual testing shrinks as regression checks move to automation, and it stays where judgement is the point.
What skills does a manual tester need?
Attention, a habit of asking what happens if, and the discipline to write a bug report somebody else can act on: steps, expected result, actual result, environment and evidence. Knowledge of the product's users matters more than knowledge of its code. Familiarity with browser developer tools shortens the path from symptom to report.
How is manual testing documented?
Scripted sessions run from written test cases, each with preconditions, steps and an expected result, and the tester records pass or fail against each one. Exploratory sessions produce a charter beforehand and session notes afterwards listing what was covered and what looked wrong. In both forms the bug report is the output that matters, and a defect noticed but not filed with steps and evidence is work lost.
When is manual testing done in a release cycle?
As each feature reaches a build a tester can use, so that findings return while the developer still has the change in mind; then in an exploratory pass over the release candidate, where the tester looks for what the cases never asked; then as acceptance by the people who requested the work, on a staging environment. Repeated regression checks are the part that moves to automation over time.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.