A test cycle was created from a saved filter. What is the difference between a filter that is resolved once at creation and one that is re-resolved every time the cycle is opened?
answer
- the rule is fine — when is it applied
- once at creation, or on every open
- an attribute edit moves the membership
- a recorded result can leave with its item
basics
~20 sResolving once turns the rule into a fixed set of cases at creation, so later library edits cannot change the cycle. Re-resolving recomputes membership on every open, so new, retired or re-tagged cases move in and out silently.
solid answer
~50 sA saved filter is a rule, and the crucial question is *when* the rule is applied. Under **resolve-once**, applying it is a one-off act: the matching cases become the cycle's members and the rule is thereafter only history. Under **re-resolve**, the rule is applied every time the cycle is displayed, so membership is a live view of the library. The difference only shows itself when the library changes. Author a case that matches, retire one, move one out of the folder, or fix a tag, and a resolve-once cycle is untouched while a re-resolving one gains or loses items — including items that already carry a recorded outcome. Products differ, and some offer both, so never assume: create a cycle, change one case's attribute, reopen, and compare the count. Resolve-once is what you want for anything you must defend later.
go deeper
Know that a saved filter is a rule, and that a cycle may either keep the rule or keep the cases the rule found once. Say which one you have seen.
Walk through what an addition, a retirement and a tag edit each do under both modes, and describe the experiment that tells you which mode a tool uses.
Show that you have debugged a moving count in production: a recorded failure that left the cycle with its item, and the attribute edit behind it. Say how you stopped it recurring.
Own the policy on when a cycle stops being a live view and becomes evidence, and what your team must be able to reconstruct months later about which cases a release was signed off against.
## The rule and the moment it is applied A saved filter is a **condition** — a folder scope, a set of tags, a priority band, an automation state, an owner. It says nothing on its own about a cycle's membership until something *applies* it to the library. Everything in this topic turns on when that application happens, and how many times. - **Resolved once (static selection).** The condition is applied at creation. The matching cases become the cycle's members and are stored as such. The rule may be kept for reference, but it no longer drives anything. - **Re-resolved (live selection).** The condition is stored *as* the membership. Every time the cycle is opened, counted or reported on, the library is queried again and the answer is whatever matches now. With a static library the two are indistinguishable. They diverge the moment anyone edits the library — which, on a real project, is every day. ## What an edit does under each mode | Change in the library after creation | Resolve-once cycle | Re-resolving cycle | |---|---|---| | A new matching case is authored | not included | appears as a new untested item | | A member case is retired or archived | still a member | disappears from the cycle | | A tag is fixed so a case now matches | not included | joins mid-cycle | | A tag is fixed so a case no longer matches | still a member | leaves, and its recorded result leaves with it | | A case is moved to another folder | unaffected | leaves if the rule was folder-scoped | The fourth row is the one that costs people an afternoon. Someone tidies attributes with the best intentions, and a case that was executed and failed quietly stops being part of the run. The result was not deleted — the item that carried it is simply no longer in the set being displayed, so the failure vanishes from the count. ## Telling which mode you actually have Do not infer this from a product's marketing words or from a dialog's wording. Establish it empirically, in a scratch project: 1. Create a cycle from a filter and write down the exact case count. 2. Author one new case in the library that satisfies the condition. 3. Reopen the cycle and compare the count. A change means re-resolution. 4. Repeat with an *edit* rather than an addition — re-tag one existing member so it no longer matches — because a few products absorb additions but never drop existing members. That asymmetric third behaviour is real, and it is the one that catches people who tested only step two. Record the answer somewhere the team reads, because it is a property of the tool that every later argument about counts depends on. ## Where re-resolution hurts, and where it helps - **It hurts auditability.** A cycle you must show to someone later should mean "this is what we chose and this is what we ran". A live selection can no longer answer that, because it reports today's population against yesterday's results. - **It hurts comparability.** Two consecutive cycles built from the same live rule can have different totals for reasons that have nothing to do with the release, so a pass-rate movement between them is not evidence of anything on its own. - **It helps during authoring.** While the case set is still being written, a live selection means the cycle keeps pace with the cases without anyone rebuilding it, which is genuinely useful in the first days of a feature. - **It helps for standing scopes.** A perpetual cycle over "everything in this area" is exactly the case where you *want* the rule to keep finding new members. The rule of thumb: **live while the set is still being defined; static as soon as the run is something you will report on.** ## Practical mitigations - Convert to a fixed membership before the cycle becomes evidence — if the product allows it, resolve the rule and accept the result explicitly. - Freeze the attributes a rule depends on for the duration of a cycle, and make attribute clean-up a between-cycles activity rather than a during-cycle one. - If a live cycle is unavoidable, capture the case count and identifiers at the start so a later divergence is at least detectable rather than invisible. - Treat an unexplained change in a cycle's total as a membership event first and a data-loss event second; the count usually moved because the population moved. ## What an interviewer is listening for The weak answer stops at "a filter picks the cases for you". The strong answer names the timing, gives one concrete consequence of a mid-cycle attribute edit, and says how they would find out which mode a given tool uses instead of assuming.
- A failure that a tester definitely recorded is missing from a filter-built cycle. Where do you look first?At the case's attributes, not at the result store. If the cycle re-resolves its filter, an edit that made the case stop matching removes the item from the set being displayed, and the outcome goes with it. Compare the current count against the count noted at creation, then check the case's edit history for a tag or folder change.
- Why is a pass rate from a re-resolving cycle hard to compare with the previous release's?Because the denominator is not stable. The rule is the same, but the population it matches has changed as cases were authored, retired or re-tagged, so a movement in the percentage mixes a change in quality with a change in what was counted. Comparison needs a membership that was fixed at some point both sides agree on.
A resolved-once filter is a printed guest list; a re-resolving one is a rule at the door reading badges. Move someone to another department after the list is printed and only the door notices.
saying these in an interview costs you the question
- Assumes every tool resolves a saved filter the same way
- Thinks a stored rule and a stored case set are interchangeable
- Blames missing results on data loss rather than membership
- Compares pass rates across cycles with unstable totals
- Tests only additions and never an attribute edit