Test case | ComplexQA Wiki

A test case is a description of one check of a product: the state in which the check starts, the actions performed, the expected results and the state after the check. The ISTQB glossary defines a test case as a set of preconditions, inputs, actions (where applicable), expected results and postconditions, developed based on test conditions.

The structure of a test case is described by ISO/IEC/IEEE 29119-3, the international standard for test documentation (current edition 2021), as part of the test case specification document. Before 2013 the same role was played by IEEE 829, the IEEE standard for software test documentation. In a test management system a test case is the central entity: test suites group test cases, test runs execute them, results and defects refer to them. The system as a whole is described in the article What is a test management system.

What a test case is for

A check that is not written down exists only in the head of the person who performs it. It cannot be repeated by someone else in the same way, it cannot be reviewed before execution, and its result cannot be compared with the result of the previous release.

A written test case solves these problems:

Repeatability. Two people who execute the same test case on the same version of the product obtain the same result, because the conditions, actions and expected results are fixed.
Review. Test cases are reviewed before execution, like any other work product. Errors in a test are cheaper to find in its text than in its results.
History. Every execution of a test case leaves a result. The results of one test case across releases show when a behavior changed.
Coverage. A test case is linked to the requirements or risks it checks. The links show what is covered by tests and what is not.
Regression. A set of test cases is executed again after changes to the product. Without written cases, regression testing depends on the memory of the testers.

Structure of a test case

The ISTQB definition lists the parts of a test case. Test management systems add an identifier, a title and attributes.

Identifier and title

The identifier is unique within the project and does not change when the test case is edited: results, defects and links to requirements refer to it. The title states what is checked, in terms of behavior: "Payment with an expired card is rejected" rather than "Payment test 3".

Objective and traceability

The objective states which test condition the test case checks. A test condition, in the ISTQB glossary, is a testable aspect of a component or system identified as a basis for testing. The objective is recorded as a link to a requirement, a user story, an acceptance criterion or a risk. These links are the basis of requirements traceability, described in the article Requirements traceability and coverage.

Preconditions

A precondition is the required state of a test item and its test environment before test execution. Preconditions include the version of the product, the configuration of the environment, existing data and the state of the user: "The user is signed in. The cart contains one item. A saved card with the expiry date 01/2025 is linked to the account."

A precondition is written so that it can be checked and established. "The system is in a normal state" cannot be checked. "The order list of the user is empty" can.

Steps and expected results

A test step is a single interaction between an actor and the test object: an input, an action and an expected result. An expected result is the observable predicted behavior of the test item under specified conditions, based on its test basis.

The expected result of each step is written so that the person executing the test can compare it with what is observed without interpretation. "The page works correctly" cannot be compared. "The message 'Card expired' is shown under the card field, the order is not created" can.

The example below is a test case with three steps:

No.	Action	Expected result
1	Open the cart and click "Checkout"	The payment page opens, the saved card is selected
2	Click "Pay"	The message "Card expired" is shown under the card field
3	Open the order list	The list is empty

Not every step needs its own expected result. A step that only prepares the next one ("Enter the amount 100") can be combined with the step whose result is checked.

Postconditions

A postcondition is the expected state of the test item and its environment at the end of the test case. Postconditions describe what remains after the test, such as created records or changed settings, and what has to be cleaned up so that the next test starts from a known state.

Test data

Test data are the values a test case uses: accounts, amounts, dates, files. They are written in the test case itself, in a separate table or in a referenced data set. Test data that depend on the environment (an account that exists only on one stand) are stated explicitly, otherwise the test case cannot be executed in another environment.

High-level and low-level test cases

The ISTQB glossary distinguishes two levels of detail. A high-level test case has abstract preconditions, inputs, expected results and actions: "Pay with an expired card". A low-level test case has concrete values and a detailed description of actions: the card number, the date, the exact text of the message.

High-level test cases are faster to write and leave room for the experience of the tester. Low-level test cases give the same result in the hands of any executor and are a direct basis for automation. The choice depends on the qualification of the testers, the risk of the area and the requirements of the project for repeatability and audit.

Atomicity

An atomic test case checks one test condition and has one reason to fail. The status of its result then has one meaning: "failed" points to one behavior.

A test case that checks several conditions at once ("registration, sign-in and password change") has several problems:

if the second check fails, the third is not executed, and its status remains unknown;
the status "failed" does not say which of the behaviors is broken;
coverage is overstated: one passed result is counted for three requirements, although only part of the case may have been executed.

Atomicity does not mean one step. A test case often needs several steps to reach the state in which the check is performed. What it means is one checked behavior, with the preceding steps as setup.

Parameterization

Many checks differ only in data: the same steps with different amounts, currencies or user roles. Parameterization separates the steps from the data. The test case is written once with parameters, and a data table lists the combinations:

Role	Amount	Expected result
Customer	100.00	The payment is accepted
Customer	0.00	The message "Enter an amount greater than zero"
Guest	100.00	The sign-in page opens

Each row of the table is executed and recorded as a separate result. A change in the steps is made in one place for all combinations.

In test automation the same approach is called data-driven testing: the test data and expected results are stored separately from the test script. Test frameworks support it directly. In pytest, for example, one test function is run for each set of parameters:

import pytest


@pytest.mark.parametrize(
    ("amount", "accepted"),
    [("100.00", True), ("0.00", False)],
)
def test_payment_amount(checkout, amount, accepted):
    result = checkout.pay(amount)
    assert result.accepted is accepted

How to choose the parameter values so that a small number of rows covers the significant cases is described in the series on test design: Equivalence partitioning and boundary values and Pairwise testing.

Priority

Priority defines the order in which test cases are executed when not all of them can be executed or when the most important ones are needed first. The ISTQB Foundation Level syllabus (version 4.0.1) names three common approaches to prioritization:

risk-based: test cases that check the highest risks are executed first;
coverage-based: test cases that achieve the highest coverage are executed first;
requirements-based: the order follows the priorities of the requirements set by stakeholders.

Dependencies between test cases also affect the order: a test case that needs data created by another is executed after it.

The priority of a test case is a separate attribute from the priority of a defect. The first is about the order of execution, the second about the order of fixing. The two are described separately in the article Defect report.

Life cycle statuses

A test case is a work product with its own life cycle: it is written, reviewed, used, updated and retired. Standards do not define a fixed set of statuses, and each system or team sets its own. A typical set:

Status	Meaning
Draft	The test case is being written and is not used in runs
In review	The test case is waiting for review
Active	The test case is approved and used in runs
Needs update	The product or the requirement has changed, and the test case no longer matches it
Deprecated	The test case is no longer used, but its results are kept

The status of a test case and the status of its result are different things. "Active" says that the description can be used. "Passed" or "failed" says what happened in one execution.

A test case is not deleted when it becomes obsolete. Its results belong to past runs and reports, and deleting it would change the history. It is moved to a final status and excluded from new runs.

Changes to a test case are versioned. A result refers to the version of the test case that was executed. Without this, a result from last year would point to steps that were written later.

Custom properties

Test management systems allow teams to add their own fields to a test case: custom properties. Typical examples are the component, the platform, the type of test (functional, performance, security), the automation status (manual, automated, to be automated) and the level of risk.

Custom properties serve three purposes: filtering when a run is assembled ("all active test cases of the Payment component for Android"), grouping in reports, and mapping data when test cases are transferred between systems. The last purpose is described in the article Migration between test management systems.

Test case and other forms of test description

A test case is one of several ways to describe a test. The table compares it with the forms most often used alongside it.

Form	What it fixes	Typical use
Test case	Preconditions, steps, expected results, postconditions	Repeatable checks, regression, audit
Checklist	A list of conditions to check, without steps	Experienced testers, quick regression, reviews
Test charter	The objective and scope of an exploratory session, without steps	Exploratory testing
Gherkin scenario	Behavior in the form Given / When / Then	Behavior-driven development, executable specifications
Automated test	Steps and checks as code	Regression in CI

A checklist and a test charter leave the actions to the tester. This makes them faster to write but less repeatable: two executions of the same checklist item can differ. A test case fixes the actions and gives the same result regardless of the executor.

A Gherkin scenario has the same parts as a test case: Given corresponds to preconditions, When to actions, Then to expected results.

Feature: Payment

  Scenario: Payment with an expired card is rejected
    Given the user is signed in
    And a saved card with the expiry date 01/2025 is linked to the account
    When the user pays for the cart with the saved card
    Then the message "Card expired" is shown
    And no order is created

An automated test is often written from a test case, and the test case remains as its description. The link between them is kept in the test management system: the result of the automated test is recorded as a result of the test case.

Terms

Term	Meaning
Test case	Set of preconditions, inputs, actions, expected results and postconditions, developed based on test conditions
Test condition	Testable aspect of a component or system identified as a basis for testing
Precondition	Required state of a test item and its test environment before test execution
Test step	Single interaction between an actor and a test object: an input, an action and an expected result
Expected result	Observable predicted behavior of a test item under specified conditions, based on its test basis
Postcondition	Expected state of a test item and its environment at the end of test case execution
High-level test case	Test case with abstract preconditions, inputs, expected results and actions
Low-level test case	Test case with concrete values and a detailed description of actions
Atomic test case	Test case that checks one test condition and has one reason to fail
Data-driven testing	Approach in which test data and expected results are stored separately from the test steps