What does a website test actually check?

A test asks a clear question and checks the answer. “Does the website work?” is too broad. “Does the receipt show the project I entered?” is something you can actually check.

Suppose you enter your name, type Bruster into the Project field, and submit the form. A message appears. Was the action successful? You need to read the message to know. A message about a different project would not be the result you wanted.

The three parts of a useful check

1. Starting point: the page is open, and no project has been submitted.
2. Action: enter a name and project, then press Create smoke test.
3. Expected result: a receipt appears and names the project you entered.

The starting point matters. If an old receipt is already on the screen, you might accidentally read that receipt instead of the new one. The action matters because another person should be able to repeat it. The expected result matters because it tells you what counts as success.

Write the expected result before you run the check. If you decide what “correct” means only after seeing the page, you can easily accept something that is actually wrong.

Expected and actual results

The expected result is what should happen. The actual result is what really happened. A test compares the two.

If the actual receipt said “Smoke test created for Old project”, the check would fail. A failure tells you that the observation did not match the expectation. You still need to find out why. The website might have a bug, or the test might have expected the wrong thing.

Clicking is an action. Checking is an assertion.

An assertion is the part of a test that says what must be true. “Click the button” is an action. “The receipt must contain Bruster” is an assertion.

A browser can click a button even if the page never displays the right result. This is why an automated test should contain a meaningful assertion after the important action. Successful clicks alone are weak evidence.

Later, you will write assertions using commands that begin with expect. For now, read that word as “check that this is true.”

What one passing test can tell you

If this check passes, you have evidence about this form, this input, and this result in the browser used for the test. You have not checked every field value or every device.

For example, submitting a complete form does not show whether a missing project is rejected. That needs another check. Thinking this way helps you choose useful tests without promising more than they cover.

You may hear the phrase smoke test. It means a short check that an important task still works. Our form submission is a good example: it is small, clear, and worth repeating after a change.

Try it: improve a vague test

Rewrite “Check the form” as a starting point, an action, and an expected result. Use the project name Garden club.

See one possible answer

Start on a fresh practice page with no receipt. Enter Ada Lovelace as the name and Garden club as the project. Press Create smoke test. Expect a receipt headed “Smoke test created for Garden club”.

Check your understanding

Is “the button was clicked” enough to prove that the project was submitted correctly?

Read the answer

No. It describes an action. You also need to check the result, such as the correct receipt text.