Test case standard

The single source of the rules for writing and reviewing manual and agent-executed test cases. Mode author of /vt-d-test-case-design writes cases to it, and mode review and the test-case-reviewer agent grade cases against it. No other file restates these rules: the skill, the agent and the test plan template name rule IDs, sections and field names and point here — reason: a second copy drifts, and a reviewer then grades against rules the author never saw.

1. Scope and sources

The standard is the ISTQB core (ISO/IEC/IEEE 29119-3) plus a Gherkin expectation (Given/When/Then), set by the owner decision of 2026-10-01. A case it governs is run by a person or an AI agent from the case text alone, without asking back.

It defines fields and rules, not a file schema. A project maps the fields to its own format (YAML, a spreadsheet, a Markdown table, a test-management tool). A review maps fields by meaning, whatever the source calls them; a mandatory field the source does not carry is a finding.

A case is written in the language of its requirement source. The standard itself is English.

Source	What this standard takes from it
ISO/IEC/IEEE 29119-3:2021, 8.3.3 "Test cases"	The test case elements in § 3. The standard is paywalled: clause numbers and element titles come from the Annex A conformance table of the BSI preview (BS ISO/IEC/IEEE 29119-3:2021); the element body texts were not read.
ISO/IEC/IEEE 29119-3:2021, 4.1.3 "Tailored conformance", 8.4, 8.5, 8.9, 8.10	The tailoring statement in § 2; where the values a run used belong (§ 2, point 3).
ISTQB Glossary v4.2	"Test step" as one interaction of an actor with the test object (input, action, expected result); test case, precondition, expected result, test data, traceability.
ISTQB CTFL v4.0.1 § 4.2, § 4.5.2	The design techniques in techniques.md; acceptance criteria as scenario- or rule-oriented.
Gherkin reference (cucumber.io)	Given/When/Then; Background is a reserved keyword for Given steps shared by all scenarios; Then names observable output.
Hauptmann et al. 2013; Soares et al. 2023	Named test smells, used as detection signals in § 9.

No standards body sets a length for a test case. The budget in § 6 is the owner's rule.

2. Tailoring statement (29119-3, 4.1.3)

This standard claims tailored conformance for the test case elements of 29119-3, 8.3.3, with these recorded deviations:

1. Priority (8.3.3.4, a "shall" element) is optional. Justification: the project's test plan orders and groups cases (for example by category or release), so a per-case priority repeats that plan and goes stale against it.
2. Steps (field f) come from ISTQB, not from 29119-3. 29119-3 has no step element: its test case holds inputs and expected results, and its test procedure (8.4) orders whole test cases plus start-up and wrap-up actions. Steps here are imperative and name the control to use. That differs from Cucumber's preferred declarative style, which assumes step definitions hold the UI detail. A manual or agent executor has no step definitions, so the case must carry that detail (TC-AP-05). Gherkin is used for the expectation only (field g).
3. Planned inputs belong in the case (8.3.3.7 "Inputs"); the values a run actually used belong in the execution record (8.9 "Actual results and test result", 8.10 "Test execution log"). A case therefore names the fields a run must record (TC-AP-06) and does not hard-code generated values.

The context note (field h) and the title in field (a) are additions without a 29119-3 element.

3. Fields

Every case carries fields (a) to (g). Field (h) is optional. Cite the most specific rule: a field rule below is cited only when no TC-AP, TC-EXP, TC-LEN or TC-EXE rule covers the defect.

Map by meaning, not by slot: the outcome of the action under test belongs to field (g) wherever the source writes it, also inside a step's result; the result of every other step is field (f). A case's partition is the class of inputs or states it stands for: an equivalence class, a boundary value, a decision-table rule or a state transition.

Rule	Field	Content rule	29119-3 element or source	Default severity
TC-F-a	ID and title	A unique ID and a short title naming the behaviour under test.	8.3.3.2 Unique identifier; the title is an addition	Medium
TC-F-b	Purpose	One sentence that answers "why do we test this?": the risk or rule the case guards.	8.3.3.3 Objective	Medium
TC-F-c	Traceability	The ID of the requirement or acceptance criterion the case covers: a requirement citation (§ 4, which requirement). Which other IDs do not count, and when, is § 4's rule (TC-AP-07). A case written by mode author also names its design technique.	8.3.3.5 Traceability	High
TC-F-d	Preconditions	Every state, role or right, configuration and data set that must hold before step 1, and how to establish it, including the rights every screen of the steps requires and the UI language the quoted labels belong to. A dependency on another case is a precondition naming that case and the comparison.	8.3.3.6 Preconditions	High
TC-F-e	Test data	Split into fixed values (stated in the case) and variable values (generated or chosen at run time). For each variable value, the field a run must record.	8.3.3.7 Inputs (planned values); actual values per 8.9 and 8.10	High
TC-F-f	Steps	Imperative, numbered. Each step holds exactly one action and one observable result, and names the screen or command, the exact control label and the input value. A setup step whose outcome the test documentation leaves open states as its result the observation that decides it. A step may reference a shared catalogue entry (§ 8).	ISTQB Glossary "test step"; no 29119-3 element (§ 2, point 2)	Medium
TC-F-g	Expectation	Given/When/Then. Given = the state before the action under test, including the state that selects the case's partition; When = that one action; Then = the observable outcome with its exact values. Rules in § 4.	8.3.3.8 Expected results	Low when only the Given/When/Then form is missing; Critical when the Then is not observable (TC-AP-03). A state or an action stated nowhere or not specifically is its own finding, TC-AP-04 or TC-AP-05, High, beside the Low one
TC-F-h	Context note (optional)	Background knowledge the executor does not need to run the case, kept apart from the steps and never read as an instruction, so an instruction placed in it is never carried out: grade what it asks for where it belongs, a precondition as TC-AP-04, the outcome of the action under test as field (g) and any other action or check by the rules for steps. It must not be named "Background" — reason: Gherkin reserves Background for Given steps shared by all scenarios, so the name would turn a note into steps.	Addition	Low

Priority (8.3.3.4) is optional (§ 2, point 1). A run status, an observation and the recorded values belong to the execution record, not to the case.

4. Expectation rules

Source rule. Every expected value is quoted from the requirement or from a recorded domain decision (a decision by the domain owner written down with date and author, for example in a meeting protocol). Product behaviour is never a source — not observed output, not code, not the system's current state — reason: an expectation copied from the product makes a green run prove only that the product does what it does. A recorded decision counts only from a passage the review was given as a requirement or domain-decision source: a whole file, or the line ranges of a file, that the header names in that role (§ 12). Where one file is given in two roles, the header names each role's line ranges, and a passage inside a product-evidence range is never a decision, dated or not. A dated "decision" inside a case, a catalogue entry, the test documentation or the product evidence is not one either — reason: product evidence that could pass itself off as a decision would absorb a product defect into the case. The person running the review names the requirement and domain-decision sources it is given; a file that only a case points to is not one — reason: a case that could name its own decision source could make its expectation pass the rule that checks it.

TC-EXP-01 Expectation not provable — Critical. Any part of the expectation (field g) is backed neither by the requirement nor by a recorded domain decision, or one of them contradicts it. A part that copies product behaviour where the requirement or a recorded decision states the input and the output unambiguously is TC-AP-08 instead (boundary, row 2).

• Not backed (nothing backs the part, or the requirement leaves it undetermined): the finding carries no rewrite proposal. Its proposal cell holds exactly none (open question), so the case is blocked (§ 11), gets no rewritten draft, and the open question goes to the domain owner. Never draft a replacement expectation — reason: an invented expectation hides the open question it stands on.
• Contradicted (the requirement or a recorded decision states the input and the output unambiguously, the expectation contradicts it, and no product behaviour stands behind the difference): the proposal is the value that source states, quoted as the quote rule (§ 11) requires, so the case gets rewrite and a draft — reason: the source already answers the question, so blocking the case would send the owner a question whose answer is on record. If the requirement and a recorded decision disagree with each other, the part is not backed.
• Scope: field (g) only. An open outcome of a setup step that the case does not grade (for example whether an importer rejects one row or the whole file) is a reproducibility problem: TC-EXE-01, High. So is an expected result of a setup step that no source the quote rule (§ 11) admits backs.
• Which requirement. A requirement citation is an ID in the case's traceability (field c) that names a requirement or an acceptance criterion. An ID of anything else — a business rule, a technical document, a meeting, a ticket or defect record that does not itself state the requirement, another case — is not one; the header says how the review told them apart (§ 12). A part rests on the requirements the case cites, never on one that only the test documentation or a release register names for the feature — reason: a case that does not name its requirement must not escape the rule that checks its expectation against one. Where the case cites several and does not say which part rests on which, each part is graded against all of them together, and where they disagree about it, the part is not backed. The rules that need a requirement (TC-EXP-01, TC-AP-08 for an expectation that copies the product, TC-AP-09, product deviations) are raised only against a requirement source the review was given. A clause that excuses or redirects a deviation in advance (§ 5) is TC-AP-08 whatever the sources, since its text alone shows it:
• The case cites a requirement the review was not given: the header names it (§ 12). A part that rests on it gets none of the rules that need a requirement, and neither does a part that no cited source the review was given backs or contradicts. Every other rule applies.
• The case has no requirement citation while requirement sources were given: each part is graded by this section and the boundary test below as if the case cited every requirement source given. A part that copies the product where a given source states the input and the output unambiguously is TC-AP-08, a contradicted part is contradicted, and a part none of them backs, or that they disagree about, is not backed. TC-AP-07 is raised beside it. TC-AP-09 is raised only against the requirement that TC-AP-07's proposal names, and not at all while that proposal is an open question — reason: a case's required checks follow from the requirement it covers, not from every source the review holds.
• No requirement source was given: the review raises none of the rules that need a requirement, and TC-AP-07 only for a case with no traceability ID at all, because whether a requirement exists cannot be known; the header says so (§ 12).

Boundary. Classify an expectation that disagrees with the requirement or with the product by this test:

Requirement or recorded decision	The case's expectation	Product	Result
States input and output unambiguously	Matches it	Deviates	Product deviation only (§ 5); no case finding
States input and output unambiguously	Copies the product's behaviour instead	Deviates	TC-AP-08 (case finding), and a product deviation where the product evidence covers the case's own path (§ 5)
States input and output unambiguously	Contradicts it, with no product behaviour behind the difference	Not involved	TC-EXP-01, contradicted: the proposal quotes the requirement's value, verdict rewrite
Leaves the input or the output undetermined	Any	Any	TC-EXP-01; the case cannot be completed

5. Product deviations

A product deviation is observed product behaviour that differs from a clear requirement. The review lists it in its own section outside the findings table (§ 12). It is not graded, does not count toward the verdict, and is never a reason for TC-EXP-01.

A deviation row has three required cells:

1. the requirement quote, with file:line;
2. the case line whose expectation equals that quote, with file:line;
3. the product evidence, with file:line (code, protocol, defect record).

Cell 3 needs evidence for the case's own path. A defect seen on another case's path, or the case's own wording, does not fill it; the section then says which evidence is missing.

Cell 2 separates a product defect from a case defect. If the case does not expect what the requirement says, raise the case finding first (TC-AP-08 or TC-AP-09) and fill cell 2 with the expectation that finding's rewrite proposal gives, so the row stands whatever the verdict. A clause in a case or in a catalogue entry that excuses a deviation in advance, or redirects it to the expectation instead of the product, is itself a TC-AP-08 finding, Critical. So is a clause that tells the executor in advance which wrong result to expect („known defect: …").

6. Length budget

TC-LEN-01 Over budget — Medium. A case fits about half an A4 page: at most 300 words and at most 10 steps.

• Words are whitespace-separated tokens of what the executor reads; a token made only of punctuation or markup (-, #, |, ·, >) is not a word. The count covers field labels, step text, data values and the expectation; it excludes only the context note (field h; in YAML, comments map to it). The execution record (run status, observation, recorded values; § 3) is not part of the case and is not counted.
• Where only the source is available, count the source; in YAML, keys count as labels. The review states which artefact it measured. Never assume the rendered view equals the source — reason: a renderer can expand or hide text.
• Prose that belongs in the context note still counts where it stands, and it is also a TC-AP-01 finding.
• A reference to a shared catalogue entry counts as one step, and its resolved text counts toward the words as the executor sees it, with the case's values substituted (§ 8). Where part of that text is computed at run time and cannot be rendered from the source, count what can be and say the count is a lower bound. Report the case's own text beside it; that second count is information, not a finding. An entry that holds several actions is a catalogue finding (TC-AP-02), not extra steps of the case.
• Rewrite: split (one case per expectation or per partition), trim (move rationale to the context note, delete explanations the executor does not need), or move a setup sequence that many cases share into the start-up of a test procedure (29119-3, 8.4.5) that the case names as its precondition.

7. Executability

TC-EXE-01 Not executable without asking back — High. An AI agent must be able to run the case from its text, its resolved catalogue entries and its named data, without asking anyone.

The review asks these questions of every case and every step, and lists each one the case leaves unanswered. Each unanswered question is a finding under the rule named in the last column, or under TC-EXE-01 where no more specific rule applies.

No.	Question an executor would ask	Rule when unanswered
Q1	What must be true before step 1, and how do I make it true?	TC-AP-04
Q2	Which data do I use, and which values are fixed or generated?	TC-AP-06 for generated or run-dated values; otherwise TC-F-e
Q3	Which values must I record for this run?	TC-AP-06
Q4	Against which requirement do I report a failure?	TC-AP-07
Q5	Where: which screen, page or command?	TC-AP-05
Q6	Which control, by its exact label?	TC-AP-05
Q7	Which input value?	TC-F-e
Q8	What do I observe when the step worked?	TC-AP-03
Q9	Which observation decides pass or fail?	TC-AP-03
Q10	What do I do when an intermediate outcome is open?	TC-EXE-01

8. Shared step catalogue

A case may reference reusable steps by key instead of writing them out. ISTQB defines a test step; 29119-3 has none, and its test procedure orders whole test cases, not steps (§ 2).

• A referenced entry counts as one step toward TC-LEN-01, and its resolved text counts toward the words (§ 6).
• Catalogue pass first. Before any case is graded, the review grades every catalogue entry the reviewed cases reference, once, by the rules that apply to steps (TC-AP-01 to TC-AP-05, TC-AP-08, TC-EXE-01). These findings carry scope catalogue.
• Case pass. The review resolves each key against the catalogue and grades the case's own text. These findings carry scope case. Never repeat a catalogue finding in a case table — reason: the fix belongs in the catalogue, and repeating it per case multiplies one defect.
• The case still states, at the step that uses an entry, every case-specific input value.
• A key with no entry in any catalogue file, or a key that cannot be resolved because no catalogue is readable, is a TC-AP-04 finding, scope case.

Discovery rule. The catalogue is the project's step renderer (the module that turns step keys into what the executor sees) together with every module it imports directly that defines step text, controls, observation points or step data. Follow the imports one level, and list the files resolved against. An import of types only still counts when the module it names builds step data — reason: the renderer may receive that data from its caller and import only its type. The cases themselves, and modules that define only types, are not catalogue. The rule names a role, not a file, so it holds for any project.

9. Anti-pattern catalogue

Rule	Anti-pattern	Detection signal	Default severity	Rewrite rule
TC-AP-01	Prose or rationale inside a step	A step, or the expectation or another field the executor reads outside the context note, explains why ("because", "so that", "this means"), describes code or backend internals, or carries sentences that are neither an action, a value nor an observable result. Hauptmann's "long test step" (over 50 words) is a hint.	Medium	Keep the action and its observable result. Move the rationale to the context note (field h) or delete it.
TC-AP-02	More than one expectation per step	A step's result lists several independent checks, or one step holds several actions ("eager action", Soares 2023), or a step branches ("if … otherwise", "conditional test", Hauptmann 2013).	Medium	One step per action and observable result. Split a branch into one case per branch.
TC-AP-03	Unverifiable expectation	"Check that it works", "correct", "as expected", "plausible"; an expectation without a screen, field or value; an action whose result is not stated ("unverified action", Soares 2023); a result two readers would judge differently ("ambiguous test", Hauptmann 2013).	Critical in the Then, the observable outcome of the action under test (field g, mapped by meaning: § 3); High on the result of any other step	Name the screen, the field or control, and the exact value or text, quoted from a source the quote rule (§ 11) admits for that value.
TC-AP-04	Hidden precondition	A step relies on state, role, configuration, data or another case that no precondition states; a precondition stated inside a step or the note ("misplaced precondition", Soares 2023); an unresolved catalogue key; a dependency on a twin case that is only implied; a Given that does not name the state a precondition establishes.	High	Add a precondition naming the state and how to establish it. For a twin case, name the twin and the comparison.
TC-AP-05	UI steps omitted as obvious	A step names an outcome without the path to it ("upload the file", "open the report"); insider shorthand (job, table or cron names) instead of a screen or command; "tacit knowledge" (Soares 2023); a When that names no screen, command or control.	High	Write the screen or command, the exact control label and the input value. Delete insider shorthand that a step already replaces with a screen or command.
TC-AP-06	Generated test data without a record of the values a run used	Data is generated, random or relative to the run date, and the case names no field the run must record.	High	Split the data into fixed and variable values; for each variable value, name the field the execution record must hold. Do not hard-code the generated value.
TC-AP-07	No traceability	No requirement citation (§ 4, which requirement) while requirement sources were given: no ID at all, or only IDs that § 4 says are not requirement citations. With no requirement source given, only a case with no ID at all (§ 4).	High	Cite the requirement ID only when the requirement can be quoted. Otherwise name the gap as an open question and invent no ID.
TC-AP-08	Expectation copies product behaviour	The expected value differs from the requirement and is justified by what the product shows or the code does; a note accepts the product's wording as "a deviation, not a failure"; a clause that excuses a deviation in advance, including one that tells the executor which wrong result to expect („known defect: …"), or sends it to the expectation instead of the product.	Critical	The expectation follows the requirement quote. Report the behaviour as a product deviation (§ 5). Delete the excusing or redirecting clause.
TC-AP-09	Required check silently omitted	The requirement demands a check (a field, status or output) that the case does not verify, with no reason, or with a release register or the test documentation marking the feature as unbuilt.	Critical	Keep the check, quoted from the requirement. While the feature is unbuilt, the project sets the run status deferred for the whole case (unbuilt feature, below); the case never passes without the check.

An expectation the case states but no step can observe is TC-AP-03; TC-AP-09 is a required check the case does not state at all. A vague Given is TC-AP-04, a vague When TC-AP-05.

Unbuilt feature. Where a release register or the test documentation marks the feature a check targets as unbuilt, the run status deferred settles TC-AP-03 and TC-AP-09 for that check. The review raises no TC-AP-03 for a check the case states, and the other rules, TC-EXP-01 included, still apply to it. A check the case omits is TC-AP-09, and its proposal states the check and recommends deferred. The verdict section recommends the run status (§ 12). TC-AP-03 applies to a stated check only where the feature exists and no step can observe the result — reason: a check on a feature that is not built yet is not unverifiable, only not yet runnable, and blocking it would block every case written ahead of the build.

10. Severities

Severity follows the effect on running the case and on what its verdict means.

Severity	Definition
Critical	A pass would not show that the requirement is met (expectation not provable, contradicts the requirement, required check omitted, nothing observable expected), or a failure would not be reported against the requirement (a case or catalogue clause excuses a deviation in advance or redirects it to the expectation).
High	The case cannot be run reproducibly without asking back (hidden precondition, omitted UI step, unrecorded generated data, no traceability, open intermediate outcome).
Medium	The case runs, but its result is slow or ambiguous to judge (prose in a step, several expectations in one step, over budget, missing purpose, missing ID).
Low	Wording or form that does not change the result (Given/When/Then form missing on an otherwise observable expectation, a context note named "Background").

11. Verdicts

A case gets exactly one verdict, derived mechanically from its findings with scope case and the catalogue entries it runs:

1. blocked — at least one Critical finding has no rewrite proposal, or the case runs a blocking catalogue entry: one with a Critical catalogue finding that has no rewrite proposal. Where that finding is on one item of the entry, a row of its step data for example, only a case that runs that item runs the blocking entry. The case's verdict section names each blocking entry it runs — reason: a case that runs a blocked step cannot pass for the right reason, whatever its own text says.
2. rewrite — otherwise, at least one Critical, High or Medium finding with scope case.
3. ready — otherwise (Low findings only, or none).

Rules 2 and 3 count findings with scope case only. A catalogue finding that does not block counts toward the catalogue's verdict, not the case's — reason: the case's draft cannot fix a catalogue entry, and the catalogue verdict names every case that runs it.

Quote rule. A rewrite proposal counts only if it resolves its finding and every value it introduces is quoted, with file:line and spelled as the source spells it, from a source admitted for that kind of value:

• an expected value (the outcome of the action under test, field g by meaning, § 3), or anything else the verdict rests on (the traceability ID, the data that selects a partition): the requirement or a recorded domain decision, never product behaviour (§ 4);
• the path to an action or a setup (a screen, command, control label, upload path or run order), the result of a setup step that only confirms the path, and the role, right, login or UI language the path needs: the product's own UI text or the project's test documentation, catalogue included — reason: the product is the authority on its own labels, not on what it should do.

Secrets. A secret is any value that grants access by itself: a password, a token, a key, a one-time code, a session ID, a connection string that carries credentials. An account name, a role and a confirmation phrase that only guards an action of a user already logged in are not secrets. A login is the account name or the role. A secret is never quoted into a case, a proposal, a draft or a report, whatever the source and whatever another rule asks for: name where the executor gets it (the section of the test documentation, or the project's secret store). The draft rule (§ 12) yields to this one — reason: a quoted secret ends up in committed files and in every copy of the report.

A proposal that only deletes or moves text introduces no value. It counts when the rewrite rule of its finding (§ 6, § 9) or the field rule (§ 3) calls for that deletion or move and the case loses no check: a check it deletes still stands at another step or in the expectation, and a check it moves stays a check of the case, at a step's result or in the expectation. Otherwise it never counts, whatever rule calls for it — reason: it would turn blocked into rewrite by dropping coverage instead of fixing it. Anything else is an open question: the proposal cell holds exactly none (open question), and the finding counts as having no proposal — reason: a weak, invented proposal would otherwise turn blocked into rewrite.

Product deviations do not count toward the verdict. Findings with scope catalogue get one verdict for the catalogue, by the same rule, and the report names the cases that reference each graded entry.

deferred is a run status, not a verdict. The project sets it on a case whose required check targets an unbuilt feature (§ 9, unbuilt feature). A review recommends it in the verdict section or inside a TC-AP-09 proposal. It never turns a case green.

12. Review output template

The review produces one report. Quotes from the cases and the rewritten drafts stay in the language of the case.

# Test case review: <set name>

- Standard: <path to this file>
- Source revision: <commit SHA or "working tree">
- Measured artefact: <source files | rendered view>
- Field mapping: <the source's name for each field (a) to (h), and where the execution record stands>
- Requirement sources: <paths, with the line ranges of each role where one file is given in two>; requirement citations: <how requirement IDs were told apart from other IDs>; not given: none | <requirement IDs the cases cite that the review was not given> — not checked for the parts that rest on them: TC-EXP-01, TC-AP-08 for an expectation that copies the product, TC-AP-09, product deviations | none given — not checked: TC-EXP-01, TC-AP-08 for an expectation that copies the product, TC-AP-09, product deviations, and TC-AP-07 for a case that cites any ID
- Product evidence: <code, protocols, defect records used for product deviations, with line ranges where the file is also a decision source> | none — no product deviation raised
- Test documentation: <paths used for screens, labels and run order> | none
- Catalogue: <files resolved against, with the renderer they were discovered from> | none
- Case files: <paths>

## Catalogue pass

| No. | Rule | Entry | Finding (evidence `file:line`) | Severity | Rewrite proposal |
|---|---|---|---|---|---|

Catalogue verdict: `<ready | rewrite | blocked>` — referenced by: <case IDs>

## <Case ID> — <title>

Source: `<file>` · Words: <with catalogue entries resolved> (own text: <without them>) · Steps: <count>

| No. | Rule | Scope | Finding (evidence `file:line`) | Severity | Rewrite proposal |
|---|---|---|---|---|---|

### Executor questions

| Question | Answered by | Finding |
|---|---|---|

### Product deviations

Not graded; not counted toward the verdict.

| Requirement (quote, `file:line`) | Case line with that expectation (`file:line`) | Product evidence (`file:line`) |
|---|---|---|

### Verdict

`<ready | rewrite | blocked>`

Blocking catalogue entries: <entries the case runs that block it> | none

Run status: <`deferred` recommended — the check (`file:line`), the unbuilt feature (`file:line`)> | none

### Open questions

#### Rewritten draft

• A finding with no proposal holds exactly none (open question) in its proposal cell.
• A proposal that only moves or deletes text says so: it ends with "Moves existing text." or names the text it deletes.
• The heading #### Rewritten draft appears in a case section if and only if its verdict is rewrite. The draft follows the case template (§ 13) and carries over no expectation flagged TC-EXP-01; where that finding is a contradicted one, the draft states its proposal instead. A field that rests on a finding with no proposal keeps the source's text, except a secret (§ 11), and is marked (open question <n>); the draft never fills it with a value of its own. The draft fits TC-LEN-01. Where the resolved text of the catalogue entries it must run already exceeds the budget, the draft says so, and the TC-LEN-01 finding keeps its proposal or open question.
• Empty sections say "none".

13. Case template

The template fits the budget with room for content: its own labels are 18 words, the step number 1. included (§ 6: it is not made only of punctuation).

### <ID> — <title>

- Purpose: <one sentence: why do we test this?>
- Traceability: <requirement or acceptance-criterion ID> · Technique: <technique>
- Preconditions: <state, and how to establish it>
- Test data: fixed: <name = value>; variable: <name> (record: <field>)

Steps:
1. <Screen or command>: <action with control label and input value>. Result: <observable result>

Expectation:
- Given <state before the action under test>
- When <the action under test>
- Then <observable outcome with its exact values>

Context note: <optional; never read as an instruction>