Not "IT WORKED WHEN I CLICKED IT". The FIVE THINGS that must be demonstrated before ANYBODY SIGNS FOR A SCREEN.
There is no test framework here, so "tested" means whatever the person saying it decided it means — and this lesson is about making that a specific claim rather than a feeling.
THE FIVE ARE: IT WORKS ON DATA CHOSEN TO BREAK IT, IT BEHAVES WHEN THE SERVICE DOES NOT, IT IS CORRECT IN BOTH LOCALES, IT IS OPERABLE WITHOUT A MOUSE, AND THE RULES IT ENFORCES ARE ENFORCED SOMEWHERE THAT MATTERS.
NONE OF THOSE IS THE HAPPY PATH, AND THAT IS THE POINT. The happy path is what you demonstrated while building it, several hundred times — it is the least informative check available and it is the one every sign-off consists of.
DATA IS FIRST BECAUSE IT IS CHEAPEST AND FINDS THE MOST. Lesson 2, and the developer's own test records are chosen — unconsciously — to be convenient: short names, every field populated, twenty rows.
FAILURE PATHS ARE SECOND BECAUSE THEY ARE THE ONES USERS MEET. Lesson 4, and Module 8 Lesson 7's default: a chain that stops silently looks identical to one that succeeded.
BOTH LOCALES IS THIRD AND IT IS NOT OPTIONAL IN THIS ESTATE. Lesson 5 — a right-to-left layout is a different layout, and half the users are in it.
KEYBOARD IS FOURTH, IS CHEAP AS YOU GO, AND IS EXPENSIVE AFTERWARDS. Lesson 6.
AND THE FIFTH IS THE ONE NO AMOUNT OF CLICKING CAN ESTABLISH: THAT THE RULES ARE REAL. Module 10 Lesson 2 and Module 12 — a browser-side rule passes every UI test and does not exist. It is a question about where the rule lives rather than an observation.
SO "TESTED" SHOULD MEAN THOSE FIVE WERE DEMONSTRATED AND SOMEBODY WROTE DOWN WHAT HAPPENED. Anything less is a description of a demonstration, and a demonstration is designed to succeed.