Test case, scenario and script: three things that are not the same

You open the test suite you inherited. There is a folder called "scenarios" that holds files with numbered steps, a folder called "cases" that holds Selenium code, and a spreadsheet titled "regression scripts" that actually describes business behavior. Nobody remembers why. Every word points to something other than what its name promises, and now you are the one who has to guess.

This is not a cosmetic problem. When three distinct concepts wear each other's names, the suite becomes unreadable: you cannot tell which file describes a business intention, which one defines a concrete verification, and which one is just code that pushes buttons. The short answer is this: test case, scenario and automation script are three different layers, and blurring them is the cheapest way to pile up technical debt in QA.

01 · the layerThe scenario describes a situation, not a verification

A test scenario is the description of a business situation you want to cover. It answers the question "which real world condition do I care about". It does not say how to verify it or with what exact data: it says what story you are telling. "A user tries to pay with an expired card" is a scenario. It is not yet an executable test; it is an intention.

The scenario lives in the language of the product, not that of the system. That is why a business analyst can read it and nod without knowing anything about the database. The ISO/IEC/IEEE 29119-1 standard deliberately separates the level of the test condition (what you want to exercise) from the level of the concrete case that realizes it [1]. The scenario is the hinge between the requirement and the test.

The scenario verifies nothing. It frames what is worth verifying.

The usefulness of the scenario is about coverage. When you list scenarios, you are mapping the space of situations the product must support: valid card, expired card, card with no funds, network down mid payment. One scenario can give rise to several cases. It is a level of abstraction above, and losing sight of it is what leaves suites with a thousand cases while nobody knows which situations they truly cover.

02 · the oracleThe test case has an expected result; the script decides nothing

A test case is the concrete verification. It has what a scenario does not: preconditions, specific input data and, above all, an expected result. That expected result is the oracle: the assertion of what should happen for the test to be considered passing. Without an expected result there is no test case; there is a stroll through the application.

The ISTQB defines the test case precisely by that trio: input values, execution preconditions and expected results [2]. A case is executable by a human reading steps, or by a machine. And here comes the third layer, the one most people confuse with the other two.

The automation script is code. It is the mechanical implementation of one or several cases so they run without a person pushing buttons. The critical point: the script does not provide the oracle, it inherits it from the case. A script that clicks on things and navigates screens but asserts no expected result is not testing anything; it is automating a stroll. The expected result lives in the case; the script only checks it at high speed.

That is why mixing the names is costly. If you call a script with no assertions a "case", your coverage report lies: it says you verify something you merely walk through. If you call a case a "scenario", you lose the business level and can no longer reason about which situations are missing. Terminology is not bureaucracy: it is what makes the suite's metrics mean something.

03 · the debtWhy terminological hygiene pays for itself within a year

The confusion does not hurt the day you write the suite. It hurts twelve months later, when someone else (or you yourself with no memory of the context) has to maintain it. A suite where scenario, case and script are clearly separated reads like an index: situations at the top, verifications in the middle, code at the bottom. A suite where the three names are swapped reads like a hieroglyph.

There are three concrete debts born of the mix. The first is coverage debt: without the scenario layer visible, nobody knows which business situations went untested, so they surface in production. The second is oracle debt: when scripts are called cases, automation without assertions sneaks in and the suite gives false confidence. The third is maintenance debt: when a business rule changes, you do not know which files to touch because the names do not tell you which layer each thing lives in.

The operating rule is simple. Name folders by their layer and do not let a file move up or down a level without renaming it. A scenario never contains code. A case always contains an expected result. A script always inherits its oracle from a case and never invents its own by accident. If you respect those three boundaries, the person who opens your suite a year from now will be able to read it without archaeology.

Today's careless word is next year's undecipherable file.

When you move from theory to practice and start turning cases into scripts, this separation becomes even more profitable: automation only scales if each script knows exactly which case it implements and which oracle it checks. Without that naming discipline, automating means multiplying the mess instead of reducing the effort.