Manual Web Testing Workflow

Staging has a new checkout flow and the developer's verdict is "it works." Your automated smoke suite agrees — it was written against the old happy path and never extended. So the first useful thing you do that morning is walk the feature the way a customer would, and what you find there decides what gets automated next.

A user journey is a named goal with a start state, an ordered sequence of steps, and an end state you can point at: a row in the orders table, a message in an inbox, a line in the purchase history. The name matters because it makes the journey reviewable and reusable — "returning customer buys one item with a saved card", "guest applies a promo code and abandons at payment", "buyer resumes from the order email". If you cannot name what you are testing, you are clicking screens, not testing.

Write the journey down before you touch the browser:

Three details in that table do the real work. Start state: "cart with an item already in it" must be reproducible — cleared cookies, test account at a known balance, feature flag in a stated position — or your second run disagrees with your first and you waste an afternoon chasing a ghost. Observable expectations: "page looks right" is not an expectation; "subtotal shows 59.98" is, and it must be checkable in the DOM, a network response, a database row, or an email. Negative branches are journeys too: declined card, expired session mid-form, item that sells out between cart and payment.

Run the whole journey end to end before you investigate anything. When something looks wrong, the instinct is to stop and dig. Resist it for one complete pass. A journey is a story, and interrupting it means you never learn how it ends — the defect that blocks release is often three steps past the oddity that first caught your eye. Jot the wall-clock time and one line of description, keep walking, investigate after the pass. Timestamps are what let you correlate your notes with server logs and with the browser session you will reconstruct later in Testing with Browser DevTools.

Order the journeys by risk rather than by what is convenient. First the paths that move money or data: login, purchase, password reset, anything writing an order. Then the paths with history of defects — the checkout page has broken in the last three releases, so it goes early. Then the rare branches. A single journey of eight to twelve steps takes roughly ten to fifteen minutes when you are not composing prose mid-run, so a fifty-minute block comfortably covers three journeys plus triage.

When a journey fails, capture what you have and move on: the journey name, the step number, the timestamp, the observed result, and the expected result. That is already most of a defect report. The discipline of finishing the pass and timestamping as you go is what separates a manual session that produces filed defects from one that produces vague memories — the subject of Defect Metrics and Reporting. The next chapter turns the individual journey into a checklist another tester can run without asking you anything.

Two testers receive the same release candidate. One finds four defects; the other finds one, and the release ships with the three the second tester walked past. The difference was not skill — it was that neither had a checklist, so each tested the feature they personally remembered to test.

A structured checklist fixes that by making coverage explicit and shared. It is not the same object as a test case. A test case is one step with one expected result, precise enough to automate; a checklist is a set of areas and questions that guarantee both testers cover the same ground at the same depth. The checklist is the scaffolding; individual journeys and defect reports are built on it.

A checklist that works has four columns and one rule per line:

Checkout — release 2026.10  ·  tester: A.R.  ·  date: 2026-10-12
[ ] Guest checkout: email field accepts valid, rejects malformed, error is inline
[ ] Guest checkout: cart survives a page reload and a back-button click
[ ] Promo code: valid code applies; expired code shows expiry reason, not "invalid"
[ ] Promo code: removing a code restores the original subtotal to the penny
[ ] Payment: declined card leaves no order row in DB
[ ] Payment: double-click on Pay creates exactly one order
[ ] Confirmation: email arrives within 60s and matches the order total

The rule: every line is verifiable by looking at something. "Test the promo code" is untestable as written because two testers will read it differently; "removing a code restores the original subtotal" produces the same verdict from both. Keep lines atomic — one behavior per line — so a failure points at one place instead of a paragraph.

Three habits keep checklists honest across releases. First, run them in the written order: random order means the tester who is running out of time skips whatever happens to be last, and last items are usually the ones nobody has ever executed. Second, mark every line — checked, failed with a defect ID, or explicitly "N/A because feature flag is off". A blank line is ambiguous between "passed" and "never looked", which is exactly the ambiguity that lets regressions through. Third, carry forward: anything that failed last release becomes a permanent checklist line for at least the next three cycles, because fixed-once does not mean fixed-forever.

Feed the checklist from three sources: the change log (what touched this release), the defect history for this area (what has broken before), and the requirements (what the feature promises). Anything in none of the three is optional depth, not required coverage.

Shared checklists also make estimation possible. If the checkout checklist takes 35 minutes measured — not guessed — then a release touching checkout costs 35 minutes of manual verification, and you can argue credibly for automation of the lines that repeat every cycle. That argument is the bridge to Automation Concepts and Frameworks, but it is built from checklist data, not enthusiasm.

One warning: a checklist will never find what nobody wrote down. It guarantees consistency across testers and releases; it does not replace judgment about states the requirements never mention — empty carts, zero results, expired sessions. Those are hunted deliberately, in the next chapter, before any automation exists to give false comfort.

Automation written against a happy path has a structural blind spot: it only visits screens that contain something. Production visits the other screens constantly — forms nobody has filled in yet, lists with no results, sessions that expired while the tab was open. Those states are where manual passes earn their keep, and they are worth attacking with the same structure you give a journey.

Form validation deserves a pass of its own because it is a contract with a precise shape. For each field, work the contract in order:

1. Absent          — submit with the field untouched; is the requirement stated up front?
2. Malformed       — email "user@", phone "12A45", date "2026-13-45"
3. Boundary        — at the stated min/max length, one over the max
4. Valid-but-odd   — leading/trailing spaces, unicode name, value of only punctuation
5. Submission      — does the error sit next to the right field, in text, after submit?

Two questions decide pass or fail beyond the message itself: does the browser keep what you typed when validation fails (silent data loss is a defect even when the message is correct), and does the message say what to do — "Enter a valid email address" beats "Invalid input", and a server response of 422 with no visible message is a defect regardless of how good the client-side checks are. Paste a script or long string into a short field too; maxlength handling differs between typing, paste, and autofill more often than teams expect.

Error messages are tested by provoking the real failure, not by inspecting the happy path's message table. Turn off Wi-Fi and submit; let a session expire between two steps; use a card the gateway declines; make the API return 500 by hitting the feature flag endpoint. For each provoked failure ask four questions: is the message visible without opening devtools, is it specific enough to act on, does it avoid leaking internals (stack traces, SQL, connection strings), and does the UI recover — is the button re-enabled, the form still filled, the user not stuck on a spinner that will spin forever? A spinner that never resolves after a failed request is one of the most common manual finds and one of the least likely to appear in a happy-path script.

Empty states are the screens automation never loads: search with no results, an order history before the first order, an empty cart, a fresh workspace with no projects. Check each for four things. Does it render at all (an empty list sometimes renders an unstyled skeleton or throws a console error)? Does it explain what to do next with an actual action, not just "No data"? Do surrounding elements stay correct — does the total still show 0.00 rather than undefined, do pagination controls disappear instead of showing "page 1 of 0"? And can you get out of the empty state from the empty screen itself? The empty cart that offers no way back to the catalog is a dead end defect.

Record findings while the session is live with the timestamp, the journey and step number, observed versus expected, and one screenshot. That packet converts directly into a filed defect with no second session, and its quality is what Defect Metrics and Reporting counts. When the manual pass is done, you know which states are worth automating and which need one human with a browser — the setup for Testing with Browser DevTools.