A printable worksheet for this exercise: the tasks, the exact prompts, a checkpoint and stretch challenges. Hand it round when you are onboarding a team.
Download the PDF (98 KB)
A test that clicks through a flow without checking anything will pass right up until the moment your application breaks, and then it will keep passing. This exercise is about the difference between doing and proving. About ten minutes.
The idea in one line
Every instruction you write is either an action (do something) or an assertion (check something is true). A test with no assertions cannot fail for the reason you care about.
Step 1 — See an assertion in the test you already have
Open your test and expand a verification step:
Three things to notice:
- The action reads as a description of the target — the element containing this text — not a selector path. That is what lets it survive the page being restructured around it.
- The right-hand pane shows the page at that exact moment.
- The Data tab underneath shows the value the step actually read.
Step 2 — Write a weak test on purpose
Create a new test with this prompt:
On the Toolshop demo store at https://practicesoftwaretesting.com/, open the Drill category and click into the Cordless Drill 20V product. Do not sign in.Approve it and let it run. It will pass.
Now ask what it proved. It proved a link could be clicked. It did not check the product page loaded correctly, that the price was right, or that an error was not shown. If the store started serving the wrong product, this test would stay green.
Step 3 — Make it prove something
In the chat on the left, ask for the check:
Add a step that verifies the product page shows the price $125.23.The agent adds the step, checks it against the live page, and tells you what it did. Run the test again.
Same flow, completely different test. It now fails if the wrong product loads, if the price changes, or if the price element disappears.
What makes a good assertion
Check the thing a person would check. After opening a product, a person looks at the name and the price. They do not inspect a CSS class.
Be specific enough to be wrong. "Verify a price is shown" passes if the price is $0.00. "Verify the price is $125.23" does not.
Do not over-specify. Asserting on text that changes constantly — a promotional banner, a session ID, a "3 people are viewing this" counter — produces a test that fails for reasons nobody cares about, and a suite people learn to ignore. That is worse than no test.
Check counts and negatives too. "Exactly 2 products" catches a category quietly losing an item, which a per-product check never would.
Try these
Each is one prompt. Add them to a test or create new ones. None needs a sign-in.
Verify the Sander category lists exactly 3 products.Open the Workbench category and verify both the Wooden Workbench at $172.52 and the Workbench with Drawers at $178.20 are listed.Open the Drill category, sort by Price (Low > High), and verify the first product listed is the cheapest one on the page.Add the Cordless Drill 20V to the basket as a guest and verify the basket total shows $125.23.That last one sets up Exercise 5.
Checkpoint
You are done when you have a test that fails if the application misbehaves — not one that merely clicks without complaint. If you cannot name what would turn your test red, it is not finished.
What you learned
Actions prove nothing on their own. The value of a test is entirely in what it checks, and you get to say what that is in plain language.
Next: Exercise 3 — Read a run.
- Exercise 3 - Read a Test Run and Its Evidence — read what the run actually proved
- Reviewing AI-Generated Tests: What a Human Still Has to Check — what a human still has to check
- Understanding a Test Run and Its Results in Functionize Studio — the evidence, in full
A PDF of this page, for reading offline, printing, or passing to somebody who does not have a Studio account yet.
Exercise 2 - Write Assertions That Prove Something (PDF, 258 KB)