In a TestRail- or Xray-class test case repository, what is the difference between a controlled attribute such as component or priority and a free-text label typed onto a stored case?
answer
- who owns the vocabulary
- pick from a list, or type it
- mandatory field means total coverage
- labels return only what authors remembered
- spelling drift versus form fatigue
basics
~20 sA controlled attribute is a field defined once with a fixed value list, so every case answers the same question the same way. A free label is text anyone can invent — cheap to add, easy to misspell, never complete.
solid answer
~40 sBoth are selectors on a stored case, but they differ in who defines the vocabulary. A **controlled attribute** — component, type, priority, owner — is a field created at the repository level with an allowed value list; the author picks rather than types, and the field can be made mandatory, so eventually every case carries an answer. A **free label** is open text invented at authoring time, with no definition step and no approval. That makes labels perfect for short-lived, cross-cutting marks (`needs-fixture-refresh`, a migration name) and bad for anything a selection must be *complete* over, because near-duplicate spellings pile up and cases nobody remembered to mark are simply absent. The practical rule: if a saved query must return *all* matching cases, the dimension belongs in a controlled field.
go deeper
Be able to say plainly that an attribute is chosen from a fixed list defined for the whole repository, while a label is free text anyone can type, and give one example of each.
Explain why a mandatory controlled field makes a query complete over the repository while a label query only returns the cases whose author remembered, and name the spelling-drift problem.
Show you have seen both failure modes: the label vocabulary that forked into near-duplicates, and the over-governed form where authors pick the first value to escape. Say how you would detect each.
Own the standard for when a dimension earns a governed field with a backfill obligation, and be able to defend leaving a genuinely temporary mark as a free label rather than growing the schema.
## What a stored case actually carries A case in a TestRail- or Xray-class repository is a record: a title, some step content, and a set of **selectors** — small pieces of metadata whose only job is to let you find that case again among thousands of siblings. Those selectors come in two shapes, and the difference between them decides what a query over the repository can honestly promise. A **controlled attribute** is a field defined once, at the repository level, with a fixed list of allowed values. Four recur almost everywhere: - **component** — which part of the product this case exercises - **type** — what kind of check it is (a functional path, a boundary check, a security check, a performance probe) - **priority** — how much this stored case matters relative to its neighbours - **owner** — who answers for the case when it needs a decision The author does not type these values; they choose from the list the field was defined with. That single constraint is where all the value comes from. A **free label** (a tag) is an open text field. Anyone may invent a value at authoring time — no definition step, no approval, no review. `payments-migration`, `needs-data`, `quarantined`, `slow` — a label costs one keystroke and carries whatever meaning its author had in mind that afternoon. ## What the constraint buys and what it costs | | Controlled attribute | Free label | |---|---|---| | Value set | fixed, defined before first use | open, invented at use | | Cost to add a value | a schema change somebody approves | none | | Typo risk | none — you pick, you do not type | high; near-duplicates accumulate silently | | Completeness | can be made mandatory, so coverage becomes total | partial by construction | | Retires cleanly | yes — remove the value, see what breaks | rarely; dead labels linger forever | | Good for | stable dimensions of the product | short-lived, cross-cutting marks | ## The completeness property is the real difference Everything else is detail. When a field is controlled *and* mandatory, a query on it partitions the whole repository: every case is in exactly one bucket, so `component = checkout` returns the checkout cases, full stop. A query on a free label returns *the cases whose author remembered the label* — which is a different set, and one that gets further from the truth every week as new cases are authored by people who never saw the convention. That asymmetry bites hardest when a selection is used to make a decision. A run built from a controlled attribute can be defended: it is everything that matches. A run built from a label is a sample of unknown coverage wearing the costume of a complete set. Nothing in the product warns you about the difference — the query returns rows either way. ## The failure mode each shape has 1. **Labels drift by spelling.** `smoke`, `Smoke`, `smoke-test` and `smoketest` are four distinct values to a query engine and one idea to a human. Repositories usually offer type-ahead on existing labels, which slows the drift but does not stop it, because type-ahead only helps the author who starts typing the same first letters. 2. **Labels drift by meaning.** A tag invented for one migration outlives the migration. Six months later nobody can say whether the cases still carrying it are relevant, and nobody dares delete it. 3. **Controlled fields drift by fatigue.** Every mandatory field is another thing between an author and a saved case. Add enough of them and authors pick the first value in each list to get past the form — which is worse than an empty field, because an empty field is visibly empty and a wrong value looks like data. 4. **Controlled fields ossify.** Adding a value means finding whoever governs the field. When that is slow, people route around it with a label, and you end up maintaining both. ## How to choose in practice Ask what will consume the selector: - If a **saved query** will drive a run, a report, or a coverage claim, and the claim depends on the set being complete, it needs a **controlled attribute**. - If the mark is **temporary**, invented by one team for one piece of work, and nobody will assert completeness over it, a **label** is exactly right and a field would be overkill. - If a label survives more than a release or two and people start querying it as though it were complete, that is the signal to promote it into a field — and to backfill the existing cases at the same time, because a half-populated new field is a label with more ceremony. The two shapes are complements, not rivals. A healthy repository has a small set of controlled attributes that every case answers, and a churning tail of labels that come and go with the work. It becomes unusable when the tail is doing the load-bearing work.
- You have made a component attribute mandatory. What did you have to do about the cases that already existed?Backfill them, before the field is trusted. A new mandatory field only constrains new and edited cases; the existing thousands sit empty or default. Until they are populated, a query on the field is exactly as incomplete as the label it replaced — so the backfill, usually a bulk edit per subtree, is part of introducing the field, not a follow-up task.
- Type-ahead on existing labels is offered when authoring. Does that solve label drift?It slows it, it does not solve it. Type-ahead only helps an author who begins typing the same first characters as the existing value, so `smoke` and `quick-smoke` still diverge, and a plural or a hyphen still forks the vocabulary. It also does nothing about the second drift — meaning — where one spelling quietly comes to mean two things.
saying these in an interview costs you the question
- Says labels and attribute fields are the same thing renamed
- Assumes a label query returns every relevant case
- Claims free text cannot be queried at all
- Wants every useful mark promoted to a mandatory field
- Never mentions that existing cases need backfilling