In a TestRail-class case repository, a folder tree and case attributes such as component and type both index the same cases — what different question does each answer?
answer
- one home versus many facets
- containment hierarchy against independent facts
- the tree can only sort on one axis
- a saved query is a stored question
- browse and own here, select there
basics
~20 sA 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.
solid answer
~40 sThey are two indexes over one set of cases, and they answer different questions. The **folder tree** is a containment hierarchy — each case has exactly one path, which makes it browsable, gives newcomers a map, and is usually the unit that permissions and ownership attach to. **Attributes** are independent facts about the case — component, type, priority, owner — and a case carries several at once, so they cut across the tree freely. Selection for a run should come from attributes read by a **saved query**, because the query re-evaluates when the run is created and therefore picks up cases authored since. Selection that points at a folder path is selection by location, which stops being true the moment somebody reorganises. Keep the tree for browsing and ownership; keep the attributes for selecting.
go deeper
Know that a case sits in exactly one folder but can carry several attribute values at once, and that a saved query filters on the attributes rather than on the folder path.
Explain that a tree can only be organised along one axis, that a saved query is re-evaluated rather than stored as a result, and why that makes attributes the right basis for selecting a run.
Talk about the failures you have seen: the duplicated fact in a folder name, the run that missed cases authored last week, the permission boundary that shortened a query result without saying so.
Own the convention for the whole repository — what the tree is allowed to encode, which attributes are mandatory, and how you keep reorganisation a cheap, routine event rather than a migration.
## Two indexes, one set of cases Every serious case repository ends up with both a folder tree and a set of attributes on each case, and teams that have not thought about it treat them as interchangeable ways to organise. They are not. They answer different questions, they fail differently, and the most common structural mistake in a large repository is asking one of them to do the other's job. The **folder tree** (sections, suites, a directory path — the name varies by product) is a **containment hierarchy**. Its defining property is that a case has exactly one path. That single-home property is what makes it useful: - it is **browsable** — a newcomer opens the tree and gets an immediate map of what exists - it is where **permissions and ownership** usually attach, because one home means one unambiguous owner - it gives a stable **place to file** a new case, which is a real cognitive service; deciding where something goes is easier than deciding how to tag it The **attributes** are **independent facts** about the case: which component it exercises, what kind of check it is, how much it matters, who answers for it. A case carries all of them at once, and each cuts across the tree without regard for it. Their defining property is the mirror image of the folder's: **many facets, no single home.** ## Why selection belongs to the attributes The question a run has to answer is almost never *where do these cases live* — it is *which cases match what I care about right now*. Those two coincide only when the tree happens to be organised along the exact axis you are selecting on, and a tree can only be organised along one axis at a time. A repository organised by product area cannot also be organised by check type. A repository organised by team cannot also be organised by release. The moment two people want different top-level cuts, the tree loses — but a saved query on attributes gives both of them what they want off the same cases, because attributes compose: 1. `component = checkout AND priority = high` — one team's release gate 2. `type = boundary AND component = checkout` — a design reviewer's audit list 3. `owner = payments-team AND label = needs-fixture-refresh` — a maintenance sweep None of those three is a folder, and no tree could hold all three at once. ## The property that actually decides it: re-evaluation A saved query is not a stored result — it is a stored *question*, re-evaluated whenever it is used. That is the property worth building on. A case authored this morning with the right attributes appears in tonight's run without anybody touching the run definition. A frozen list of case identifiers, by contrast, is a photograph: correct on the day it was taken and quietly wrong forever after. This is also why a suite pinned to a folder path is a weaker construct than it looks. A path *is* re-evaluated — but it selects on **location**, and location is the one property of a case that a well-meaning reorganisation changes. Attributes describe the case; the path describes where somebody most recently decided to put it. ## A working division of labour | Concern | Folder tree | Attributes and labels | |---|---|---| | Cardinality per case | exactly one | many at once | | Best at | browsing, filing, ownership, permissions | selecting, filtering, reporting | | Changes when | somebody reorganises | the case's nature changes | | Survives reorganisation | no, by definition | yes | | Newcomer value | high — it is the map | low until you know the vocabulary | The practical rule that falls out: - **Shape the tree for humans reading it.** Shallow, along the axis your team actually thinks in, and treat a reorganisation as a normal event rather than a catastrophe. - **Shape the attributes for queries.** Keep the set small and mandatory enough that a query on them is complete. - **Never encode into the tree a fact that is also an attribute.** A folder literally named for a priority or a check type is a fact stored twice, and the two copies will disagree within a release. - **Let the run be defined by the query,** so the tree stays free to change. ## Where the two must agree One caveat: because permissions typically follow the tree, an attribute-driven query can select cases the querying account cannot read, and the result silently shortens. That is not a reason to select by folder — it is a reason to keep the tree's permission boundaries coarse and aligned with the attribute vocabulary, so that the two indexes disagree about visibility as rarely as possible.
- If attributes are better for selection, why keep a deep folder tree at all?Because filing and browsing are real work that a flat pile makes worse. The tree gives a newcomer a map, gives an author an obvious place to put a new case, and gives permissions and ownership a natural unit. It just should not be asked to answer selection questions, and it should be kept shallow enough that reorganising it is cheap.
- What happens when a folder is named after a value that is also an attribute — say a folder called high-priority?You now store one fact twice, in two places that can be edited independently, and they will disagree. Somebody moves a case out of the folder without changing its priority value, or lowers the priority without moving it. Pick the attribute as the single source and let the folder name describe area or feature instead.
- An attribute-driven query returns fewer cases for one user than another. What is the likely cause?Read permissions, which usually attach to the folder tree rather than to the attributes. The query matches the same cases for both accounts, but the result is filtered to what each may see, so a user without access to a subtree gets a silently shorter list. Nothing in the result marks the omission — hence checking coverage with an account that can see everything.
A library shelf gives every book one physical home, which is what makes browsing possible — you walk the aisle. The catalogue gives the same book many cross-cutting entries: author, subject, year. You reshelve without reprinting the catalogue, and you would never define a reading list as 'whatever is currently on shelf 4'.
saying these in an interview costs you the question
- Treats folders and attributes as two names for one mechanism
- Defines every run by pointing at a folder path
- Creates folders named after priority or check type
- Thinks a saved query stores its result rather than the question
- Solves cross-cutting selection by deepening the tree