Automated tests verify: "does this button click, does this form submit, does this API return 200?" They don't notice that an error message is grammatically correct but would make no sense to a non-technical customer, or that a new feature conflicts with a workflow three screens earlier. That gap is what manual testing covers, and it's why organizations pursuing automation are discovering it expands their testing scope rather than replacing the humans doing it.

What manual testing actually is

Manual testing is a human tester interacting with software to find defects, verify behavior, and assess quality, without relying on automated scripts to drive the interactions.

That definition sounds simple, but it covers a wide range of activities: running a predefined test case step by step, exploring a new feature with no script at all, assessing whether an interface makes sense to use, or comparing a finished feature against the original requirement to check if they match.

The "manual" in manual testing doesn't mean slow or low-quality. It means human judgment is doing work that no script can replace.

Why automation doesn't make manual testing obsolete

Automated tests check what you tell them to check. They verify: "does this button click, does this form submit, does this API return 200?" They do this reliably and quickly, thousands of times.

What automated tests can't do: notice that a button is technically clickable but positioned in a way that confuses users. Notice that the error message is grammatically correct but would make no sense to a non-technical customer. Notice that a new feature, while working correctly, conflicts with a workflow three screens earlier in a way nobody anticipated.

Human testers notice these things. Not because humans are better than computers at checking assertions (they're not), but because humans bring context, experience, and the ability to ask "does this actually make sense?" that no test script can replicate.

The Capgemini World Quality Report 2025-26 reports that 89% of organizations are pursuing AI and automation in quality engineering. The same report notes that most of them are discovering automation is expanding testing scope, not replacing the humans doing it.

The types of manual testing

Functional testing verifies that features work as specified. Login authenticates users, the cart calculates totals correctly, the export generates the right file format. This is the most commonly automated category, but manual execution still makes sense for new features before automation is built. Exploratory testing is the most distinctly human activity in QA. The tester simultaneously learns the system, designs tests based on what they find, and executes those tests, all in real time. There's no script. The tester follows their instincts, their experience, and their curiosity. This is where experienced testers find bugs that automation never would, because nobody thought to write a test for that specific sequence of events. Usability testing checks whether the software is intuitive and efficient to use. Can a new user complete the main flow without instruction? Are error messages clear? Does the layout make sense? Automation can verify that elements exist; it can't tell you if the product is pleasant to use. Regression testing verifies that existing features still work after changes. This is the category most suitable for automation: repetitive, well-defined, stable. Manual regression testing is still done in organizations without automation, and as a spot-check even in those with full automation. Acceptance testing confirms that the delivered software meets the requirements agreed upon with stakeholders. This is often done manually by a product owner or QA lead, comparing the actual product against the original specification or user story.

How manual testing fits in modern Agile teams

The old model: development sprints, then a "testing phase" where QA verifies everything manually before release. This doesn't work anymore. The testing phase becomes a bottleneck and teams can't release frequently enough.

The modern model: QA is involved from the beginning of a sprint, not the end.

During planning: QA reviews the feature specification and identifies ambiguities. "What happens if the user uploads a file that exceeds the size limit?" is a question worth asking before development starts, not after.

During development: developers write unit tests for their own code. QA writes test cases and can start automated tests against API endpoints as soon as they exist, before the UI is built.

During testing: new features get manual exploratory testing, where a QA engineer spends 30-60 minutes trying to break the feature in unexpected ways. Regression coverage comes from the automated suite.

After release: monitoring and production testing to catch issues that only appear at scale or with real user data.

"Shift-left testing" means moving testing activities earlier in the development process. In practice, this means QA being present in planning meetings, writing test cases from requirements, and providing feedback before code is written, not just after it's done.

What manual testing looks like in practice

Here's what a manual exploratory testing session on lab.becomeqa.com looks like:

You log in and navigate to the travel items table. The automated tests verify that items load and display correctly. Your job as a manual tester is to look for what the automated tests missed.

You try: sorting the table by different columns, then adding a new item and checking if it appears in the right sorted position. You try editing an item while the table is filtered. You try rapidly clicking the delete button twice to see if double-submission is handled. You try navigating away mid-edit and coming back to see if unsaved changes are preserved or discarded. You try opening the add-item modal, filling half the form, closing it, and opening it again to check if the previous data persists.

None of these are likely in the automated regression suite. All of them are things a real user might do.

The skills that matter for manual testing

Requirements analysis. Can you read a user story and identify what's underspecified? "As a user, I can filter items by status." Does that mean single-select or multi-select? What happens if no items match the filter? Test case design. Equivalence partitioning, boundary value analysis, decision tables, state transition testing: these techniques let you cover more ground with fewer test cases. They're not just for automation. Bug reporting. A bug report that gets fixed immediately vs one that gets kicked back for "cannot reproduce" is entirely about quality of the report: reproducible steps, clear expected vs actual behavior, the right environment details. Communication. Manual testers talk to developers, product owners, and stakeholders constantly. The ability to explain a bug, assess its severity accurately, and advocate for fixing it before release is a core skill. Exploratory testing technique. Knowing how to structure an exploratory session (using charters, taking notes, managing time) separates productive exploration from random clicking.
The best manual testers are mentally modeling the application while they test, building a map of how the system works, where the boundaries are, and where the risky intersections are. That mental model is what guides where to look next.

FAQ

Is manual testing a dead-end career?

No. Pure manual testing roles are becoming rarer, but manual testing as a skill is more valuable than ever, integrated into the work of QA engineers who also automate. The engineers who understand how to test well, not just how to write scripts, are the ones who build test suites that actually catch bugs.

Do I need to learn to code if I'm doing manual testing?

Not necessarily, but knowing enough SQL to query the database, enough JavaScript to read test output, and enough HTTP to use Postman opens significantly more doors. You don't need to be a developer, but technical literacy helps.

How do I show manual testing skills in a portfolio?

Document your testing process: write sample bug reports, create test plans for a feature you've tested, record an exploratory testing session and annotate what you were looking for and why. A thoughtful bug report is more impressive than many hiring managers expect.

What's the difference between QA and testing?

Testing finds defects. QA (Quality Assurance) is broader. It encompasses the processes, standards, and practices that prevent defects from being introduced in the first place. A QA engineer tests, but also reviews requirements, participates in design, and influences how software is built. The distinction matters in practice: a tester focused only on finding bugs is doing less than a QA engineer who helps prevent them.

→ See also: How to Write a Test Case: Format, Examples, and Common Mistakes | The Anatomy of a Bug Report That Developers Actually Fix