When you have a dozen test cases, you can keep them in a spreadsheet. When there are hundreds, multiple test runs, and more than one team, you need a dedicated system — a test management tool. Think of it as a tracker, but not for bugs — for test cases and their execution results.
The most well-known tools are TestRail, Qase, and Zephyr (the last one lives inside Jira), and there are others that are simpler or free. The logic is the same across all of them, so once you know one, switching to another is easy. Let's look at what they offer and how work is structured inside them.
A case lives in a suite; a run takes the suite against a specific build and puts a mark on every case. A failed case carries a link to a bug — and that link reads both ways: from the case card you see which build it failed on and which defect covers it, from the bug you see which check found it. The system counts the run summary itself, from the marks: "blocked" is a separate line from "failed" — there is no defect there, there was simply nothing to check with.
Why a dedicated system
Keeping test cases in a text document or Excel is possible, but it gets painful fast:
- It's unclear what has already been checked on this build and what hasn't.
- There's no convenient way to record a result for each case (Passed / Failed / Blocked) and get a summary.
- It's hard to track history: how did this case behave in previous runs.
- It's awkward to work as a team of two or three on the same set.
A test management system closes all of this at once.
How it works
Three core concepts — and you already know them:
- Test case — a checklist card with steps and expected results. Cases are organized into sections/suites (for example, "Registration," "Payment") — these are test suites.
- Test run — you take a set of cases and execute them against a specific build. For each case you set a result: Passed (it worked), Failed (it broke — you usually link to the bug you filed right away), Blocked (can't be checked), Skipped (deliberately skipped).
- Report — the system shows the run summary automatically: how many passed, how many failed, trends over time. It's a handy answer to the question "is this ready to ship?"
A typical day: you open the planned run "Regression — Payment," go through the cases, mark results, file bugs in the tracker for failing cases and link them to the cases.
The connection with a bug tracker
A test management tool and a bug tracker are neighbors that work together. Cases and runs live in TestRail or Qase; bugs live in Jira. When a case fails, you file a bug in the tracker and link it to the case. Later you can see, from the case, which bugs it caught — and from the bug, which case found it. Zephyr is convenient precisely because it lives right inside Jira, so the connection is completely seamless.
Is it worth learning a specific tool in advance
Not really: your team will show you whichever one they use, and it takes a couple of days to pick up. What matters is the case → run → report mechanic: the tools draw it differently but do the same thing. Qase and TestRail have free trials — an evening is enough to create a couple of cases and a run and get a feel for it.
Where this applies
On any serious project a system like this is the team's shared memory: what was checked on this build and how the last regression ended.
Where people stumble most often:
- Confusing test management with a bug tracker. Cases and runs go in one place, bugs go in another; they are connected, but they are different things.
- Not marking run results carefully, so nobody knows later what was actually checked: the summary is counted from marks, not from memory.
- Not linking a failed case to a bug — the case history breaks, and in the next run nobody remembers why it is red.
In short
- Test management holds cases, runs and results; a bug tracker holds defects. Two different systems, and they are linked.
- A run is a set of cases plus a specific build plus the marks; without the build number a result has nothing to attach to.
- "Blocked" is not "failed": there was nothing to check with, the case has no defect, and the report keeps it on a separate line.
- The case-to-bug link works both ways: from the case you see which defects it caught, from the defect — which check found it.
- The system counts the summary itself, from the marks you set: a missing mark means "unknown," not "fine."
What to read next
- How to write a test case — what the card that goes into a suite is made of.
- Test plan and test suites — how suites are assembled for the goal of a run and when a run counts as finished.
- Bug lifecycle and trackers — what happens next to the defect a failed case points at.
- Test reporting and metrics — which numbers from runs mean something and which do not.