Manual testing: the complete guide

ll manual testing means is that a human interacts directly with software to check it works. There are no automation frameworks involved, just a tester, the product, and a list of things to check. This guide covers the types of manual testing, when to use each one, how to plan your sessions, and which tools help.

At a glance

• Manual testing is a human checking software directly: a tester, the product, and a list of things to check
• The main types: exploratory testing, regression testing, user acceptance testing (UAT), and smoke testing
• Manual wins where judgment matters: new features, user experience, and anything that changes too often to automate cheaply
• A checklist of test prompts usually beats detailed test cases: faster to write, and it covers more ground
• A useful test report shows what was tested, what passed and failed, any issues found, and who ran the tests

Most teams already do manual testing without calling it anything formal: if you've ever clicked through a new feature to see if it behaves as expected, you've done it. This guide is about doing it deliberately. (For a step-by-step intro, see how to get started with manual testing.)

What are the different types of manual testing?

Most of the testing your team does probably falls into one of four categories. Understanding the difference helps you use each one at the right time.

Exploratory testing

Exploratory testing is the most valuable kind of manual testing. James Bach describes it as performing tests while learning things that may influence the testing: testers interact with the product freely, inventing test ideas as they go, reacting to what they find, and following interesting leads. There's no rigid test case telling you exactly what to click, just a set of areas to investigate and a tester using their judgment to poke around.

This is where the bugs that automated checks miss tend to show up. Automation only catches what it's programmed to look for. A human tester will spot the thing that just feels wrong, or notice that two features interact in a way no one considered.

Regression testing

Regression testing checks that things which worked before still work now. Every time your team fixes a bug or ships a feature, there's a risk that something else breaks unnoticed. Regression tests are your safety net.

The common assumption is that regression testing has to be automated. Automating the stable, frequently-run checks is worth it, but a manual regression list has one advantage automation can't match: immediacy. The moment you fix a bug, you add a test for it, and that test protects the very next release with no automation project to wait for. In Testpad, you start with a handful of prompts and add a line every time you fix a bug. The list builds itself over time.

User acceptance testing (UAT)

UAT verifies that software does what it was supposed to do for the people it was built for. In client projects, that usually means the client checking the product before signing off. For product teams, it means testing against real user scenarios.

UAT doesn't require an elaborate setup. It requires clear test scenarios and a straightforward way for testers or clients to record what they find. Testpad's guest access lets clients log results without needing an account; you just give them a link.

Smoke and sanity testing

Before investing time in detailed testing, it's worth checking that the basics work. Can you log in? Does the main page load? If the answer is no, there's no point running anything else yet.

Smoke testing and sanity testing mean essentially the same thing (the ISTQB glossary lists them as synonyms): a quick check of the main functionality before planned testing begins. A short checklist of critical paths, run in a few minutes at the start of each session, is enough.

When does manual testing outperform automation?

The short answer: more often than most teams expect.

Automation is good at repetitive checks. It can run the same test a thousand times and never get tired. But it can only test what it's been explicitly told to look for. It has no intuition, no curiosity, and no ability to notice that something feels off even if it technically passes.

Manual testing is the better choice when:

• You're testing something new and don't yet know what "correct" looks like
• The interface or user experience is what's being evaluated
• You're doing exploratory work to understand the product's real state
• The feature changes often, making automation expensive to maintain
• You need a human to verify something works in context, not just technically

The two approaches work together rather than compete. Even Google's DORA research, which makes the case for automating your regression suite, recommends that teams keep doing exploratory, usability, and acceptance testing manually throughout delivery. And if the question on your mind is AI rather than automation, we take that one on in why manual testing matters.

How do you plan manual testing effectively?

A test plan for manual testing is essentially a list of things to check. The goal is to capture enough detail that testers know what areas to cover, without prescribing exactly how to test each one.

The most practical format is a checklist of test prompts: short, specific ideas that direct a tester's attention without turning testing into a box-checking exercise. "Check password complexity rules" is a better test prompt than either "test login" (too vague) or a five-step test case with expected outputs (too rigid).

Good test plans:

• Use prompts rather than step-by-step instructions
• Group related tests together in a hierarchy
• Go into more detail in risky or complex areas
• Evolve over time as you find and fix new issues

Checklists or test cases: which should you use?

Test cases are detailed: steps, expected outcomes, preconditions. Checklists are lightweight: a list of things to investigate. Neither is universally better.

Use test cases when you need a record of exactly what steps were performed, or when you're testing something with precise compliance requirements. Use checklists when you're moving fast, testing exploratively, or working with testers who know the product well enough not to need hand-holding.

Most teams default to test cases out of habit rather than necessity. For the majority of manual testing, a well-written checklist covers more ground in less time.

How do you track and report on manual testing?

Testing without records isn't testing; it's hoping. Even a simple pass/fail note against each test prompt tells you something useful: what was checked, what worked, and what didn't.

Good manual test reporting doesn't need a lengthy summary document after the fact. A shared report that shows where testing has got to whenever someone looks beats any post-mortem write-up. Stakeholders can check progress for themselves, and issues surface during testing rather than days later.

What a test report needs to show:

• What was tested
• What passed and what failed
• Any issues or comments captured during testing
• Who ran the tests and when

That's it. The rest is optional. Testpad's Report view shows exactly this: a grid of pass/fail results against every test, with comments and issue numbers captured inline, shareable with stakeholders as a link.

What tools do manual testers need?

Manual testing doesn't really need much. A way to record what you're going to test, a way to capture results, and a way to share findings with the rest of the team.

Most teams start in spreadsheets. They work for simple setups, but they get unwieldy as test plans grow and teams need to track results across multiple releases or testers. Managing multiple test runs, filtering by environment, and sharing progress all require workarounds that waste time.

The traditional alternative is heavyweight test case management tools: formal, database-centric, and designed for teams with dedicated QA departments. For many teams, they're more process than necessary.

Tools like Testpad sit in the middle: a checklist-based approach that maps directly to how manual testing actually works. You have a list of things to check, you work through them, you mark pass or fail, and you capture any issues as you go. Anyone on the team can join as a guest tester without needing an account.

Key things to look for in a manual testing tool:

• Quick to write and edit test prompts
• Clear visual progress tracking
• Easy to share results with stakeholders
• Support for guest testers (for UAT or outsourced testing)
• Reusable tests across releases

Make manual testing a habit with Testpad

Manual testing works best when it becomes a habit rather than a last-minute scramble. Start with the things most likely to break, build up your test prompts over time, and share results as you go.

If you want a tool that makes all of that easier without adding process for the sake of it, try Testpad free for 30 days.

If you liked this article, consider sharing