Software testing practice for beginners: a path through five exercises

Updated November 2, 2026

Every session on this site plants a known set of bugs, and when you submit your report the page lists all of them and marks the ones you caught. That key is what makes the exercises usable for learning on your own: after each run you see what you missed. This page is an order to take the exercises in, and what to pay attention to at each step.

What you need

A desktop browser with developer tools. The Network and Console tabs matter from the second step on, because some planted bugs leave no trace on the screen. No account, and nothing you type into a form is stored. A session has no time limit. The forms are small, so one pass fits in a sitting, but the second pass over the same form usually finds more than the first.

Step 1. TicketBox: a form, its requirements, your report

Open the form and read the requirements before you touch a field. For each rule, decide what the form should do when the rule is broken, then break it: give a number field a letter, and pick yesterday for a date that must be today or later.

Write down every problem as you find it, one bug per line, with the value you entered and what happened. The draft stays in your browser. Before submitting you can check it twice: the page tells you how many of the planted bugs your lines match and which lines matched nothing, without naming the bugs. Use the first check about halfway through, when you think you are done with the obvious part, and the second one right before you submit.

After you submit, the page shows every bug that was planted in your session. Read the ones you missed slowly. Each session on this form plants 13 or 14 bugs out of a pool of 22, so the list is long. Read it as a list of what you did not think to try.

Step 2. The same form, now with the developer tools open

When AI agents ran this form in October 2026, the bugs they found were the ones that change something on the screen: a wrong total, a message that does not appear. Much of what they missed was the other kind, where the server charges whatever total the browser sends it, or a request goes out without a value the page showed you, or something the server should keep to itself gets printed to the browser console. None of this is visible without the Network and Console tabs, and a first manual pass tends to skip it for the same reason.

Read what the server trusts and double submit testing, then start a new TicketBox session. It draws a new set of bugs, so the second run is a different exercise even where the form looks the same. This time, for every action, look at what the browser actually sent and what came back.

Step 3. JoinBox: two forms that must agree

A sign-up form and a login form are tested as one flow, because most of what can go wrong is a disagreement between them: a rule the first form enforces and the second one checks differently, or an account created with one spelling of an email address that cannot log in with another. Lockout after wrong passwords belongs here too, in both directions: it has to happen, and it has to end.

Read the sign-up and login test cases first. Use made-up names and passwords; the exercise keeps salted hashes only and deletes accounts after a day.

Step 4. RoomBox: a REST API with no screen

Here there is no form. You send requests, from a console on the page or from curl, and read status codes and response bodies. The habits from steps 1 and 2 carry over: read the API reference, send what it forbids, compare the response to what the reference promised. Two things are new. A request can succeed for the wrong user, so test with two accounts, not one. And two requests can arrive at nearly the same moment, which a form rarely lets you do by hand.

The REST API test cases guide has the request shapes worth trying. Expect this step to take longer than the forms did.

Step 5. Review a report an AI agent wrote

The fifth exercise turns the task around. An AI testing agent went through one of these forms and wrote a bug report. You get the same form with the same planted bugs and mark each item of the report: a real bug, a real bug with wrong steps, not a bug, or a repeat of another item. The key was built by reproducing every item by hand.

This is the skill of checking work that is not your own. The guide how to review a bug report an AI agent wrote lists the checks, cheap ones first.

Step 6. If you write code: nine builds

The same booking API comes as nine builds. One or two are clean and each of the others has one planted bug. Write a test suite against the reference, run it on every build, and mark each one as passed or failed. A good suite fails on every buggy build and passes on the clean ones. A suite that passes everywhere has not tested the thing that was broken; one that fails on a clean build has a wrong expectation in it.

How to tell whether you are improving

The result page is where to look. Each session lists how many of the planted bugs your report caught, and two runs of the same exercise are a fair comparison because they draw from the same pool. Also look at the line about the bugs AI agents usually miss: the forms were run by three AI models in October 2026, and the bugs they found in a third of their runs or fewer are marked. Those are the ones worth tracking from run to run.

More guides: what AI testing agents find and miss · email field test cases · all guides