Manual Testing: How to Fill the Gaps in Your QA Strategy

Manual testing fills gaps that automated checks are poorly suited to find: confusing interactions, ambiguous requirements, unexpected user behavior, and visual or usability problems that need human judgment. Use it alongside automation. Automate stable checks that need frequent repetition; focus human testing on discovery, judgment, and high-risk changes.

Build the strategy around critical user and business workflows, then choose the test method that best addresses each risk. A larger test suite is not automatically better if it slows feedback or adds maintenance without improving confidence. Microsoft’s guidance is to align test types with critical scenarios and risks.

1. Decide where manual testing adds value

Manual testing is most useful when the question is difficult to specify in advance or when the answer depends on a person’s interpretation. It is especially valuable during early development, UI changes, and work where automation is not yet feasible. It costs more per execution and scales less easily than automation, so reserve it for cases where human insight matters.

Situation	What a person can assess	Useful approach
A new checkout flow whose wording or recovery behavior is changing	Whether the next step is understandable and a declined payment is recoverable	Exploratory session with a focused charter
A form with multiple states and unclear acceptance details	Whether errors, help, and state changes make sense to users	Exploration plus a short checklist of known risks
A visual redesign	Hierarchy, readability, layout, and whether the page feels coherent	Manual review across relevant devices and states
A stable, frequently repeated business rule	Usually little judgment is needed once expected behavior is clear	Automated unit, integration, or end-to-end regression check
A workflow with high business impact and uncertain edge cases	Whether unusual combinations expose a failure the scripted cases missed	Risk-focused exploration, followed by automation for stable discoveries

Manual review can reveal accessibility concerns, but a human pass by itself does not establish accessibility or compliance. Use appropriate accessibility checks and expertise for those goals.

2. Choose a manual testing technique deliberately

Manual testing is not one technique. The ISTQB Foundation Level syllabus describes checklist-based testing, error guessing, and exploratory testing as experience-based techniques. Each is useful for a different knowledge and risk condition. ASTQB’s syllabus explanation provides the underlying definitions.

Exploratory testing

Exploration combines learning, test design, execution, and evaluation. ISTQB describes it this way: “In exploratory testing, tests are simultaneously designed, executed, and evaluated while the tester learns about the test object.” Use it when learning about a feature may reveal new conditions or when requirements leave meaningful questions open.

Give the session a charter so discovery stays connected to a risk. For example: “Can a returning customer recover from a declined payment without losing the cart?” Record the user, risk, environment, time available, and what you discover. A charter guides investigation without pretending to enumerate every possible test.

Checklist-based testing

Use a concise checklist for important conditions that should receive consistent attention. Base it on user needs, product experience, and known failure patterns. For a checkout, that might include an empty cart, an invalid address, a declined payment, a retry, and a confirmation that survives a page refresh. A checklist is a prompt, not a substitute for investigating unexpected behavior.

Keep checklist items focused on conditions that need human attention. The syllabus advises against checklist items that can be checked automatically or belong in entry and exit criteria.

Error guessing

Use knowledge of the product, past defects, common implementation mistakes, and similar applications to probe likely weaknesses. Vary inputs, outputs, logic, interfaces, and data. Examples include submitting a form twice, refreshing during a save, using a long name, or navigating backward after a payment step.

Error guessing depends on the tester’s experience. Record what you tried and the context so another person can understand the result; do not present an intuition-led pass as exhaustive coverage.

3. Build a risk-based mix of manual and automated checks

Start from workflows and potential consequences rather than a target number of tests. A useful plan asks which failures would block users or harm an important business outcome, how likely they are, and which method can detect them with useful feedback.

Decision factor	Manual testing is a strong fit when…	Automation is a strong fit when…
Human judgment	The result involves visual hierarchy, confusing copy, nuanced interaction, or open-ended expectations	The expected outcome can be expressed clearly as a repeatable assertion
Repeatability	The test is a one-off investigation or its steps are still changing	The same stable check must run often
Interface and behavior stability	Design and requirements are moving, making scripts costly to maintain	The behavior and selectors are stable enough to support dependable checks
Risk and workflow criticality	Exploration is needed to discover unknown failure paths	Known high-impact paths need consistent regression coverage
Feedback and maintenance cost	A human session can answer an important question faster than building a brittle test	Repeated execution saves time and the suite gives timely, meaningful feedback

Unit tests check components in isolation, integration tests check interactions, and end-to-end tests cover complete journeys. The testing pyramid helps organize layers of automation; it does not prove that every user-facing risk is covered. More tests can increase pipeline time and cost. Prefer a smaller set that protects critical workflows and gives the team confidence to make changes.

When exploration uncovers a recurring failure condition and expected behavior becomes stable, consider adding a regression check. That is a practical way to convert learning into repeatable protection, while reviewing whether the check remains worth its maintenance cost.

4. Run a focused manual test session

1. Name the risk. Pick a critical workflow or an uncertainty worth investigating. State who is affected and what a failure would mean.
2. Choose the method. Use a charter for open-ended learning, a checklist for known conditions, and error guessing to probe likely weak spots.
3. Set the scope. Specify the build, browser or device, account or test data, relevant configuration, time limit, and any setup assumptions.
4. Exercise realistic and unusual paths. Follow the expected journey, then vary inputs, timing, navigation, and state where those variations relate to the risk.
5. Capture evidence as you go. Note the steps, expected result, observed result, and enough context to reproduce the behavior. Add a screenshot or recording when it clarifies a visual or timing issue.
6. Decide what happens next. File actionable defects, update relevant checks, and identify stable, repeatable discoveries that may warrant automation.

For release testing, define scope, test cases or charters, timing, ownership, and entry and exit criteria. Keep the plan proportional to release risk and aligned with business objectives. Microsoft’s testing guidance describes these as elements a release test plan can cover.

5. Record defects so another person can reproduce them

A useful manual test record identifies what was tested, under which conditions, and what happened. Include the relevant details rather than relying on “it didn’t work.”

• Build or version, date, and environment.
• Browser, device, viewport, and relevant account or test data.
• Setup and steps, or exploratory charter and session notes.
• Expected behavior and the observed result.
• How often it occurred and whether it is reproducible.
• Screenshot, recording, or other diagnostic evidence when it helps explain the failure.

Link the report to the affected requirement, workflow, or build when your test-management process supports it. Azure Test Plans is one documented example: it supports planned manual tests, exploratory sessions, feedback, traceability, and diagnostics such as screenshots and screen recordings. These are Azure product capabilities, not requirements for every testing tool. See Microsoft’s Azure Test Plans overview.

6. Capture screenshots for visual review and defect evidence

A screenshot can make a layout defect, unexpected state, or confusing interaction easier to review. For a small, repeatable capture task, a browser automation script can open a page and save an image. The following Playwright example uses Node.js and captures a full page at a fixed viewport.

import { chromium } from 'playwright';

const browser = await chromium.launch({ headless: true });
const page = await browser.newPage({
  viewport: { width: 1440, height: 900 },
});

try {
  await page.goto('https://example.com', { waitUntil: 'networkidle' });
  await page.screenshot({ path: 'page.png', fullPage: true });
} finally {
  await browser.close();
}

Install Playwright in a Node.js project with npm install playwright, then run the file with Node.js. Use a page and test account you are authorized to access. Choose a deterministic test environment where possible; network-idle can be unsuitable for pages with persistent connections or background requests. In that case, wait for a specific element or use a deliberate short delay after the relevant state appears. A screenshot records pixels at a point in time; it does not determine whether a page is usable or whether a visual difference is a defect.

Capture the same page with ScreenshotNeo

For a screenshot without managing a browser instance, ScreenshotNeo accepts a URL in one GET request and returns an image or PDF. Its options include full-page capture with lazy images loaded, element capture by CSS selector, dark mode, 12 device presets or a custom viewport, and retina scale. Custom CSS and JavaScript, click-before-capture, selector hiding, wait conditions, request blocking, headers, cookies, user agent, timezone, and geolocation can help reproduce a visual state. See the ScreenshotNeo API documentation for request parameters.

7. Or skip the browser setup

Make a screenshot request with cURL:

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o shot.webp

The same request in Python:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

Or in Node.js:

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://stripe.com',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

These examples use the documented endpoint and parameters; replace the target URL with a page you are authorized to capture. ScreenshotNeo accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each of those steps can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers identify the page verdict and billing status. An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots. Sign up for the free plan.

8. Troubleshoot common manual testing problems

Problem	Likely cause	What to do
A defect report cannot be reproduced	Missing build, environment, account state, data, or steps	Add the version, setup, browser or device, exact steps, and expected versus observed behavior. Ask the reporter for missing context.
Exploratory sessions wander without useful findings	The session has no risk, question, or time boundary	Write a focused charter, name the affected user and environment, and record discoveries against that question.
A checklist creates false confidence	It covers known conditions but is treated as proof that unknown paths are safe	Keep checklist checks for repeatable known risks and reserve time for exploration of changing or ambiguous behavior.
Manual release testing takes too long	Low-risk routine checks are repeated by hand, or scope is not prioritized	Prioritize critical workflows. Automate stable, frequently repeated checks when the maintenance cost is justified.
Automated UI checks break after ordinary design changes	The interface or selectors are changing, or the check depends on brittle details	Review whether the behavior is stable, use resilient selectors, and retain human review for questions that still need judgment.
A screenshot differs between runs	Dynamic content, animation, timing, viewport, data, or environment changed	Fix the viewport and test data, wait for the relevant state, and control or account for dynamic content before comparing images.
A browser capture waits indefinitely for network idle	The page keeps connections or background requests open	Wait for a specific selector or state instead of network idle, and close the browser in a finally block.

9. Improve the strategy over time

Review manual and automated coverage when workflows, interfaces, risks, or maintenance costs change. Ask which manual sessions repeatedly find valuable issues, which stable checks are unnecessarily repeated by people, and which automated checks create delay without useful confidence. Update the risk priorities and move checks between methods when the evidence warrants it.

For teams developing a formal automation approach, ISTQB’s Test Automation Strategy qualification covers viability, investment, metrics, costs and risks, and transition activities. See the ISTQB qualification outline.

10. Frequently asked questions

When should I use manual testing instead of automation?

Use manual testing when the question needs human judgment, requirements or interfaces are changing, or exploration may reveal conditions you did not know to script. Automate stable checks that need frequent repetition when the value exceeds their build and maintenance cost.

What should still be tested manually?

Keep human review for usability nuance, ambiguous journeys, visual hierarchy, and discovery around high-risk changes. The exact mix depends on the product and its critical workflows.

Does manual testing mean there should be no test cases?

No. Manual work can use scripted cases, checklists, focused exploratory charters, or error guessing. Choose the structure that fits how much is already known about the risk.

Does a screenshot prove a page is correct?

No. It provides visual evidence of a particular page state and can help someone review or reproduce an observation. It does not establish that the experience is usable, accessible, or functionally correct.

How do I know whether a discovery should become an automated test?

Consider automation when the condition recurs, expected behavior is stable, the check can run reliably, and repeated execution is worth the maintenance effort.