In a TestRail- or Xray-class test case repository, what are the parts of one stored manual test case, and what does each part hold?
answer
- four parts, not one prose block
- title travels; body does not
- starting state lives above the steps
- each row pairs action with expectation
- template decides the field set
basics
~20 sA stored manual case has a title naming what is checked, a preconditions block giving the starting state, numbered step rows that pair each action with its own expected result, and attributes that classify the case.
solid answer
~50 sA stored case is a definition, not a record of a run. Four parts do the work. The **title** names the behaviour being checked and is usually the only part that appears in result lists, so it has to read on its own. **Preconditions** describe the state the environment, account and data must be in before step one, which is setup rather than verification. The **step table** is a numbered list of rows, each pairing one action with the expected result for that action, and that pairing is what lets a later reader see where things diverged rather than only that they did. Around the body sit **attributes**, the fields that classify, route and size the case. Which fields a case shows, and whether its body is a step table at all, is decided by the template it was created from.
go deeper
Be able to name the four parts and say what each holds, and to state plainly that the starting state belongs in preconditions rather than in the first numbered steps.
Explain why the steps are a table: numbering makes rows addressable, per-row expectations make each row self-checking, and row edits stay small and reviewable. Say what the template decides.
Show judgment about titles and setup: a title that reads alone in a failure list, and preconditions that stop two executors doing different work under the same definition.
Own the consequence at scale. The stored shape is what every report, coverage view and audit later reads, so a repository with inconsistent case anatomy cannot be summarised honestly whatever the tooling.
## A case is a definition, not a record A stored manual test case answers two questions for someone who did not write it: **what should I do, and what should I see?** It carries no outcome of its own. An execution points back at it and records what happened, which is why the same definition can be run in cycle after cycle and still mean the same thing. Everything about the shape follows from the fact that a case is read far more often than it is written, usually by someone with less context than the author had. ## The four parts | Part | What it holds | What breaks without it | |---|---|---| | **Title** | one line naming the behaviour under check | result lists read as bare identifiers, and nobody can triage them without opening every entry | | **Preconditions** | the starting state: environment, account, data, switches, and where the user already is | executors improvise setup, so two runs of "the same" case do different work | | **Step rows** | numbered actions, each carrying its own expected result | a divergence names the case but never the action inside it | | **Attributes** | the fields around the body that classify, route and size the case | the case can only be found by browsing the folder tree | The title deserves more care than it usually gets, because it is the part that travels. Execution lists, coverage views, reports and a link from a defect all show the title and not the body. "Checkout" is not a title. "Checkout rejects an expired card and leaves the basket intact" is one, because it survives being read alone in a list of two hundred. ## Why the steps are a table rather than a paragraph - **Addressable.** A row has a number, so a comment, a screenshot or an outcome can point at one action instead of at the whole case. - **Self-checking.** Each row carries the expected result for its own action, so the executor compares as they go rather than reaching the end and reconstructing what should have happened. - **Reviewable.** Inserting or editing a row is a small, visible change. Rewriting a block of narrative is not, and neither a reviewer nor the repository can show cleanly what moved. - **Ordered.** The numbering is part of the contract: row four is allowed to be terse because rows one to three have already happened. ## Preconditions are not step zero The commonest shape defect in a young repository is a step table whose first rows are "log in", "dismiss the banner", "open settings". Those rows are setup. They cost authoring effort, they are duplicated across every case in the folder, and they push the behaviour under test down to row five, where a hurried executor is already skimming. Preconditions are the place for them, and they are also the honest place for data requirements — "an account whose card expired last month" — that an executor otherwise has to invent, differently each time. The dividing line is simple: **if a row exists only to arrive at the interesting behaviour, it belongs above the table.** If arriving there is itself the thing being checked, it belongs in the table with its own expectation. ## The attributes around the body Around the title, preconditions and steps sits a set of fields. Some ship with the product, and its own filtering, saved views and export already understand them. Others are declared by an administrator for the project. Which fields a given case shows — and whether the body is a step table or a single free-text block — is decided by the **template** the case was created from, so a repository can hold a stepped case and a step-free one side by side without either looking malformed. ## Reading the case as an executor 1. Check the preconditions hold. If they cannot be made to hold, the case has not been run at all. 2. Work down the rows in order, performing exactly the action described. 3. Compare what happens against **that row's** expected result, not against a general feeling that the feature works. 4. Where the observation disagrees with the row, attach the disagreement and the evidence to that row. A stored case that supports all four of those is doing its job. One written as a paragraph of narrative with a single "it should work" at the end forces the executor to supply the missing structure from memory, and forces the next reader to guess what the author meant.
- Why is the title of a stored case worth more care than it usually gets?Because it is the part that travels. Execution lists, coverage views, reports and links from a defect show the title and not the body, so a vague one makes a list of failures unreadable and forces whoever triages it to open every entry. A good title names the behaviour and its expected outcome in one line.
- Why store the steps as numbered rows instead of one free-text block, if a human reads both the same way?Rows are addressable and editable. A number gives a comment, a piece of evidence or an outcome something specific to attach to, and inserting or changing one row is a small reviewable edit. A rewritten paragraph shows only that the text changed, not what moved, so review and history both get coarser.
saying these in an interview costs you the question
- Calls the whole case "the script" with no separation of setup
- Puts a single expected result at the end of the case
- Treats the title as an internal label nobody reads
- Writes environment and login setup as numbered steps
- Assumes attributes are optional decoration around the steps