How do you check an application when you cannot code?

Two customers book the same time: what should happen? This example explains what a test is for, why to prepare it early and what you can check yourself.

Imagine a booking tool. Two customers choose the same slot at almost the same time. The expected result is simple to describe: only one booking should be confirmed, and the other customer should be able to choose another time. That sentence prepares a useful check.

A test asks a specific question

A test means trying a situation and comparing the result with what was expected. You can do this manually, using two trial accounts and invented information.

An automated test uses code to perform a check. It can run again after a change to spot certain problems. Its value depends on what it actually checks: a green indicator alone does not mean the whole application works.

Decide on the correct result before building

For this booking, you need to choose the rule before trying to program it. If you decide afterwards, you risk accepting the behaviour you got simply because it already exists.

Writing tests before code is part of a method called TDD. You do not need to learn the acronym to ask for the essential point: “First show me what we will check and which result will count as correct.”

Choose situations that matter

Start with a normal action, then a common error. A booking succeeds; an occupied slot is refused. Add an important rule: a colleague allowed to view the calendar must not be able to change appointment times.

These situations can come from your requirements document. They help you discuss checks without opening code files and without claiming to cover every possibility.

Ask what was tried

When a stage is reported as complete, ask which situations were checked, what happened and whether anything failed. Repeat the main journey in the application yourself whenever possible.

If a check fails, the reason needs to be understood. Changing the expected result to get a green indicator only makes sense if the requirement really changed. The reason for that change should remain visible.

Keep realistic expectations

In Maestro, the method prepares checks while breaking down the work. Your approval includes reviewing the described need and the result you can observe.

Useful tests reduce the risk of missing errors; they do not prove that there are no defects or that the product is secure. Start by writing down three situations your work depends on and asking how each will be checked.