Test Case Management: The Record a Release Rests On

The question a green dashboard can't answer

Somewhere in the last ten years, "move fast" got quietly rewritten as "skip the paperwork." Test case management was the paperwork. So a lot of teams went straight to automation: write the checks, wire them into CI, watch the board turn green.

It feels like progress, because for a while it is — right up until someone asks a question the board was never built to answer.

What did we actually test before we shipped? Not how many assertions ran, but what they covered, measured against what the release was meant to do. What changed since last time, and did we re-test the part that changed?

And the hardest one: why did we sign this off? An auditor asks it. A customer's security reviewer asks it. Your own team asks it in a post-incident retro. To every one of them, "the pipeline was green" is not an answer.

Test case management is how you answer those questions. It isn't documentation you produce to satisfy a process; it's the record that makes every downstream quality decision defensible.

What a test case actually contains

Strip a test case down and five parts matter.

An ID — a stable handle that doesn't change when the title does. It's what a bug report, a run record, and a requirement all point at. Titles are for humans; IDs are for traceability, and the two should not be the same field.

Preconditions — the state the system has to be in before step one makes sense. A logged-in user with an empty cart is a different test from one with a saved card. A case that leaves this implicit fails intermittently, for reasons nobody can reproduce.

Steps — the actions, in order, specific enough that someone who has never seen the feature can perform them.

Expected result — what should happen. This is the field everyone under-writes.

Why "expected result" is the field that decides everything

Watch how people fill it in. "Login works." "Page loads correctly." "Error is shown." Every one is a placeholder wearing the costume of an assertion. Works how? Correct by what definition? Which error, with what message, and what happens to the half-filled form behind it?

The expected result is the entire point of the case — the line that separates a pass from a fail — and it's the line that gets three words when it needs three sentences.

A vague expected result quietly transfers the judgement of pass-or-fail from the person who designed the test to whoever runs it, months later, with no context. Two testers, same case, different verdicts. That isn't flakiness in the product. It's flakiness in the case.

Case, scenario, suite, run: four words, four different things

These get used interchangeably in standups, and it costs you at reporting time, so it's worth being pedantic.

A test case is a single, specific check with one expected result. A scenario is the user-level situation it exercises — "checkout with an expired card" is a scenario; the cases underneath cover the decline message, the retained cart, and the retry.

A suite is a named collection of cases you run together for a reason: a smoke suite, a regression suite, the set tied to one feature. A run is what happened when you executed a suite at a point in time — this build, this environment, these results, this date.

Why conflating case and run breaks reporting

A case is the question. A run is one answer to it. When a tool — or a spreadsheet — stores only the latest result on the case itself, you have quietly thrown away every previous answer.

You can no longer say "this case has failed on three of the last five builds," because there is only ever one build in the record: the last one. Trend, flakiness rate, regression-over-time, "when did this start failing" — all of it lives in the run history.

A model that overwrites the result every time can't hold history. Keep cases and runs separate, with a relationship between them, and these questions answer themselves. Merge them, and they become unanswerable no matter how much you paid for the tool.

Traceability, and the question coverage can't answer

A requirements traceability matrix sounds like the most bureaucratic artefact in testing, and it is often built like one — a giant grid maintained out of obligation. But underneath the ceremony it answers a question nothing else can.

Coverage percentage tells you how much of your code your tests exercise. It's a useful number, and on its own it's also a trap: it can be high while the thing you were supposed to build goes completely untested. You can hit ninety per cent line coverage on a feature and never once check the one business rule the feature exists to enforce.

What the link is really for

Traceability is the link from a requirement to the cases that verify it. Its value shows up the day a requirement changes. Someone edits acceptance criterion 4, and the question in the room is immediate: which tests are now wrong?

Without the link you find out at runtime, or in production, or never. With it, you follow the requirement to its cases and know exactly what to revisit before you ship — not a percentage, a list.

Why the spreadsheet lasts — and the three places it breaks

Nobody starts test case management in a dedicated tool. They start in a spreadsheet, and they're right to. Managing test cases in Excel or Google Sheets is free, everyone knows how, columns are fields and rows are cases, and you can be running in an afternoon.

For a small suite and one or two testers it genuinely works, and any honest look at test case management best practices has to begin by admitting that. The spreadsheet is not a mistake. It's a stage. It breaks at three specific points, and it's always the same three.

Concurrent edits

The moment two people manage cases at once, the spreadsheet becomes a merge problem. Someone's row wins, someone's row is lost, and you find out a fortnight later that a case you swear you wrote isn't there. Real-time sheets soften this but don't fix it: there's no record of who changed what, or why, or which version you tested against.

Run history

A sheet has one cell for a result. Run the suite again and you either overwrite the last result or paste in a new column — and within a quarter you're maintaining a grid forty columns wide that nobody can read. The spreadsheet has no concept of a run as a first-class thing, so it can't give you history. And without history, you can't see a trend.

Traceability

You can fake a requirement link with a column of IDs typed by hand. It holds until a requirement changes, at which point every link is a manual find-and-check. Nobody does it, so the links rot into decoration. A relationship the tool doesn't understand is one it can't maintain for you.

When the case is the source of truth for automation

Here is the split that quietly decides whether test case management is worth anything to your team, or is just documentation tax.

In most shops the documented cases and the automated tests are two separate universes. Cases live in the spreadsheet or the tool; automation lives in the repo. They were the same idea once — the automated test was written from the case — and then they drifted, because the code changed and nobody updated the prose.

Six months on, the documentation describes a product that no longer exists. Everyone knows it, so nobody trusts the docs and nobody maintains them. The record is dead, and its death was predictable the day it became a parallel copy instead of the source.

Making the case load-bearing

The alternative is to make the case the source of truth: the documented case is the canonical description of the behaviour, and the automated test is an implementation of it — linked to it, traceable back to it.

Change the intended behaviour and the case is where you change it; the automation follows from that, not the other way round. Now the record stays alive because it's load-bearing. A failing test points back to the exact case and expected result it was checking, and a case can tell you honestly whether it's automated, run by hand, or not covered at all.

Where Tesbo sits, precisely

This is the job Tesbo is built for: managing that record and drafting the cases that populate it, with the case as the source and a person approving what goes in.

The boundary is worth stating plainly, because it's where a lot of tools oversell. Tesbo does not run, schedule, or execute your automated tests — the framework, the runner and the pipeline stay yours. It manages and drafts the cases the automation is built from, and nothing enters the trusted record without a person signing off on it.

A case nobody reviewed is a case nobody trusts

The last piece is the one most often skipped, because it's the one that costs someone an hour: review.

A test case is a claim about how the product should behave, written by one person, usually quickly. Unreviewed, it carries exactly one person's understanding — their blind spots, their assumption about what "correct" means, the requirement they half-remembered.

When that case later fails, the first question is always the same: is the product wrong, or is the case wrong? A reviewed case lets you answer fast, because the expected result was agreed by more than one person before it ever ran. An unreviewed one sends you into a debate about what the test even meant to check — mid-release, with the clock running.

Review is also where vague expected results get caught. "Error is shown" survives being written; it does not survive a second person asking "which error?" That question is cheap to answer in review and expensive at 2 a.m. during an incident.

The foundation comes first

Put the pieces together and the argument is simple. Quality decisions become defensible — what did we cover, what changed, why did we sign off — because there's a real record underneath them: honest expected results, runs kept separate from cases so history survives, requirements linked so a change has a visible blast radius, and review so the record is trusted.

Automation built on that record is worth having. Automation built on nothing is a green light with no idea what it's approving.

The reason so many teams skipped this isn't recklessness. It's that maintaining the record by hand — the forty-column spreadsheet, the rotting links, the overwritten results — was genuinely miserable, and abandoning it felt like the only relief on offer. But the misery was in the manual upkeep, not the practice.

None of this replaces exploratory testing, or the judgement of the people doing it — a documented suite tells you what you decided to check, never what you haven't yet thought to. It's the floor, not the ceiling. But you want the floor there before you start building on it.