Case Inventories

A variant table holds one row of values per run of the same stored case. Placeholders in the step text name a column, and the repository substitutes that row's value, producing one execution per row.

A shared step block is one stored step sequence that many cases point at instead of each holding a copy. Edit the block and every referencing case changes at once; edit a pasted copy and only that case changes.

A 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.

Per-row expectations make each step independently checkable, so a divergence can be attached to the action where it happened instead of to the case as a whole. A single case-level expectation pushes that detail into free text nobody can search.

A folder answers where a case lives: one home, browsable, the unit permissions and ownership usually follow. Attributes answer what a case is: independent facts that cut across the tree, which a saved query can combine to select a run.

Assignment records an owner on one cycle item, so it leaves the shared pile and appears in that tester's filtered queue. It changes nobody's result: an assigned item stays untested until an outcome is recorded.

Most case repositories append the second attempt as a new dated result rather than replacing the first. The item's displayed status becomes the latest attempt, while the earlier failure stays in the execution's result history.

A hand-picked list names each case explicitly, so a person fixes the contents. A saved filter names a rule instead, so the contents are whatever the library matches when that rule is applied.

Blocked means the tester could not execute the case at all, because an environment, data or dependency problem stopped the run. Failed means the case ran and the product behaved wrongly. Blocked describes the run; failed is evidence about the product.

Unassigned items count exactly like assigned ones. They belong to the cycle total and stay in remaining until a result is recorded, because the counts read the result and not the owner. Owner-filtered views hide them.

The denominator is the set of requirements the panel's saved filter selects; the numerator is how many of those satisfy the panel's configured covered condition. The unit counted is the requirement, not the test case.

Two things, as a pair: which tracker project receives the item, and which item type it is created as. Trackers attach mandatory fields, closed value lists and workflow to that pair, so the mapping is defined against it.

Filing from a failed execution pre-fills the draft ticket with the run's context: which case failed, which cycle it ran in, the environment or build under test, who recorded the result, and the comment and evidence captured at failure time.

Each condition is stricter than the last, so over one population the three readings form a descending ladder: a link counts intent, executed counts work actually done in the chosen cycle, passed counts behaviour confirmed. The gaps between them are the diagnosis.

Name a source rather than inventing a value: a constant the team stands behind, something derived from the run or the case, a person prompted at filing time, or a destination change that drops the demand.

A clone copies the case definitions - titles, steps, expected results, field values and attachments - into brand-new cases with new identifiers. It leaves behind the executions, recorded results and the revision trail, which stay with the originals.

One change-history entry names the actor, the timestamp, and every field that save touched with its before and after values. Entries are per-field and append-only, so the trail never shrinks.

A snapshot cycle copies each case's text when the case joins it, so later edits never change what the cycle shows. A live-reference cycle stores only a pointer, so every edit to the master case appears immediately inside the open cycle.

Archiving hides a case from authoring and selection while keeping its record and execution history intact. A hard delete removes the record itself, so past results and inbound references lose the row they resolved against.

Comparing two revisions is a read-only, field-by-field diff. Restoring writes the old values back as a brand-new revision attributed to you, now — it never deletes the revisions in between, so the trail only grows.

Every pushed result names three things: the cycle it belongs to, the stored item it is a result for, and the outcome. The item handle is the one that fails, because code and repository must already agree on one identifier.

Every automated outcome is attributed to that engineer, the pipeline inherits their full human reach across projects, and the job breaks when they change team or leave. Use a dedicated machine account holding only the capability to record results.

Titles are editorial text: they get reworded, translated, duplicated and re-scoped, and none of those edits signals that coverage changed. A durable identifier survives every rename, so the pairing breaks only when the definition is actually deleted.

Definitions travel; the context the old product wrapped around them mostly does not. Titles, step text, folder placement and plain fields import cleanly. Execution history, attachments, typed custom-field meaning and shared-step relationships arrive degraded or missing.

Recording a result adds evidence about what happened; authoring changes what the test says. Splitting them lets an automation account report outcomes continuously while never being able to rewrite the definitions its own results are evidence for.