Guide
A plain explanation of manual QA with examples: what testers do, the manual testing process step by step, when it still makes sense, and how it fits next to automation.
Updated 7 min read
Manual testing is when a person uses the product the way a customer would, step by step, and decides whether each step passed or failed. No script runs in the background. You click, you read, you compare what you see to what the spec says should happen.
That sounds obvious, but most teams still treat it as an afterthought. Someone runs a build, fires off a few happy-path clicks, and calls it done. Real manual QA is slower and more deliberate. You write cases first, execute them in order, log defects with evidence, and ship a report someone else can audit. See how to write a test case for the case structure most teams reuse.
A repeatable manual testing process keeps releases predictable. Most teams follow the same rhythm each sprint, even if tool names differ.
On a typical sprint, a manual tester imports or writes test cases, groups them by story or module, and executes them against a staging build. Each step gets a status: Pass, Fail, Blocked, or Skip. Failures become defects with screenshots attached. At the end, you export a summary for the team.
Automation is great for stable flows you will run hundreds of times. Login, checkout, API contracts. Manual work shines when judgment matters: does this error message make sense, is this animation distracting, does the whole flow feel broken even though the API returned 200.
Most mature teams use both. Automation guards the baseline. Manual testing catches the stuff scripts miss and validates releases before they go out.
Manual vs automated testing at a glance
| Dimension | Manual testing | Automated testing |
|---|---|---|
| Who runs it | Human tester | Script or CI job |
| Best for | New UI, exploratory checks, judgment calls | Stable flows run on every build |
| Cost per run | Higher per execution | Lower after initial setup |
| Evidence | Screenshots, notes, step status | Logs, assertions, screenshots on failure |
| When to start | Day one of a feature | After behavior stabilizes |
Pros
Cons
Pros
Cons
Picture a checkout change shipping Friday. You import twelve cases for cart, coupon, and payment. On staging you run them in order. Step 4 fails: coupon with a trailing space never applies. You log a defect with the screenshot, severity High, and link it to case CHECKOUT-03 step 4. Dev fixes it Monday. You retest the same steps on build 412 and close the defect. That is manual testing with a traceable example, not ad-hoc clicking.
9:00 — Import sprint cases from Excel into QA Workspace, grouped by story.
10:30 — Execute Auth and Checkout modules on staging build 408. Two steps fail.
11:00 — File defects with repro steps and screenshots from the failing steps.
14:00 — PM asks for a smoke summary. Export a PDF run report with pass/fail counts.
16:00 — New build 409 lands. Retest two resolved defects from the Tasks page.
The pain is usually tooling, not the work itself. Test cases live in one spreadsheet, defects in Jira, screenshots in a folder named "final_v3_really_final". QA Workspace keeps cases, runs, screenshots, and defects in one Chrome side panel, stored locally on your machine.
If you are starting from scratch, read how to write a test case, grab the free template, and import it straight into the extension.