Skip to main content
Handbook/Test/Chapter 77 · Manual QA

The Human Pass

Share

Share this page

Pass it to someone who needs it.

Key takeaway: Some bugs only a human will find

Your automated tests are green and you trust them, but they only ever check what you thought to check. A confusing label, a broken layout on a phone, a flow that technically works but feels wrong: a machine sails past all of it. This chapter gets you the human pass that catches what no assertion can.

8.8.1Automated tests miss the human bugs

A test only ever checks a case you thought of in advance. You wrote it, or your agent did, to confirm the thing you already pictured. It cannot flag the case that never crossed your mind.

It also never asks the question a person asks without trying: does this feel right? A form can submit, save, and pass every check while its button sits in a place no one would look. That whole class of bug, ugly, confusing, awkward, working but wrong, is human-only.

8.8.2Explore, don't just follow a script

Exploratory testing is poking at your app like a curious or careless user with no script in hand. You deliberately leave the path you designed and see what breaks.

The moves that find bugs are the ones a tidy user never makes:

  • click things in the wrong order
  • submit the empty form, then the same one twice
  • hit the back button in the middle of a flow
  • resize the window small, then tiny
  • paste an essay into a field built for a name

Spend ten unhurried minutes doing the weird thing. That is where the bugs no test imagined are hiding.

8.8.3Keep a release checklist

Before every ship, walk one short list by hand, on a real device. Not the desktop browser shrunk narrow, an actual phone, because that is where layout and touch bugs live. The same list every time turns into muscle memory:

Release checklist (walk before every ship) [ ] Log in and log out [ ] Complete the one core flow end to end [ ] Do all of it once on a real phone [ ] Empty state: a brand-new account with no data [ ] Error state: submit a form with fields left blank [ ] Wrong input: bad email, huge number, pasted text [ ] Hit back and refresh mid-flow, nothing breaks [ ] Read every label out loud, does it make sense

Keep it to what would embarrass you if it shipped broken. A list you actually finish beats a long one you skip.

8.8.4Write a bug report your agent can fix

When the human pass finds something, how you write it up decides whether the agent fixes it in one round or three. A vague "the signup is broken" forces the agent to guess and re-ask. A reproducible report, the exact steps plus what should happen and what did, gets it fixed on the first try.

Fill in the same four parts every time:

Title: one line, what is wrong Steps to reproduce: 1. Go to ... 2. Click ... 3. Type ... and submit Expected: what should have happened Actual: what happened instead Environment: device, browser, phone or desktop

Hand your app to a senior QA engineer and let them build both artifacts around your specifics:

Ready prompt
Act as a senior QA engineer reviewing my app before release. Do three things. 1. Write a short manual release checklist tailored to my app: the core flow, empty and error states, wrong input, and a real-phone pass. Keep it to what would hurt if it shipped broken. 2. Give me a reusable bug-report template with steps, expected, actual, and environment. 3. List the exploratory edge cases most worth trying by hand for this app: the weird orders, bad inputs, and interrupted flows a careless user would hit. My app:

Do this now: paste the prompt, then walk your app's release checklist by hand on a real phone before your next ship.

Mahmoud Zalt

Mahmoud Zalt

Software engineer, 16+ yrs · built Sistava.com in 3 months, idea to production, using these methods

Resources
Contribute
Donate

Support my work

A small tip keeps the free work coming.

© 2026 Mahmoud Zalt. Free to read, not to republish.
Copyright & license