Test Case vs Test Suite vs Test Run: Differences and Reuse Examples

A password-reset check fails on one build and passes after a fix. If the team changes a single “Status” field from Failed to Passed, the latest result may be visible while the evidence of the original failure disappears. Copying the entire test case for each build creates the opposite problem: several specifications that must be maintained separately.

A test case defines a check, a test suite groups checks for a purpose, and a test run organizes a particular execution and records its outcomes. Reuse the definitions and suitable selections; retain distinct evidence for what happened on each build. The useful boundary is between the behavior you intend to verify and the observations made while verifying it.

Compare the Purpose of Each Artifact

These terms describe different responsibilities, even when a tool displays them together. A case can be ready for execution without having passed anything. A suite can be complete as a collection without having been executed. A run can exist in a planned state before a tester records its first result.

Criterion	Test Case	Test Suite	Test Run
Main question	What specific behavior should be checked, and how?	Which checks belong together for this purpose?	What was selected, who tested it, and what happened in this context?
Typical contents	Preconditions, inputs, actions, expected outcomes, requirement references	Selected cases or procedures, grouping purpose, relevant ordering or dependencies	Case selection and specification references, build, environment, assignments, actual results, evidence and defects
Reuse across builds	Reuse the definition while the behavior remains valid	Reuse a suitable grouping, reviewing membership as risk changes	Reuse useful settings or selection for a new execution; record fresh results
Maintenance trigger	A requirement, setup, action or expected outcome changes	Coverage needs or the grouping purpose change	A build, configuration, assignment or execution attempt needs recording

The expected outcome belongs to the specification. The actual outcome belongs to an execution result. A case saying “Reject a consumed reset token” remains useful after an execution shows that the application accepted it. Changing the expectation to match that faulty behavior would hide the discrepancy rather than fix it.

A suite might group password-reset cases for regression or select critical identity checks for smoke testing. The same case identity can contribute to different logical selections without copying its steps. Whether an application implements that through suites, folders, tags, filters or another object depends on its data model. A folder containing cases is not automatically a run or a record of release coverage.

Give each grouping a purpose so its membership can be reviewed. “Identity Smoke” should have a reason for including a consumed-token check and excluding another check, rather than serving as an unexplained folder name. For the library organization behind those selections, see the guidance on organizing a Jira test repository.

A run connects the selected work to execution context. It may contain several case executions, each with its own tester and result history. Some systems call related objects cycles, executions or execution records. Confirm how your tool separates planning records, individual tests and results before treating those names as interchangeable.

Reuse One Password-Reset Suite Across Two Builds

Consider an illustrative password-reset feature, not a documented customer example. Its agreed requirements say that a valid unused token permits a password change, expired tokens are rejected, consumed tokens cannot be used again, and requests for an unknown email address receive the agreed generic response without revealing whether the account exists.

Create the Password Reset Core suite with the following cases. Both runs select the same four definitions at revision 1. The results are invented to demonstrate the recordkeeping, not measurements from a product test.

Case	Expected Behavior	Build 501 Result	Build 502 Result
RST-01: Valid unused token	Permit the password change and invalidate the token afterward	Passed	Passed
RST-02: Expired token	Reject the token without changing the password	Passed	Passed
RST-03: Consumed token	Reject another password change using the consumed token	Failed	Passed
RST-04: Unknown email request	Return the agreed generic response without account disclosure	Passed	Passed

Each case needs enough setup detail to reach its intended condition. RST-03 begins with an account and token whose first reset has already succeeded. RST-02 uses a token known to be expired under the approved policy. An arbitrary token that the application has never issued would test a different condition.

For both builds, assume a staging environment named Identity QA, the same recorded browser and operating-system versions, and a versioned fixture definition named reset-v3. These references establish the intended configuration. The run also records what was deployed and which isolated fixture instances were actually used.

Build 501: Record the Failure Against Its Execution

Create run RESET-501 for build 501 and select RST-01 through RST-04. Maya executes RST-01 and RST-02; Omar executes RST-03 and RST-04. Those assignments describe this run's work, not permanent ownership of the reusable cases.

In RST-03, Omar uses an already consumed token and observes that another password change succeeds. Record Failed against that case execution, retain the expected rejection and observed change, and attach suitable reproduction evidence. Link the defect to RESET-501 and the executed case revision so a reviewer can identify the affected build and check.

Avoid putting usable reset tokens or account secrets into broadly accessible screenshots and logs. Evidence should establish the starting state, relevant response and observed effect without exposing credentials. The reusable case should continue to require rejection; the failed result explains why the implementation needs attention.

Build 502: Retest With Fresh Results

After the fix is deployed as build 502, create RESET-502 with the same case selection and definitions. Omar now executes RST-01 and RST-02, while Maya executes RST-03 and RST-04. Changing the assignees does not require duplicating the cases or creating a new suite.

Restore the required starting states and provision fresh token instances. Reusing reset-v3 means reusing the fixture definition, not replaying a token consumed during the previous run. The practical distinction between restoring state and changing a dataset is developed in the guide to safe, repeatable QA data.

In this example, all selected checks pass on build 502. The new RST-03 result supplies confirmation that the previously observed defect no longer reproduces under the recorded conditions. Repeating the other checks provides focused regression evidence around the change. Broader regression scope still depends on impact analysis; a password-reset suite alone says nothing about unrelated application areas.

Keep the Failed result in RESET-501 and the Passed result in RESET-502. The fix changed the application, so the expected behavior and case revision can remain unchanged. A report can show the latest build as passing while still allowing someone to inspect the first failure, its defect and the later confirmation.

Track Case Versions, Suite Selection, and Run Evidence Separately

Reuse does not mean definitions never change. If the product later changes its token-expiration policy, review RST-02's setup and expected outcome. Record the updated case revision and its requirement reference. An older run must remain interpretable against the rule it tested, rather than appearing to have checked the new policy retroactively.

Suite membership can evolve independently. Adding a rate-limiting case to Password Reset Core changes the available grouping. It does not prove that either earlier run executed that case. Preserve each run's actual selection instead of reconstructing historical scope from today's suite contents.

Data and configuration add separate dimensions. A parameterized case can use several datasets while retaining one underlying definition. A browser or operating-system combination describes where an execution takes place. The values actually used, the observed response and the resulting status explain what happened. A case revision alone does not capture all of that context.

Check your tool's snapshot rules before relying on them. TestRail documents that closing a run archives its results and prevents future case changes from affecting that historical run. Its parameterization documentation also states that open runs retrieve current dataset values, with those values preserved when the run or plan closes. Creating a run therefore should not be assumed to freeze every specification and input in every product.

Establish the preservation procedure before execution begins:

1. Record the selected case identities and revisions, or the equivalent controlled specification reference your tool supports. Retain the actual selection when it comes from a changing filter.
2. Identify the application build, environment, configuration and dataset version. Capture relevant actual input values or protected references when a version label is insufficient to reproduce the condition.
3. Record results, execution times, the person or runner responsible, evidence and related defects against the appropriate attempt.
4. Close or archive the completed evidence according to the tool's documented behavior and your retention policy. Check that later edits cannot silently change what the record appears to prove.

Where a system permits another result inside an existing run, retaining individual attempts and their context is still necessary. A new run per build makes the example easy to compare, but the required property is traceable execution history, not a universal rule about which button to press.

Count Executions Without Inflating the Case Library

The example contains four reusable case definitions. Each run selects four case executions, giving eight executions across the two builds. It does not contain eight independently maintained test cases.

Build 501 has three passing results out of four selected executions, or 75%. Build 502 has four out of four, or 100%. Combining both runs gives seven passing results across eight historical executions, or 87.5%. That combined figure describes the selected history; it is not the pass rate of build 502 and should not be displayed as though it were.

A partial rerun needs a different reading. If RESET-502 selected only the previously failed RST-03 and it passed, the evidence would be one passing confirmation check on build 502. It would not establish that all four checks passed on that build. A dashboard that carries forward earlier results needs to label their build and origin clearly.

Configuration can multiply the execution count too. Selecting all four cases for two browser configurations creates eight configured executions for one build while retaining four definitions. Report whether the denominator counts unique cases, case-and-configuration combinations, all attempts or each execution's latest result. Also state how Blocked, Skipped and unexecuted work are treated rather than silently excluding them.

A pass rate measures outcomes within its stated scope. It does not show that every requirement was covered, that the case selection was adequate, or that a release is ready. Review unresolved defects, excluded risks and missing configurations beside the rate.

Apply the Distinction in a Jira-Based Workflow

In Jira, separate delivery work from the test-management model supplied by your app or configured process. A work item representing a testing task does not by itself establish reusable case specifications, suite membership and historical execution results. Jira work-item status and a test outcome can answer different questions.

Sherlock Test Management provides a relevant app-specific example. Its current product description distinguishes an approved, versioned reusable baseline from a release-specific run containing selected scope, assignments, results and linked defects. It describes proposing scope from a Jira Fix Version for team review, and keeping a finished run attached to the baseline version it executed. Those are Sherlock capabilities, not a claim that Jira natively implements the same entities.

For the password-reset change, that separation would let the team review which approved cases belong in the release scope and assign execution without replacing their reusable definitions. The Sherlock product workflow describes recording Pass, Fail or Blocked in its Runner or supported Jira panels. Its AI-generated additions and edits remain proposals until accepted; that review workflow is different from an AI agent autonomously executing the application. Verify the relevant app behavior in your environment before relying on it for retention or reporting.

Decide Whether to Edit a Case, Change a Suite, or Start a Run

When the intended behavior or required setup changes, review the case definition. When the testing objective or risk scope changes, review the grouping and selected membership. When another build, configuration or retest needs evaluation, create the appropriate execution record and collect fresh evidence.

Before your next release, inspect a previously failed check that later passed. You should be able to recover the original expectation, executed revision, affected build, actual failure and subsequent confirmation without guessing from today's suite. If those records are missing, repair the separation between reusable specifications and execution evidence before adding more copied cases.