Home / Glossary

Test Management Glossary

Last updated 2026-08-15 · 20 terms

This is a glossary of test management terminology: the words QA teams use to organise, execute and report on testing inside a test management system. It is deliberately not a general software testing dictionary. You will not find black box testing or performance testing here, because those are well covered elsewhere and they are not what this page is for.

Every definition is written to stand on its own, so it makes sense quoted somewhere else without the page around it. Where a term deserves more than a paragraph, the entry links to a full article or to a step-by-step guide in our knowledge base.

The definitions are maintained by the QA Madness team, who build QAM Hub and run test management on client projects for a living. Each entry carries a review date and we revisit the set on a schedule rather than when someone notices a mistake.

Filter terms

Custom field

An extra data field added to a test case, run or result to hold information the default schema does not cover: component, risk level, regulatory reference, automation owner. Custom fields are how a generic tool becomes yours. They are also how reporting gets useful, because a field you cannot filter on is a field you cannot report on.

Execution status

The recorded outcome of running one test case in one test run: passed, failed, blocked, skipped, retest, or whatever custom values a team defines. The status belongs to the run, not to the case, which is why the same case can be passed in one release and failed in the next without either record overwriting the other.

Also called: test status, result status

Precondition

The state the system and the data must be in before a test case's first step makes sense: a logged-in user, a seeded order, a specific feature flag. Preconditions written down are the difference between a case anyone can execute and a case only its author can. They are also the first thing to check when a case fails for everyone new.

Also called: setup, given

Regression suite

The set of test cases run to confirm that existing behaviour still works after a change. It grows by default and shrinks only on purpose, which is why mature teams review it on a schedule and retire cases that no longer earn their execution time. A regression suite nobody prunes eventually becomes too slow to run when it matters.

Also called: regression pack

Requirement

A statement of what the product must do, held in a tracker, a specification or the test management system itself. In testing terms a requirement matters because it is the thing coverage is measured against. A requirement with no linked test cases is untested by definition, and finding those gaps is most of what traceability is for.

Also called: user story, acceptance item

Requirements traceability matrix (RTM)

A view linking every requirement to the test cases that verify it and the results of those cases, so gaps and orphans are visible at a glance. Built by hand in a spreadsheet it is accurate on the day it is made and wrong within a sprint. Generated from live links, it stays accurate without anyone maintaining it.

Also called: traceability matrix, RTM

Sanity testing

A narrow check that one specific fix or change behaves as expected, usually run after a build is already known to be broadly stable. Sanity testing is deep and narrow where smoke testing is shallow and wide. The two get used interchangeably in conversation, which is harmless until someone reports "sanity passed" and the other person hears full coverage.

Smoke testing

A short, broad run confirming a build is stable enough to be worth testing properly: the application starts, the main paths work, nothing is obviously on fire. Smoke suites earn their place by being fast and by being run on every build. A smoke suite that takes forty minutes has stopped being a smoke suite.

Also called: build verification test

Tag

A free-form label attached to test cases so they can be selected across the suite hierarchy: smoke, mobile, payments, needs-data, slow. Tags are how you build a run that folders cannot express. They rot faster than any other organising device, so agree a small vocabulary early and audit it, or you end up with three spellings of one idea.

Also called: label, marker

Test case

The documented check of one behaviour: a title, preconditions, steps with expected results, and whatever metadata the team needs to filter on. A test case is a reusable asset executed many times against many builds, which is the property that separates it from a task or a ticket, and the reason issue trackers model it badly.

Also called: test script, test scenario

Test coverage

How much of something is exercised by tests, where the something has to be named to mean anything: requirements, features, code, risk. Requirement coverage is what test management systems measure, and it answers whether anything shipped untested. It is not code coverage, and quoting one number while meaning the other is the most common reporting error in QA.

Also called: requirement coverage

Test data

The inputs and system state a test needs to run: accounts, records, files, fixtures. Test data is the most common cause of a case that only its author can execute and of a run that fails in one environment and passes in another. Managing it means deciding what is seeded, what is generated and what is shared.

Also called: fixtures, seed data

Test management system (TMS)

The system of record for testing: where test cases live, where runs are executed and recorded, where automated results are collected, and where coverage and release readiness are reported. It sits between the issue tracker that holds requirements and defects, and the frameworks and pipelines that execute automated tests.

Also called: test case management tool, TCMS

Test plan

The document covering what will be tested for a specific release or project, by whom, in which environments, on what schedule, and what is explicitly out of scope. A plan is bounded and dated. It answers "what are we doing this time", which is a different question from the one a test strategy answers.

Test result

The record of one execution of one test case in one run: its status, who or what ran it, when, how long it took, and the evidence attached. Results accumulate into history, and history is what makes flakiness, stability trends and pass-rate comparisons possible. A tool that stores only the latest status has thrown that away.

Test run

A selected set of test cases executed together for a purpose, against a specific build and environment, with an owner and a result per case. The run is the unit that carries execution history. Creating a run rather than editing statuses on the cases themselves is what lets you compare this release with the last one.

Also called: test cycle, test execution

Test step

One action within a test case, paired with the result expected after it. Steps make a case executable by someone who did not write it, and they make a failure precise: the run records which step failed, not just that the case did. Cases with a single vague step are the usual reason failures need re-investigation.

Also called: step, test action

Test strategy

The standing approach to testing across an organisation or product: what gets automated, which risks justify which depth, which environments are maintained, how defects are triaged. A strategy outlives releases. A test plan applies it to one of them, which is why copying strategy text into every plan is a sign that neither document is doing its job.

Test suite

A named grouping of test cases, usually by feature, component or type of testing, forming the structure a team browses and selects from. Suites organise the library; runs execute from it. Keeping that distinction is what stops a suite from becoming a record of one release's execution and losing its reusability.

Also called: test folder, test collection

Traceability

The maintained links between requirements, test cases, runs, results and defects, so any one of them can be followed to the others. Traceability turns a question like "was this requirement tested, and did it pass in the release we shipped" into a lookup rather than an investigation. Regulated industries require it; everyone else needs it at audit time.