Test Scenarios

One-sentence summary

A test scenario is the planned way of writing down "when I give this input I expect this output" in advance and checking it step by step, instead of poking at a project at random.

Why it matters

Your prototype worked, but does it really work? You tried it once, it did the right thing, and you were happy. But what happens the next day when someone else opens the project and it behaves differently?

If we test "off the top of our head," we try different things each time and forget what we already checked. A test scenario fixes this. Every scenario states three things clearly: which input we give, what we expect, and what actually happened. That makes a test repeatable: someone else, or you a week later, can follow the same steps and get the same result.

This is different from randomly tinkering. Planned testing lets you show where a bug is instead of guessing. The Test Track idea you will meet later in this module rests on the same logic: taking a robot through different situations one by one and writing down what it does in each.

What is a test scenario?

A test scenario is a small plan that checks one single situation. In its simplest form it has:

• Input: What do we give the project? (a button press, an amount of light, a number, an obstacle)
• Expected output: What do we want to happen for that input?
• Actual output: What really happened when we tried it?
• Result: Are expected and actual the same? (Pass / Fail)

Throughout this lesson we will use one example project you already know from earlier modules: the automatic night light. The idea is simple: when the room is dark the LED turns on, when it is bright the LED turns off. A light sensor (LDR) measures how bright the surroundings are.

The input → expected output idea

First let's write a clear rule: "If the light level is below 300, turn the LED on; otherwise turn it off." That number 300 is called the threshold.

Now we turn the rule into scenarios:

• Input: light level 100 (dark room) → Expected: LED on.
• Input: light level 800 (bright room) → Expected: LED off.

Notice something: we have not even tried the project yet. We wrote the expected output in advance. This matters a lot, because it stops us from looking at the result during testing and saying, "well, that's probably what should have happened."

Boundary cases

The place we make mistakes most easily is right at the threshold. Our rule says "turn on if below 300." So what should happen when the light is exactly 300? On or off? If we don't decide, the project may sometimes turn on and sometimes off at that point.

Inputs right at the threshold, just below it, and just above it are called boundary cases. A good test list always includes the boundaries:

• Input: 299 → Expected: on.
• Input: 300 → Expected: off (because our rule says "below," and 300 is not below 300).
• Input: 301 → Expected: off.

Testing the boundaries reveals most hidden bugs. Imagine a calculator that accepts numbers up to 5. Then 4, 5 and 6 are the most valuable tests; a middle value like 2 rarely surprises you.

The test scenario table

The best way to keep scenarios organised is a table. Each row is one scenario. A table like this becomes a test list that you can repeat as many times as you like.

Example table for the night light:

In this table, row 4 came out "Fail." That means the code was probably written as "turn on at 300 and below," while we wanted "only below 300." The test showed us the exact spot of the bug. In the next lesson you will learn to record bugs like this in a Bug Log.

Leave the "Actual output" and "Result" columns empty until you run the test. Only fill them in after you try it. That way you don't fool yourself.

Second example: the line-following robot

Let's apply the same method to a different project. From earlier modules, the line-following robot tries to stay on a black line when it sees one. The input is no longer a number, but whether or not there is a line under the sensor.

Look at row 4: "if the line disappears" is a boundary case, and most people don't think of it. What should the robot do when it loses the line? Deciding this in advance can stop the robot from driving off the table in the real test.

Mini practice

Prepare a five-row test table for a small project of your choice (the night light, the line-following robot, or a doorbell that runs on a button). Follow these steps:

1. Write the one-sentence rule of your project. Example: "When the button is pressed, ring the bell."
2. Fill in this empty template:

Project: ...................
Rule: ...................

# | Input                | Expected output | Actual output | Result
1 | (normal case)        |                 |               |
2 | (another normal case)|                 |               |
3 | (boundary: just below)|                |               |
4 | (boundary: exact threshold)|           |               |
5 | (unexpected input)   |                 |               |

1. Fill in the "Expected output" column before you try the project.
2. Then run the project and fill in the "Actual output" and "Result" columns.
3. Give the same test to a friend and see whether they get the same results. If they do, your test is repeatable.

Try to include at least one boundary case and one unexpected input (for example, running it while the sensor cable is unplugged).

Common mistakes

Writing the expected output after the test

Running the test, seeing the result, and then saying "that's what I expected anyway" is the most common mistake. The expected output is always written first; otherwise the test proves nothing.

Testing only the "happy" cases

Everyone tries the case where the project works. The valuable cases are the boundaries and unexpected inputs: the exact threshold, an empty input, an unplugged sensor, very bright light.

Writing a vague expectation

"The LED should work properly" is not testable. "With light at 100, the LED is on" is testable. Write the expectation so it can be measured.

Testing only once

Assuming you're done because it worked once is misleading. If running the same scenario again gives a different result, the project is not yet reliable.

Safety note

In tests with robots and motors, don't run the robot near the edge of a table so it can't fall off; test it on the floor or in an area with barriers. Keep your fingers away from moving parts such as gears and wheels. Cut the power before plugging or unplugging a sensor cable. Stop the test if a battery gets hot. If a fix needs a cutting tool, a hot surface or soldering, do it together with an adult.

Lesson summary

• A test scenario has four parts: input, expected output, actual output and result.
• The expected output is written before you run the test.
• Boundary cases (the exact threshold and just around it) reveal the most hidden bugs.
• Keeping scenarios in a table makes testing organised and repeatable.
• A good test tries not only the case where the project works, but also the boundaries and unexpected inputs.

Check questions

1. What are the four basic parts of a test scenario?
2. Why do we write the "expected output" before running the test?
3. What does a boundary case mean? Give one boundary case from the night light example.
4. If our rule is "turn the LED on if the light is below 300," should the LED be on when the light is exactly 300? Why?
5. You ran a test and it worked. What do you still need to do before calling it "repeatable"?

Answers

1. Input, expected output, actual output and result (pass/fail).
2. Because if we write it after seeing the result, we fool ourselves into saying "that's what it should have been"; writing it in advance makes the test a real check.
3. A boundary case is an input very close to the point where the rule changes. Example: the light values 299, 300 and 301 are boundary cases for the night light.
4. No, it should be off. The rule says "below," and 300 is not below 300, so a value equal to the threshold falls outside the rule.
5. You need to run the same scenario again and get the same result, and if possible have someone else follow the same steps and get the same result too.

Source and verification note

For “Test Scenarios”, verification focuses on whether the relationship between What is a test scenario? and Boundary cases remains consistent across examples. A project page should make a result claim only when it is supported by a real prototype, test record or observation. Numbers such as cost, duration and success rate must be labelled clearly when they are estimates.

Next lesson

The Bug Log: Writing down each case that came out "Fail" in testing, one by one, and keeping an organised record of what you tried and what actually helped.