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 Anaqa demo store at https://ecom.functionizeapp.com/testsites/anaqa/index.php?route=common/home, open the Electronics > Air Conditioner category and click into the Boltas 2 Ton 3 Star Split AC 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 $966.00.
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 $966.00" 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 Electronics > Computer Accessories category lists exactly 3 products.
Open the Electronics > Laptops category and verify both the Vostro 3458 at $175.00 and the iBall CompBook at $560.00 are listed.
Open the Electronics > Air Conditioner category, sort by Price (Low > High), and verify the first product listed is the cheapest one on the page.
Add the Boltas 2 Ton 3 Star Split AC to the basket as a guest and verify the basket total shows $966.00.
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.