Hands on the Keyboard, Bugs on the Table
Today you stop learning about testing and start doing it — including the exercise that teaches the hardest lesson in this course: testing something once proves nothing.
- Run a functional sweep across buttons, forms, links and navigation
- Read HTTP status codes in the Network tab and know which ones are your problem
- Spot a silent failure — a page that looks perfect and is quietly broken
- Find a bug that was deliberately hidden from you
1. Functional testing, plainly
Functional testing asks one question of every single thing on a screen: does this do what it says it does? Does the button go where it claims? Does the search bar actually search? Does "Forgot Password" lead anywhere useful, or to a dead page? It is the most basic layer of testing and it is where essentially every testing job starts.
The method is boring and that is the point. You go left to right, top to bottom, and you touch everything. Testers who "have a feel for where bugs are" got that feel by first being systematic a few hundred times.
2. Status codes — the numbers that tell you the truth
Every request your browser sends comes back with a three-digit status code. You will see these for the rest of your career:
| Code | Means | What you do about it |
|---|---|---|
| 200 | OK / Success | Nothing. It worked. |
| 404 | Not Found | The page or file requested does not exist. Usually a broken link or a missing image. Report it. |
| 500 | Internal Server Error | Something broke on the backend. This is a real bug and it is worth reporting immediately. |
| 401 / 403 | Unauthorized / Forbidden | The user is not allowed here. Ask yourself whether that is actually correct — sometimes it is the bug. |
The move that makes you valuable: keep the Network tab open while you browse normally. When a page looks completely fine but you can see a 500 or a 404 quietly failing behind it, you have just found something no ordinary user would ever have reported. This is the difference between "I clicked around" and "I tested it".
3. The hidden bug — and why one click proves nothing
Real bugs are rarely waiting politely on the surface. The dangerous ones hide behind conditions:
- A Buy button that works perfectly the first 98 times and throws an error on the 99th.
- A form that accepts everything correctly except a name of exactly one character.
- A page that is flawless until the browser is narrower than a certain width, at which point a button slides behind another element and becomes unclickable.
- A feature that only fails when the connection is slow enough for two requests to overlap.
Nobody hands a tester a list of bugs to go confirm. You are handed a product and told: something in here is wrong. Find it. Today you are going to build exactly that situation for yourself — and you are going to build it with AI, which is the most useful thing AI does for a learning tester.
Make AI build you a broken app — then refuse to read the code
Every testing course has the same problem: to practise finding hidden bugs, somebody has to hide them for you. AI solves that permanently. From today you can generate an unlimited supply of practice targets, at any difficulty, in about thirty seconds — which is something testers five years ago simply could not do.
Paste this prompt exactly:
Build me a single-file HTML page (HTML, CSS and JavaScript all
in one file, no libraries, no internet needed) that works as a
small fake online shop called "PracticeMart".
It must have: a product list with 4 items, an "Add to cart"
button on each, a cart counter in the header, a quantity field,
a coupon code box, and a checkout form asking for full name,
email, phone number and delivery address.
Now plant exactly 4 BUGS in it, of these 4 different kinds:
1. One functional bug (something visibly does the wrong thing)
2. One edge-case bug that only appears after a repeated action
or at an exact boundary value
3. One responsive bug that only appears below 500px width
4. One silent bug that logs an error to the browser Console but
looks completely fine on screen
Rules:
- The page must look totally normal on a casual click-through.
- Do NOT tell me what the bugs are.
- Do NOT put comments in the code describing them.
- At the very end, output the answer key inside a code block
labelled ANSWER KEY that I will not scroll to until I am done.
Give me the full file, ready to save as practicemart.html.Now the discipline part. Save the file as practicemart.html, double-click it to open it in your browser, and do not read the source code. Reading the code is cheating and it teaches you nothing, because on a real job you will never have the code, the developer's notes, or an answer key. Hunt it like a black box: click everything, click things too many times, resize the window, empty every field, paste rubbish into every input, keep the Console open the whole time.
Only when you are certain you are done, scroll to the answer key and see how many of the four you caught. Most people get two on their first attempt. If you got three, you have a real aptitude for this. If you got four, generate a harder one with six bugs and do it again.
Hunt A — your generated app (30 min). Run the AI drill above. Write down every bug you find, in the order you found it, and note how you found it. Then check the answer key and write one honest line: what was your method — random clicking, or a system? The people who find the fourth bug almost always had a system.
Hunt B — a real live site (30 min). Pick a real website you did not build. Click through every visible button, link and form for half an hour with the Network tab open the entire time. Log at least three things that behaved unexpectedly — even small ones: a broken link, a form with no confirmation message, an image that never loads, a 404 firing in the background. Note which was easier to spot: the visible bug, or the silent one. That answer is the reason testers get paid.
Q1. What does a 500 status code usually mean?
Reveal the answer
Something broke on the backend or server side. Report it immediately — it is a genuine defect, not a user mistake.
Q2. A page looks perfect but the Console shows a red error and the Network tab shows a failed request. Is that a bug?
Reveal the answer
Yes — a silent failure. Something the page tried to do did not happen. It may be invisible today and cause missing data or a broken feature tomorrow. Report it with the exact error text and the failing request.
Q3. Why is clicking a button once and seeing it work not enough?
Reveal the answer
Because a large share of expensive bugs are conditional — they only appear on the Nth repeat, at an exact boundary, at a certain screen width, or when the network is slow. Testing something once only proves it can work, not that it does work.
- I generated PracticeMart and hunted it without reading the code
- I found at least two of the four planted bugs
- I logged three unexpected behaviours on a real live site