In a TestRail-class test-management repository, what is the difference between building a test cycle from a hand-picked list of cases and building it from a saved filter?
answer
- two ways to answer which cases
- who fixes the contents, person or rule
- does a newly authored case appear
- enumeration versus condition
basics
~10 sA 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.
solid answer
~50 sBoth answer the same question — which cases are in this cycle — but they store different things. A **hand-picked list** stores identities: someone opened the library, chose cases, and the cycle now holds that set. A **saved filter** stores a condition over case attributes such as folder, tag, priority or automation state, and the membership is whatever satisfies it. The practical consequences follow from that. A hand-picked cycle is stable and easy to defend in a review, because one person owns exactly what went in, but it does not notice a case added to the library afterwards. A filter-built cycle scales to hundreds of cases and keeps pace with the library, but nobody individually approved the resulting set, so a mis-tagged case is silently in or silently out. Mature teams use filters to draft the set and a hand check to accept it.
go deeper
Be able to say plainly that one approach stores the chosen cases and the other stores a rule that finds them, and give one consequence of each.
Explain what happens to each kind of cycle when the library changes underneath it — a case authored, retired, moved or re-tagged — and why the two answers differ.
Show the hybrid: a rule to shortlist, a human to accept, and the rule kept beside the cycle. Be ready to describe a coverage gap you found that came from a tagging mistake.
Own the tradeoff between scale and accountability across a team. Decide when curated membership is worth the maintenance and when the attribute data is trustworthy enough to select from directly.
## What a cycle stores when you choose cases A **test cycle** — also called a run, a test execution or an iteration, depending on the product — is the record of one pass over some subset of a stored case library. Creating one always answers a single question: *which cases are in it?* A TestRail-class repository, and equally the Jira-resident tools such as Xray and Zephyr that keep the same idea inside the tracker, offer two ways to answer. - A **hand-picked list** is *extensional*. A person browses the library, ticks cases, and the cycle stores those identities. The set is finite, named and frozen at the moment of choosing. - A **saved filter** is *intensional*. Instead of identities you store a condition — "everything under this folder subtree, tagged for checkout, that is not marked automated" — and the membership is derived by applying that condition to the library. The distinction is the same one that separates a list of names from a rule about who qualifies. Everything else in this topic follows from it. ## Fixed by a person versus fixed by a rule | | Hand-picked list | Saved filter | |---|---|---| | What is stored | case identities | a condition over attributes | | Who owns membership | the person who ticked | whoever maintains the attributes | | A new case appears in the library | not included | included if it matches | | A case is re-tagged or moved | still included | may enter or leave | | Cost to build for a large scope | high, and it grows | flat, once the rule exists | | Ease of defending in a review | high — one decision, one author | lower — must re-derive the rule | The last two rows are why teams drift toward filters as a library grows, and why they drift back toward explicit acceptance after their first surprise. ## Where each one breaks - **The hand-picked list goes stale.** A feature's cases were ticked in March. In June three new cases were authored for the same feature, and the cycle nobody rebuilt does not contain them. Coverage looks fine; the count is simply against the wrong population. - **The hand-picked list does not scale.** Choosing four hundred cases by hand is not just slow — it is unreviewable, because the reviewer would have to repeat the whole exercise to check it. - **The saved filter inherits every attribute mistake.** A filter is only as good as the tagging behind it. One case tagged with a typo is invisible to the rule, and no one will notice, because nothing draws attention to an item that was never there. - **The saved filter has no single author.** When someone asks "who decided this case would not be run?", a hand-picked list has an answer and a filter has a rule plus a data-entry history. ## The hybrid most teams land on In practice the two are not rivals. The usual working pattern is: 1. **Draft with a rule.** Use the filter to reduce a library of thousands to a candidate set of dozens or hundreds. This is the part a human is bad at and a query is good at. 2. **Accept explicitly.** Have a person scan the candidate set, remove what does not belong, and add what the attributes missed. The acceptance is the decision; the query was only the shortlist. 3. **Record the rule beside the cycle.** Keep the filter text with the cycle even when the membership was accepted by hand, so the next release starts from the same shortlist rather than from a blank page. That pattern gets the scale of a query and the accountability of a list, and it is the answer an interviewer is usually listening for. ## What the interviewer is really probing The surface question is a definition. The underlying one is whether you know that a cycle can hold either a **decision** or a **pointer to a rule**, and that these behave differently over time. A candidate who says "filters are faster" has answered half of it. A candidate who adds "and the cost is that no one individually approved the set, so an attribute error becomes a coverage gap that nothing reports" has answered all of it. One caution about vocabulary: products differ in what they call these, and several offer both in the same dialog, so ask which one a given cycle was built with rather than assuming from the name on screen.
- Your cycle was hand-picked, and someone asks why a brand-new case for the same feature was never run. What do you tell them?That the cycle stored case identities chosen when it was created, so a case authored afterwards was never a member. It is not a skip and it will not show as untested — it is outside the population entirely. The fix is to rebuild or extend the selection, and to prefer a rule-based shortlist for scopes that keep growing.
- Two people build a cycle from the same saved filter an hour apart and get different case counts. What explains it?The rule is stable but the library is not. Between the two applications a case was authored, retired, moved between folders, or had an attribute edited so that it started or stopped matching. Nothing is broken; a filter describes a population at the moment it is applied, so any two applications can legitimately differ.
saying these in an interview costs you the question
- Thinks a hand-picked cycle grows by itself as the library grows
- Says filters are simply better, naming no cost
- Cannot say who is accountable for what ended up in the cycle
- Assumes every product resolves a saved filter the same way