Every Type of Manual Testing, Explained for 2026

Manual testing is software testing performed by a human — exercising the product the way a user would, watching for what a script wouldn't think to check. There are roughly 14 canonical types practising QA teams reach for: exploratory, smoke, sanity, regression, acceptance, ad-hoc, usability, accessibility, security, localisation, compatibility, performance, mobile, and beta. Each has a specific job, a moment in the release cycle where it earns its keep, and a different person who tends to run it. This guide walks through all fourteen — the vocabulary a QA lead is expected to have on their fingertips in 2026, regardless of how much of the suite has been automated.

Key takeaways

• Manual testing is not the opposite of automation — it covers the work automation can't do well, particularly judgement, real-user empathy, and ambiguity.
• Most teams use three to five types per release; the rest show up in audits, betas, or accessibility reviews.
• AI-assisted test generation has reduced scripted manual testing, but increased the value of exploratory and acceptance work.
• Confusion between smoke, sanity, and regression is the most common manual-testing vocabulary mistake on QA interviews.

---

TL;DR — the 14 manual testing types at a glance

---

What manual testing actually is in 2026

Manual testing is a human exercising the application and judging whether what it does matches what it should do. It sits opposite automated testing in mechanism, not in purpose — both exist to catch defects before users do. The line has shifted in one specific way in 2026: tools like Mabl, Testim, and Playwright with Copilot now generate functional tests from natural-language specs, which means the scripted manual test case is being absorbed into automation. What remains, and has grown more valuable, is the judgement-heavy modes that AI-generated tests miss. They cover what they were told to cover. They don't notice the empty state looks broken or that the success toast vanishes too fast to read.

---

1. Exploratory testing

Exploratory testing is unscripted, judgement-driven testing where the tester simultaneously designs and executes test cases as they learn the system. It is the type automation cannot meaningfully replicate. Run it any time the product has changed non-trivially — new feature, backend migration, redesigned flow — or when a bug has been reported but you cannot reproduce it. A QA engineer with product knowledge runs it, usually in a 60–120 minute session-based test management (SBTM) charter. Without a charter, testers drift into the same five flows.

Real example. A fintech team ships a "Pay a Friend" feature. The QA lead runs a 90-minute session on recipient selection, deliberately trying combinations the test plan didn't list — sending to a contact with no phone number, to a contact who has the app but isn't logged in, to themselves. Two uncover defects the scripted suite never would have hit.

---

2. Smoke testing

Smoke testing is a thin, fast check that the most critical paths still work after a new build. The term comes from hardware — power on the board, no smoke, test passed. The software equivalent: can a user log in, see the dashboard, and perform the headline action without the app crashing. Run it on every new build before deeper testing — if smoke fails, the build is rejected. Often a developer runs it before handoff, or QA in the first thirty minutes of the day, paired with an automated smoke suite.

Real example. A SaaS team deploys to staging every morning at 9am. The on-duty QA logs in with three account types (free, paid, admin), creates one record, opens one report, and confirms the Slack integration still shows connected. Five passes, deeper testing begins. Any fail, the build rolls back.

---

3. Sanity testing

Sanity testing is a narrow, targeted check that a specific fix actually works — and didn't break anything immediately adjacent. Where smoke covers the surface broadly, sanity drills into one spot. Run it after a hotfix, a small feature change, or a config tweak — it is the "I just changed this one thing, prove I didn't break it" mode. The QA engineer who reported the bug usually runs it; automation rarely pays off because each check is specific to its change.

Real example. Engineering ships a fix for "Forgot password" emails going to spam. Sanity testing verifies the email now lands in inbox for Gmail, Outlook, and ProtonMail, that the reset link works, and that the flow completes. It does not re-verify the rest of the auth system — that is regression's job. Sanity vs smoke is a frequent QA interview question: smoke checks the build is alive; sanity checks one specific fix works. Crosscheck has a longer breakdown of QA methodologies.

---

4. Regression testing

Regression testing is the verification that previously working functionality still works after new code has been introduced. It is the type most often partly automated — but the manual component remains, because automated suites struggle with visual changes, complex state, and anything that requires a human to say "that doesn't look right." Run it before every release and after dependency upgrades. Automated tests run on every commit; manual regression runs in the day or two before release, focused on flows the automated suite doesn't cover well — file uploads, payment flows, third-party integrations.

Real example. An e-commerce team prepares a release with a new saved-payment-methods step. Automated regression runs the existing 320-test suite. Manual regression covers guest checkout on a real card, Apple Pay on a real iPhone, the Klarna integration end-to-end, and the order confirmation email rendering in Outlook desktop. Each is too brittle to automate well, so a human runs it.

---

5. Acceptance testing (UAT)

User Acceptance Testing is the final verification that software meets the business requirements it was built for, performed from the perspective of the actual user or stakeholder. It answers "did we build the right thing," where regression answers "did we build the thing right." End users, stakeholders, or business analysts run it — not the QA engineers who tested it functionally — immediately before release. The point is a fresh, requirements-focused perspective, usually structured as a checklist tied to the original user stories.

Real example. A logistics company commissions a new dispatch dashboard. The vendor's QA verified everything works functionally; UAT is run by three actual dispatchers using the new dashboard for a full shift alongside the old one. Two flag that the priority ordering doesn't match how they triage routes — a requirements gap the QA team couldn't have caught, because they didn't know how a dispatcher's morning actually starts.

---

6. Ad-hoc testing

Ad-hoc testing is unscripted, unplanned testing without test cases or charters — pure intuition. It overlaps with exploratory but is even less structured: where exploratory has timeboxed sessions with charters, ad-hoc is "I have a feeling this is broken, let me poke at it." Anyone runs it — QA, developers, product managers, support engineers. It is one of the few modes where a non-QA perspective is an asset.

Real example. A support engineer notices three tickets in a week mentioning uploads are "slow." She spends an hour testing uploads across file sizes, file types, network conditions, and browsers. She finds that PDFs over 8MB on Safari take forty seconds where Chrome takes six. No test plan would have hit that combination.

---

7. Usability testing

Usability testing evaluates whether real users can accomplish their goals without confusion or excessive cognitive load. It is often confused with UX research, but the focus is narrower: can the user do the thing, not whether they like doing it. UX researchers run it in larger organisations; QA engineers borrow the playbook in smaller ones. The standard format is moderated sessions with five to eight participants — Jakob Nielsen's long-cited research suggests five users uncover roughly 85% of usability issues for a given task.

Real example. A B2B analytics tool launches "scheduled reports." Usability testing with six customers reveals that four try to schedule reports from the individual report page, but the feature lives in a global settings menu. The team moves the entry point and watches adoption double in two weeks.

---

8. Accessibility testing

Accessibility testing verifies that the product is usable by people with disabilities — including users of screen readers, keyboard-only navigation, magnification, voice control, and high-contrast modes. The reference standard is WCAG 2.2, published by the W3C in October 2023, and increasingly enforced by law: the European Accessibility Act took effect on June 28, 2025, requiring most consumer-facing digital products sold in the EU to meet accessibility standards. Ideally run by a specialist with assistive-tech experience; realistically, a QA engineer using Axe DevTools, WAVE, or Pa11y for the obvious issues, plus manual checks for what automation misses — focus order, screen-reader announcements on dynamic content, colour contrast in real lighting, keyboard traps in modals.

Real example. A government services portal runs an accessibility audit before public launch. Automated scans catch missing alt text and form labels. Manual testing with NVDA on Windows and VoiceOver on macOS catches that the multi-step form announces the wrong field as current focus after validation errors — invisible to sighted users, blocking for screen-reader users. For a tool-by-tool breakdown, see Crosscheck's accessibility testing tools guide.

---

9. Security testing (basic manual)

Manual security testing — distinct from full penetration testing — verifies that obvious security weaknesses aren't present. It is the layer between "the dev was careful" and "we paid a pentester." Run it before every release, with extra rigour after auth, session, or personal-data changes. A security-aware QA engineer runs it, working from OWASP Top 10-derived checklists — broken access control, injection, security misconfiguration.

Real example. A QA engineer testing a new "team workspaces" feature tries the basics: editing the URL to change the workspace ID, intercepting an API call in DevTools and modifying the role field from member to admin. The second one works. The bug ships as critical before public launch.

---

10. Localisation testing (L10n)

Localisation testing verifies the product behaves correctly when translated for a specific locale — language, currency, date format, calendar, number formatting, and culturally specific UX. It is distinct from internationalisation (i18n), the engineering work that makes localisation possible. Native-speaker QA engineers run it, or contracted localisation specialists. A common failure mode is letting bilingual engineers test their own translations — they catch grammar but miss tone, cultural fit, and layout breaks that happen when German strings run 30% longer than English.

Real example. A SaaS company localises onboarding into Japanese. The translation is technically correct, but native testers flag that the tone reads as inappropriately familiar in a business product, the email form rejects valid Japanese characters in the name field, and the date picker assumes Sunday is the start of the week (Japan uses Monday in business contexts). All three are caught manually.

---

11. Compatibility testing

Compatibility testing verifies the product works across the matrix of browsers, operating systems, devices, and screen sizes the user base actually uses. Modern teams pair cloud device labs (BrowserStack, Sauce Labs) with real hardware for the configurations that matter most. QA runs it against a documented support matrix — and the trick is keeping the matrix honest. Testing IE11 in 2026 wastes time; not testing the latest Safari on macOS does not.

Real example. A media site supports Chrome, Safari, Firefox, and Edge on desktop, plus iOS Safari and Android Chrome on mobile. After a CSS framework upgrade, manual testing reveals a hover-tooltip renders behind the navigation on iOS Safari only — a stacking-context bug visual regression flagged but couldn't categorise. QA files it as a release blocker.

---

12. Performance testing (manual checks)

Manual performance testing is not load testing — it is a human's perception of whether the app feels fast under realistic conditions. Load and stress testing run automated, but whether the app feels snappy on a real 4G connection with a mid-tier Android phone is a question a human still needs to answer. QA usually runs it with Chrome DevTools' Performance panel and network throttling.

Real example. A team ships a dashboard redesign. Synthetic monitoring shows median load time has improved by 200ms. But a QA engineer testing on throttled Fast 3G with 4x CPU throttling notices that time to interactive has gotten worse — a new analytics script is blocking the main thread. Manual performance testing catches what synthetic averages hid. Crosscheck has a Chrome DevTools performance auditing walkthrough for the working playbook.

---

13. Mobile testing

Mobile testing is its own discipline. The web tester's intuition does not transfer cleanly: mobile has to account for touch and gestures, screen rotation, app lifecycle states, permission prompts, push notifications, biometric auth, low-battery modes, offline behaviour, and a hardware matrix from five-year-old Android budgets to the latest iPhone. Mobile QA specialists run it with access to a representative device lab — cloud labs cover breadth, physical devices are still necessary for hardware sensors, biometrics, and carrier-specific behaviour.

Real example. A banking app ships a new biometric login flow. Manual testing on real hardware reveals that on Android with fingerprint unlock, if the user has only one finger registered and that finger is wet, the app crashes instead of falling back to passcode. The bug is essentially undetectable in an emulator; only physical-device testing surfaces it.

---

14. Beta testing

Beta testing is real-world use of a near-final build by a controlled group of external users before general availability. It sits at the intersection of UAT, exploratory, and product research — the explicit goal is to surface what no internal testing could. External users run it, recruited from customers, waitlists, or invitation programmes; product and QA coordinate feedback intake via a structured channel, since unstructured beta feedback is almost impossible to triage at volume.

Real example. A productivity startup runs a four-week closed beta with 200 users before launching a collaboration feature. Beta surfaces two issues nobody hit internally: @ mention autocomplete fails when a team has more than 500 members (no internal account had that many), and the cursor presence indicator caused performance issues on Chromebooks (no engineer was testing on Chromebooks). The biggest failure mode in beta programmes is friction-heavy feedback intake — if a user has to write a long email to report a bug, most won't.

---

Why manual testing isn't dying in the AI era

Every cycle of automation hype has predicted manual testing's demise. Selenium in 2010. Cypress and Playwright in 2018. AI-assisted test generation in 2024. None delivered.

What has happened is a redistribution. Scripted, repetitive manual testing — the kind that lived in spreadsheets and got executed identically every two weeks — has been substantially absorbed by automation. Mabl, Testim, Playwright with Copilot, and GitHub's experimental test-generation features can now produce functional regression tests from natural-language specs. That work was always the most automatable, and it is going away.

What has not gone away — and has grown more valuable — is the manual modes that require human judgement. Exploratory, usability, accessibility, and acceptance testing, plus the human-perception parts of performance, mobile, and compatibility, all share a trait: they require a tester to notice something feels wrong in a way the spec didn't predict. AI-generated tests cover what they were asked to cover. They do not have taste.

There is a second reason manual testing has stayed central: the bottleneck in modern delivery has shifted. Test execution speed has improved several-fold over the past decade, but bug reproduction and triage time has barely moved — engineering teams routinely lose more time understanding a reported bug than fixing it. The manual tester's role in that loop is no longer "executing test cases" but "delivering a clear, reproducible report fast enough that engineering can act before context decays." That is fundamentally human work. Crosscheck has more on where QA roles are heading, but the short version: the future of manual testing is judgement-heavy, automation-aware, and tightly coupled to the bug-reporting toolchain.

---

How to choose which types to run

No team runs all fourteen every sprint. A reasonable working rule:

• Every build: smoke.
• Every change: sanity on the affected area.
• Every release: regression (mostly automated), exploratory, basic security, performance gut-check.
• Every major release: acceptance, accessibility, compatibility, manual performance, mobile if applicable.
• Every market expansion: localisation. Every redesign: usability. Before GA: beta. Continuously, by anyone: ad-hoc.

Smaller teams collapse several of these — a single QA engineer might run smoke, sanity, regression, exploratory, and basic security in the same afternoon and call it "release testing." That is fine, as long as the team can name which mode they were in. Vocabulary matters because it tells engineering what confidence to attach to a "tested" status.

---

FAQ

What is the difference between manual testing and exploratory testing?

Exploratory testing is one type of manual testing. Manual also includes scripted modes — running a predefined test case — and structured modes like UAT and accessibility testing that follow a specific framework.

What is the difference between smoke testing and sanity testing?

Smoke is a broad, shallow check that the build works at all. Sanity is a narrow, deep check that one specific change works as intended. Smoke happens on every new build; sanity after a specific fix.

Is manual testing being replaced by automation in 2026?

The scripted, repetitive parts have been absorbed by automation and AI-assisted test generation. The judgement-heavy parts — exploratory, usability, accessibility, acceptance, beta — have not, and have grown in importance as bug-reproduction time has become the dominant constraint in software delivery.

What tools do manual testers use most in 2026?

For execution: real devices, browser DevTools, cloud device labs (BrowserStack, Sauce Labs), screen readers (NVDA, VoiceOver), accessibility scanners (Axe DevTools, WAVE, Pa11y). For reporting: a tool that captures screenshots, recordings, console logs, and network logs without forcing the tester to assemble them by hand.

---

Start reporting bugs faster

Most of the manual testing types in this guide end the same way: a tester finds a defect and has to communicate it well enough that engineering can act on it. That last step is where QA teams lose time — not in finding the bug, but in writing it up.

Crosscheck is a free Chrome extension built for exactly that step. One click captures the screenshot, screen recording, console logs, and network logs, then files a complete bug report straight into Jira, Linear, ClickUp, Slack, or GitHub. No paid tiers, no usage limits.

Try Crosscheck free