What is test management?

Test management in one sentence

Test management is everything a team does to make testing repeatable, visible and accountable: deciding what to test, writing it down as test cases, running those cases against a build, recording every result and turning the results into a decision about the release.

Without it, testing still happens, but nobody can say afterwards exactly what was tested, by whom, against which version, or why a release was considered safe.

The building blocks

Every test management process, whether it lives in a spreadsheet or a dedicated tool, is made of the same parts.

Building block	What it is	Why it matters
Test case	Preconditions, steps and an expected result for one behaviour	Makes a check repeatable by anyone
Test suite	A group of related cases, often by feature or screen	Keeps hundreds of cases navigable
Test plan	A reusable selection of cases for a purpose, such as a release or smoke check	Saves rebuilding the same scope every cycle
Test run	One execution of selected cases against a specific build or environment	Ties results to what was actually tested
Result	Passed, failed, blocked or skipped, with notes and time	The evidence everything else is built on
Requirement link	Which requirement a case verifies	Shows coverage and what a failure affects
Defect	A recorded problem found by a failed test	Connects testing to fixing

Test cases

A good test case can be executed by someone who did not write it. Write each step as an action with its own expected result, so a tester can mark exactly which step failed. Give every case a stable ID, a priority and an owner. Version cases rather than overwriting them, so past results keep referring to the steps that were executed. In TestPlum this is the default: test cases have structured steps and every save creates a version you can diff.

Test runs

A run answers “what did we test, on what, and what happened?” Create one run per build, release candidate or environment. The run should snapshot the cases it contains, so later edits do not rewrite history, and results should be append-only, so a correction is a new result rather than an overwritten one. See how test runs work in TestPlum.

Traceability

Linking tests to requirements turns a list of results into an answer to a business question: is the thing we promised working? A requirements traceability matrix shows every requirement with its tests, their latest results and open defects.

Manual and automated tests belong in one place

Automated tests run in CI and produce reports, usually as JUnit XML. Manual tests are executed by people. If the two live in different systems, nobody has the full picture. A test management tool should accept automated results from CI and record them next to manual ones, so release reports count both. TestPlum ingests JUnit XML with a single request from any pipeline; see CI, API and webhooks.

The metrics that matter

Keep the set small and define each metric precisely. Vague numbers start arguments; precise ones end them.

• Execution completion: run cases with a final status divided by all run cases. It tells you how much of the plan is done.
• Pass rate: passed results divided by decisive results (passed, failed, blocked). Untested and skipped cases should not inflate it.
• Requirement coverage: requirements with at least one linked test divided by all requirements. It tells you what is tested at all.
• Requirement status: whether each requirement’s tests are passing, failing or untested. It tells you what works.
• Flakiness: how often a test flips between pass and fail without a change. See flaky tests.
• Open critical defects: the number that most often blocks a release.

Combined with agreed thresholds, these become a release readiness checklist.

Spreadsheet or tool?

A spreadsheet is fine while one person tests one product. It starts to fail when:

1. Several testers execute in parallel and overwrite each other’s results.
2. You need history: what was the result of this case two releases ago?
3. Someone asks which requirements were verified before a release.
4. CI produces hundreds of automated results per day.
5. Auditors or customers ask for evidence.

What to look for in a test management tool

• Structured steps and versioning, so results always refer to what was executed.
• Run snapshots and append-only results, so history cannot be rewritten.
• Fast execution: keyboard shortcuts and bulk actions, because testers record thousands of results.
• Traceability from requirement to test to result to defect.
• CI ingestion and an API, so automated results arrive without manual work.
• Explainable reports: every number should show how it was calculated.
• Access control: roles per project, and the option to limit testers to their assigned work.
• Data isolation and security appropriate for your industry.

TestPlum was designed around exactly this list. See all features or read how TestPlum decides release readiness.

Frequently asked questions