·
12 min
Test case: ISTQB definition, template and examples
Roman Kirchmeier - Autemos
A test case, according to the current ISTQB glossary, is a set of preconditions, inputs, actions, expected results and postconditions, developed based on test conditions. Each one fixes how a single testable aspect gets checked and which result must appear. Many pages still quote an older wording that names a test objective as the basis. In practice: first decide what to test, then write down data, steps and an expected result. Banks add a link back to the requirement, which you organize in test management.
TL;DR: A test case, per the ISTQB glossary (Version 2), is a set of preconditions, inputs, actions, expected results and postconditions, developed based on test conditions. Test analysis decides what to test; test design decides how. The CTAL-TA syllabus 4.0 lists 9 quality criteria, including precision, necessity and conciseness.
Figure 1: The test case in the ISTQB chain from test basis to test suite
What is a test case according to ISTQB?
A test case is a documented unit of testing that bundles preconditions, inputs, actions, expected results and postconditions, derived from a test condition. Glossary Version 2 reads: “A set of preconditions, inputs, actions (where applicable), expected results and postconditions, developed based on test conditions.” (ISTQB Glossary, test case, 2026)
The widely quoted wording, “developed for a particular test objective”, is outdated. It circulates via unofficial glossary mirrors and from there into AI answers. The difference matters: a test objective such as “check payments” stays vague, and a test condition names exactly one checkable aspect.
The glossary defines a test condition as “A testable aspect of a component or system that is intended to be tested.” Synonyms are test situation, test requirement and test idea (ISTQB Glossary, test condition, 2026). The expected result is “The observable predicted behavior of a test item under specified conditions based on its test basis.” (ISTQB Glossary, expected result, 2026)
The five parts:
Preconditions: the state before the test, such as a logged-in test customer with a known balance.
Inputs: the test data the system works with.
Actions: the steps. The phrase “where applicable” shows that not every test needs UI steps.
Expected results: what must be observable after execution.
Postconditions: the state afterward, such as an unchanged balance and a logged-out test customer.
Where does test design sit in the ISTQB chain?
Test design creates the test case. It sits between test analysis, which decides what to test, and test implementation, which groups the designed cases into test procedures, test scripts and test suites. According to the CTFL syllabus 4.0.1, test analysis identifies testable features and defines prioritized test conditions; test design turns those conditions into cases and other testware (ISTQB CTFL v4.0.1, 2024).
Stage | ISTQB activity | Work product | Payments example |
|---|---|---|---|
Test basis | Input to test analysis | Requirements, user stories, specifications | Story “Daily limit for transfers” |
Test condition | Test analysis | Prioritized test conditions, e.g., acceptance criteria | Transfers above the daily limit are rejected |
Test case | Test design | Prioritized cases, test data requirements | Limit CHF 10,000, CHF 8,000 already sent, new amount CHF 2,000.05 |
Test procedure, test script | Test implementation | Test procedures, manual and automated test scripts | Log in, enter payment, approve, check balance |
Test suite | Test implementation | Test suites, test data | Payments regression suite |
The glossary defines a test procedure as a sequence of cases in execution order, plus setup and wrap-up actions (ISTQB Glossary, test procedure, 2026). Keeping these levels apart lets you reuse one case in several procedures. Our guide to the test plan covers how to fix scope, test levels and responsibilities up front.
Acceptance criteria are test conditions
The acceptance criteria of a user story supply the test conditions your tests are built from. In the syllabus's words: “acceptance criteria may be viewed as the test conditions that should be exercised by the tests.” (ISTQB CTFL v4.0.1, 2024)
It names two formats: scenario-oriented in the Given/When/Then style, and rule-oriented as a checklist or an input-output table. How to write criteria that lead to unambiguous tests is the subject of our guide to writing acceptance criteria.
What is the difference between a logical and a concrete test case?
A logical (high-level) test case describes which test condition gets checked under which circumstances, without fixed values; a concrete (low-level) one fixes exact inputs, data and expected values. The CTAL-TA syllabus 4.0 shows both with a discounted book order (first table row, ISTQB CTAL-TA v4.0, 2025).
Figure 2: Logical and concrete test case, book discount example (CTAL-TA 4.0)
Example | Logical | Concrete |
|---|---|---|
Book discount (CTAL-TA 4.0) | Order more than one book, with the order price resulting in a discount. Expected: discount is assigned. | Order books B1 ($10) and B2 ($20), total $30. Expected: 10% discount assigned, total price $27. |
Transfer limit, boundary reached exactly (illustrative) | A transfer that uses up the remaining daily limit exactly. Expected: order is accepted. | Daily limit CHF 10,000, CHF 8,000 already sent today, new transfer CHF 2,000.00. Expected: order accepted, remaining limit CHF 0.00. |
Transfer limit, boundary exceeded (illustrative) | A transfer above the remaining daily limit. Expected: rejection with a message. | Same starting state, amount CHF 2,000.05. Expected: rejection with limit message, balance and remaining limit unchanged. |
Per the syllabus, one logical case can become one or more concrete ones, and many are hybrid in practice. Logical cases suit early reviews with business analysts, before any code exists. You need concrete ones for execution, reproducible defect reports and any automation.
CHF 2,000.00 and CHF 2,000.05 sit right at the boundary. You find values like these systematically with equivalence partitioning and boundary value analysis.
Which fields belong in a test case template?
A practical template has nine fields: ID, title with objective, traceability, priority, preconditions, test data, steps, expected result and postconditions. According to the IEEE abstract, ISO/IEC/IEEE 29119-3:2021 “includes templates and examples of test documentation”; the second edition was published on October 28, 2021 and replaces the 2013 version (IEEE, 29119-3-2021, 2021).
The standard is paywalled. A specification under 29119-3 typically contains an identifier, objective, priority, traceability, preconditions, inputs and expected results (ISO/IEC/IEEE 29119-3:2021, 2021). The series has critics: in 2014, context-driven testers around the Association for Software Testing launched the “Stop 29119” petition against it (Wikipedia, ISO/IEC 29119, 2014).
Field | What goes in | Example TC-PAY-042 |
|---|---|---|
ID | unique, stable identifier | TC-PAY-042 |
Title and objective | what is checked, in one sentence | Transfer above the daily limit is rejected |
Traceability | requirement, acceptance criterion, risk | Story PAY-311, acceptance criterion 2, risk R-07 (limit bypass) |
Priority | derived from risk | high |
Preconditions | state before the test | Test customer C-017 logged in, daily limit CHF 10,000, CHF 8,000 sent today |
Test data and inputs | concrete values or a reference to a dataset | Amount CHF 2,000.05, payee IBAN from the test dataset |
Steps | numbered actions, one action per step | 1. Open payment entry; 2. Enter amount and IBAN; 3. Approve order |
Expected result | observable expected behavior | Rejection with limit message, no order in outgoing payments |
Postconditions | state after the test, cleanup | Balance and remaining limit unchanged, test customer logged out |
Without postconditions, changed test data stays behind and the next run starts in an unknown state. Without traceability, nobody can show why the test exists or which requirement goes untested if someone deletes it.
How do you write a test case step by step?
Every good test starts from a named test condition: you derive concrete values with a test technique, then record preconditions, steps and one unambiguous expected result. These eight steps get you there:
Figure 3: Eight steps from test condition to finished test case
Name the test condition. Write down in one sentence which aspect you check, such as a single acceptance criterion.
Pick a test technique. Derive values systematically with equivalence partitions, boundary values or decision tables.
Write the logical case. Title, objective and expected behavior, no fixed values yet.
Set concrete values. At most one invalid equivalence partition per case.
Describe preconditions and test data. So precisely that a colleague can set up the starting state without asking.
Write the steps. One action per step, in active voice, with no branches such as “if the dialog appears”.
Record the expected result and postconditions. Observable, with concrete values.
Add traceability, priority and a review. Link the requirement and risk, then have a second person read it.
Step 4 rests on a rule the German syllabus 4.0.2 added in section 4.2.1, which the English 4.0.1 does not contain. Invalid equivalence partitions should not be tested together in one case, so that one defect cannot mask another (ISTQB CTFL-Lehrplan 4.0.2, German, 2025).
An example: if one case contains an amount above the limit and an invalid IBAN, the system rejects the payment at the first error. Two separate cases would tell you whether the limit check works.
Positive tests first, then negative ones
Positive tests check intended behavior; negative tests check the reaction to invalid or unintended use. For acceptance test-driven development (ATDD), the syllabus sets the order: “After the positive test cases are done, the team should perform negative testing.” (ISTQB CTFL v4.0.1, 2024)
Section 4.5.2 says acceptance criteria should “Describe both positive and negative scenarios”. For which invalid inputs are worth testing and how to automate them, see our guide to negative testing with banking examples.
What makes a good test case?
A good test case meets the nine quality criteria of the CTAL-TA syllabus 4.0: correctness, feasibility, necessity, understandability, traceability, consistency, precision, completeness and conciseness. The syllabus warns: “Neglecting test case quality can lead to many problems, such as high maintainability costs, reduced comprehensibility, or execution delays.” (ISTQB CTAL-TA v4.0, 2025)
Figure 4: The 9 test case quality criteria per CTAL-TA 4.0
Five of the criteria depend directly on wording:
Precision: the case allows only one reading. The syllabus names terms to avoid: “suitable”, “as needed” and “several”.
Necessity: each one checks something no other one checks. “Duplicates should be avoided.”
Traceability: each one is “traceable to test conditions, requirements, and risks”.
Completeness: the attributes per ISO/IEC/IEEE 29119-3 are filled in, including test data and “a clear expected result”.
Conciseness: “Smaller test cases focused on a few coverage items are preferable.”
What does research show about smells in manual tests?
Hauptmann et al. studied more than 2,800 manual tests from 7 industrial test suites and described 7 smells: hard-coded values, long test steps, conditional tests, badly structured suites, test clones, ambiguous tests and inconsistent wording (Hauptmann et al., ICSE, 2013). Ambiguous tests and clones break the precision and necessity criteria head-on.
Soares et al. built a tool that finds these smells with 92% precision and 95% recall, and counted 13,169 occurrences. Of 24 test professionals surveyed, 80.7% agreed with the smell catalog (Soares et al., ESEM, 2023). A follow-up preprint found 8,386 smell occurrences in 973 natural-language tests, about 8.6 per test (arXiv preprint, 2024).
Alégroth et al. found 13 factors that affect GUI test maintenance at Siemens and Saab, test complexity among them. They reported that “frequent maintenance is less costly than infrequent, big bang maintenance” (Alégroth et al., IST, 2016).
How do test scenarios and the Definition of Done fit in?
A test scenario groups several cases into one user flow; the Definition of Done sets when an Increment counts as done and can require those tests to pass.
Term | Official source | Level | Example |
|---|---|---|---|
Acceptance criterion | ISTQB glossary, CTFL 4.5.2; not in the Scrum Guide 2020 | Test condition of a user story | Transfers above the daily limit are rejected |
Test case | ISTQB glossary, Version 2 | One check with data and an expected result | TC-PAY-042 from the template above |
Test scenario | No ISTQB glossary entry, industry usage | Flow across several steps or cases | Enter payment, edit it, a second person approves |
Definition of Done | Scrum Guide 2020 | Quality state of the Increment | Story tests executed, traceability up to date |
Test scenario: common term, no ISTQB definition
“Test scenario” has no entry in the official ISTQB glossary; a lookup on September 27, 2026 returned “Term not found” (ISTQB Glossary, 2026). The closest official terms are test condition and test procedure. The CTAL-TA syllabus 4.0 says “Scenario-based testing evaluates the test item's behavior in realistic scenarios”, with a main scenario, extensions and exceptions. See our comparison of test scenario vs test case for the full distinction.
Definition of Done: quality state of the Increment
The Scrum Guide defines it: “The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.” (Scrum Guide 2020, 2020). Acceptance criteria and a Definition of Ready do not appear in it. Our beginner's guide to the Definition of Done covers what belongs in one.
Why do banks need traceable tests?
Traceability proves which requirement was checked by which test, with which result and which defect. EU banks need that proof for ICT changes under DORA. The CTFL syllabus 4.0.1 describes traceability “between the test basis elements, testware associated with these elements (e.g., test conditions, risks, test cases), test results, and defects.” (ISTQB CTFL v4.0.1, 2024)
For financial entities in the EU, the Digital Operational Resilience Act (DORA) has applied since January 17, 2025. Article 9(4)(e) requires ICT change management policies so that all changes to ICT systems are “recorded, tested, assessed, approved, implemented and verified in a controlled manner” (Regulation (EU) 2022/2554, 2022). A test with a requirement ID, a version and a logged result is the smallest building block of that evidence.
A traceable test record contains:
the link to requirement, acceptance criterion and risk,
its version, and who changed it when,
every execution with date, environment and result,
the link to reported defects,
approval by an authorized person.
Our article on the traceability matrix shows how to keep these links audit-ready.
Can AI tools write test cases?
AI tools can draft tests, and the World Quality Report 2025-26 finds “test case design and requirements refinement now leading adoption” of GenAI in quality engineering. The report is a vendor survey by Capgemini, OpenText and Sogeti of more than 2,000 executives in 22 countries (World Quality Report 2025-26, 2025).
The numbers are mixed. 89% of respondents are piloting or running GenAI workflows (37% in production, 52% in pilots), and only 15% have scaled enterprise-wide. The average productivity gain is 19%, a third report minimal gains, and 60% name hallucination and reliability as a barrier (World Quality Report 2025-26, 2025).
Draft quality depends heavily on the input. In a preprint, LLM-generated high-level cases reached a macro-recall of 0.81 for a Bluetooth specification and 0.37 for a Mozilla specification (Masuda et al., arXiv preprint, 2025). Hasan et al. surveyed 26 practitioners; the primary challenge they reported was tying testing effort to business requirements (Hasan et al., MSR, 2025).
Autemos, the AI-assisted test automation software by selementrix GmbH in Baar, Switzerland, starts at exactly that point. The Autemos AI Recorder drafts an executable test workflow from a Jira ticket, a user story or a plain-text test description. Every AI-generated step must be approved by the team before it runs. Web tests export as Playwright code (Java or TypeScript) and mobile tests as Appium (Java); the exported tests run without Autemos.
Autemos does not write acceptance criteria and does not decide your Definition of Done; it turns existing stories, criteria and cases into executable tests with human approval. It syncs cases and executions both ways with Jira/Xray, and an audit trail records changes.
Frequently asked questions
What goes into a test case?
A test case holds preconditions, inputs, actions, expected results and postconditions, per the ISTQB glossary. In practice you add an ID, a title, a priority and a link to the requirement or acceptance criterion.
What is the difference between a test case and a test scenario?
A test case checks one test condition with defined data and an expected result; a scenario is a longer flow spanning several such checks. “Test scenario” is not a term in the official ISTQB glossary (as of September 27, 2026); it is industry usage.
How long should a test case be?
A single test should cover only a few coverage items; the CTAL-TA syllabus 4.0 (2025) prefers smaller, focused ones. It sets no fixed number of steps. Long test steps are one of the 7 smells of manual tests in the study by Hauptmann et al. (2013).
Is there an official template?
ISO/IEC/IEEE 29119-3:2021 includes templates and examples of test documentation, among them a specification for individual cases. The CTAL-TA syllabus refers to its attributes for completeness; the template above shows the typical fields with an example.
Can a negative test combine several invalid values?
No: the German ISTQB syllabus 4.0.2 (2025) says invalid equivalence partitions should not be tested together in one case: the first error masks the second.
Conclusion
A test case, per the current ISTQB glossary, is a set of preconditions, inputs, actions, expected results and postconditions, developed based on test conditions. Good ones follow a fixed order: test condition, test technique, logical draft, concrete values, traceability.
The nine-field template and the nine CTAL-TA criteria set the standard for every review. Negative cases follow the positive ones and test one invalid partition each. In a bank, every test links to its requirement, results and defects. AI can deliver drafts; the team approves every step.
To see how your existing tests and Jira stories become approved, executable automation, talk to the Autemos team.
