When you build a test cycle by selecting a folder in a case repository, how far down the folder tree does that selection reach, and why does the answer matter?

## Why "select this folder" is ambiguous A case library is almost always a tree: an area, a feature beneath it, a sub-feature beneath that, and cases hanging at various depths. When a cycle is built by pointing at a node in that tree, the product must decide what "this folder" means, and there is no universal answer. The behaviours you will meet: - **Direct members only.** Only cases attached to that exact node join the cycle. Anything in a child folder is left out. - **Full subtree.** The node and everything beneath it, to any depth. - **Subtree with an exclusion.** The whole subtree except folders marked in some way — archived, or deliberately opted out. All three are defensible designs, and all three return a set that looks reasonable. That is the whole problem: the failure mode of a wrong reach is a *plausible number*, not an error. ## The two ways it goes wrong | Behaviour | Failure | How it shows up | |---|---|---| | Direct members only | under-coverage | small case count; deep folders never run | | Full subtree | over-coverage | drafts, retired cases and neighbouring areas swept in | **Under-coverage is the more dangerous of the two**, because over-coverage is self-announcing — testers hit cases they do not recognise and complain within the hour. Nothing at all announces a case that was never selected. Nobody is assigned it, nobody skips it, no count includes it. It is simply outside the population, and the cycle reports a clean pass over a scope that quietly excluded the deep leaves where a mature library keeps most of its cases. ## Establishing the behaviour instead of guessing 1. Pick a parent folder whose direct-child case count and whose full subtree count you already know, or can count by hand. 2. Build a throwaway cycle from that folder alone. 3. Compare the resulting case count against both numbers. It will match one of them, and that is your answer. 4. Repeat one level deeper, because a couple of products stop after one level of nesting rather than recursing to any depth — a behaviour that a single-level test cannot distinguish from full recursion. Write the answer down beside the team's cycle-building instructions. It is a one-line fact that every later argument about a case count depends on. ## Making the reach deliberate Once you know the default, do not rely on it. A folder is a filing decision, and filing decisions get made for reasons that have nothing to do with what should run — someone parks a spike's cases under a feature, someone leaves an old release's cases in place rather than moving them. Combining scope with attributes fixes this: - Pair the subtree scope with an **active-state condition** so drafts and retired cases cannot enter. - Pair it with a **release or version attribute** when the subtree holds cases for more than one. - Prefer **shallow, deliberate trees** over deep ones for anything you select from regularly; the deeper the tree, the more the reach question costs you. - Sanity-check the resulting count against the previous comparable cycle. A total that has jumped or halved without a matching change to the library is usually a reach problem, not a coverage improvement. ## Where the tree shape itself is the problem If every cycle needs a hand-written exception list because the folder that holds what you want also holds three things you do not, the selection is not the fault — the filing is. That is a signal to move the affected cases or to select on an attribute rather than on location, so the rule stops depending on where somebody filed something months ago. ## What to say in an interview Name the ambiguity, name both failure directions, and say which one you fear more and why. Then describe the count-comparison check, because it shows you treat tool behaviour as something to verify rather than assume — which is the actual point of the question.