🐞 Manual Testing Lab

Manual Testing Lab: A bug report is like a police report — saying "something went wrong" is NOT enough; ANOTHER PERSON (a developer), looking at a screen you can't see, must be a

A bug report is like a police report — saying "something went wrong" is NOT enough; ANOTHER PERSON (a developer), looking at a screen you can't see, must be able to REPRODUCE the exact same failure using only what you wrote. Here's the real question: why is a title like "Login doesn't work" insufficient, but "Attempting login with an empty password shows 'Invalid email' instead" is enough? Because the first is a FEELING, the second is a REPRODUCTION RECIPE — it has steps, an expected result, and an actual result. This demands a completely different skill from writing code: the discipline of eliminating AMBIGUITY. If a developer can read your report and say "ah, I see the problem" without even opening the screen themselves, that report has done its job.

Manual Testing Lab — Bug Hunt

The login form below intentionally contains at least 5 different bugs. Try it with different inputs (empty password, invalid email, the "Forgot password" link, clicking Log In repeatedly), then write a structured bug report for each issue you find. The system automatically scores your report based on the title, repro steps, expected/actual result, and severity — and awards XP.

🎬 Why Is "Login Doesn't Work" Not Enough? The Chain of a Bug Report

"Login doesn't work"

Nothing Wrong on My Screen!

Steps + Expected + Actual

Understood Instantly, Fixed

When you find a bug, is saying "something went wrong" ENOUGH? This film watches why a bug report needs to be LIKE a police report — step by step, with evidence.

Step 1 — the tester FINDS an issue in the login form and writes the report: "Login doesn't work." This sentence describes a FEELING the tester SAW on their own screen — but carries NO CONCRETE information to the developer.

Step 2 (the contrast) — the developer reads the report, opens the login page on THEIR OWN screen, logs in with a normal password — EVERYTHING WORKS. "Nothing wrong on my screen!" they say, and CLOSE the report as "could not reproduce" — the bug is still there but stays INVISIBLE.

Step 3 (the fix) — the tester REWRITES the report: "STEPS: 1) Open the login page, 2) Leave the password field EMPTY, 3) Click Log In. EXPECTED: a 'Password required' warning. ACTUAL: the page silently reloads, no warning at all."

Step 4 — the developer reads this report and says "ah, the empty-password check is missing" WITHOUT EVEN OPENING THE SCREEN — because the report is no longer a FEELING, it's a REPRODUCTION RECIPE: exact steps, exact expectation, exact observation.

The lesson — writing a bug report is a COMPLETELY different skill from writing code: the discipline of eliminating AMBIGUITY. In the Manual Testing Lab below, write your own bug report and see how the system EVALUATES it.