Some entries in a manual test case repository have no numbered steps at all — what does that stored shape hold instead, and what do you give up by using it?
answer
- a template with no step table
- keeps identity, loses rows
- nothing finer to record against
- coverage known only afterwards
- paragraph diffs say little
basics
~20 sA step-free entry holds a title, a scope paragraph and the usual attributes, with a free-text body filled at execution time. Without a step table there are no per-row expectations, so nothing finer than the entry itself can carry an outcome.
solid answer
~40 sA step-free entry is a legitimate stored shape, usually produced by a template whose body is one free-text block instead of a numbered table. It still has a title, a scope or mission paragraph, often preconditions, the ordinary attributes, an identifier, a place in the folder tree and an owner, so it can be found, assigned and included in a cycle exactly like a stepped case. What it does not have is a row that carries an expectation, and that costs three things: nothing finer than the whole entry can carry an outcome; a reviewer cannot tell from the definition alone what work it will actually cover, because that is decided by whoever runs it; and edits are coarse, since a rewritten paragraph shows only that the text changed rather than which assertion moved.
go deeper
Know that a repository can store an entry with no numbered steps, that a template decides this, and that such an entry still has a title, attributes and an identifier.
Explain what is lost mechanically: no rows means no per-row expectations, nothing finer than the entry to record against, and paragraph edits that produce coarse history.
Show when you would choose the shape and when you would refuse it, especially where somebody outside the team must later rely on exactly what was checked.
Own the inventory consequence. If both shapes are counted as one number, every figure derived from the folder mixes prescribed work with delegated work, and you should say so before anyone quotes it.
## What the stored shape actually holds A step-free entry is not a malformed case. It is a case created from a template whose body is one free-text block rather than a numbered table. Typically it holds: - a **title**, exactly as a stepped case does, and it travels into lists and reports the same way; - a **scope or mission paragraph** saying what area this entry covers and, often, what the person running it is looking for; - **preconditions**, if the area needs a particular environment, account or data situation; - the ordinary **attributes** — the fields the template shows; - a **body filled at execution time** rather than at authoring time, holding what the person actually did and saw. Because it is a normal entry in the repository, it keeps everything the repository gives an entry: an identifier, a position in the folder tree, an owner, the ability to be assigned, and the ability to appear in a cycle beside stepped cases. ## What you keep | Kept | Why it matters | |---|---| | Identifier and folder position | the work is inventoried and findable, not invisible effort | | Attributes | it can be selected, filtered and reported on beside stepped cases | | Assignability and cycle membership | it can be planned into a release's work like anything else | | A title | a reader scanning a list sees what area was covered | That is the whole argument for storing this shape in the repository rather than in a document elsewhere: it makes non-scripted work **visible to planning** without pretending it is scripted. ## What you give up - **A place to hang a finer outcome.** With no rows, the entry as a whole is the smallest thing an outcome can be recorded against. "Most of it was fine but this part was not" has to live in prose. - **Predictable coverage.** Two people running the same entry will do different work, which is frequently the point, but it means a reviewer cannot tell from the definition what will be covered. A stepped case answers that before anyone runs it; this one answers it only afterwards. - **Meaningful diffs.** Editing a numbered row is a small visible change. Rewriting a paragraph shows that the text changed and little more, so the history is coarser and review is weaker. - **Repeatability after a change.** If the point is to do the same thing again next release and compare, a paragraph does not constrain the work enough to make the comparison mean much. - **Independent evidence.** The record is the executor's own account. Where somebody outside the team has to rely on what was verified, that account carries less weight than an assertion written before the work and checked during it. ## When the shape is right, and when it is not **Right when:** the value of the work is the tester's judgment rather than a prescribed path; the area is new enough that prescribing steps would encode guesses; the entry is a deliberate placeholder for work you do not want frozen into a script; or the cost of writing and maintaining thirty rows exceeds what the rows would tell you. **Wrong when:** somebody outside the team must later rely on exactly what was checked; the executor lacks the domain knowledge to make good choices unaided, so the entry becomes an invitation to do nothing much; or the intent is to repeat identical work after a change and compare the two runs. ## Living with both shapes in one repository The practical requirement is that the two shapes stay **distinguishable**. If step-free entries and stepped cases are indistinguishable in a listing, then any count over the folder mixes definitions that prescribe work with definitions that delegate it, and every number derived from that count means less than it appears to. Keeping them on separate templates — and being willing to say out loud that a count of entries is a count of two different things — is what keeps the inventory honest. The last trap is drift in the other direction: a step-free entry that slowly accretes a numbered list inside its free-text body. At that point the team wants a stepped case and is writing one in a field that cannot number, address or assert on the rows. Move it to the stepped template rather than simulating one in prose.
- Why keep such an entry in the repository at all rather than in a document beside it?Because the repository gives it an identifier, a folder position, an owner, attributes and cycle membership. That makes non-scripted work visible to planning and reporting beside scripted work, instead of being effort nobody can see, while the free-text body still avoids pretending the work was prescribed.
- What does it mean when a step-free entry's body has grown its own numbered list?That the team actually wants a stepped case and is simulating one in a field that cannot number, address or assert on rows. Move it onto the stepped template so each row can carry its own expectation, rather than leaving a step table trapped inside prose where nothing can point at it.
saying these in an interview costs you the question
- Calls a step-free entry an incomplete or unfinished case
- Counts step-free and stepped entries as one inventory number
- Expects per-row outcomes from an entry with no rows
- Types a numbered list into the free-text body
- Uses the shape where external evidence is required