Why is an acceptance criterion whose only linked test case is permanently skipped worse than one with no linked case at all?
answer
- The link exists; nothing behind it runs
- A link is not evidence of execution
- A visible hole gets an owner
- Skips outlive the reason for them
- Demote a disabled case to a gap
basics
~20 sThe link still exists, so the record reads the criterion as verified while nothing runs against it. An unlinked criterion is visible and gets an owner; a permanently skipped case hides the same hole behind a joined-up chain.
solid answer
~50 sA traceability record stores that a link exists, not that anything ran. Skip markers live on the case inside the suite and never reach the link set, so the chain joins up and the criterion reads as verified. Both states carry the same verification: none. They differ in whether anyone knows. An unlinked criterion is information — it lands on the finding list with an owner. A skipped-only criterion is misinformation, which is dearer because decisions are made on it, and it decays: the reason is forgotten and the case rots against a changed interface. The fix is to read execution as well as linkage — if every case linked to a criterion is disabled or has never produced a result, report a gap — and to give every skip an owner and an expiry.
code
pseudocode · 10 linesfor criterion in acceptanceCriteria:
linked = criterion.linkedCases
live = linked where case.enabled
and case.lastResult != SKIPPED
and case.executions is not empty
if linked is not empty and live is empty:
report SILENT_GAP(criterion,
reason = "every linked case is disabled or skipped",
owner = criterion.owner)go deeper
Know that skipping a case is a normal thing to do and that it means the case produced no result. Be able to say what stays true and what stops being true while a case is switched off.
Explain the mechanism: link sets store connections, suites store skip markers, and nothing joins the two, so a criterion with a disabled case reads exactly like a verified one.
Show the judgement. Argue why a hidden hole costs more than a visible one, describe how a skip decays into permanence, and give the rule you would add so a disabled case falls back into the finding list.
Own the policy: who may disable a case, what has to be recorded when they do, how long a skip may live, and what the team is allowed to claim about a criterion while its only case is switched off.
## Why the record still reads as verified A traceability record joins statements to cases. What it stores is that a link exists — this acceptance criterion is verified by that test case — and almost nothing built on top of it asks the second question: *did that case actually produce a result?* Skips, quarantines and disabled cases usually live in the suite, expressed as a marker on the case itself, and the marker does not travel into the link set. So the two never meet. The criterion has a case, the case has a link, the chain joins up, and the reader concludes something that has not happened. That is the whole mechanism, and it is why the situation is worse than the more alarming-sounding alternative of having no case at all. ## Two ways to be unverified | | Open gap: no linked case | Silent gap: only case is skipped | |---|---|---| | What the record shows | A finding, on the list | A joined-up chain, no finding | | Who is looking | Whoever owns that requirement | Nobody | | How it decays | Stays visible until closed | Ages quietly; the reason is forgotten | | Cost to repair later | Write one case | Repair a rotted case, or write one anyway | | What a reader concludes | "This is not verified yet" | "This is verified" | Both states have the same amount of verification behind them: none. They differ entirely in whether anyone knows. An open gap is *information*; a skipped-only criterion is **misinformation**, and misinformation is the more expensive of the two because it is acted on. ## How a temporary skip becomes a permanent one 1. A case starts failing for a reason nobody can fix today — an unstable dependency, a half-finished change, an intermittent failure that blocks everybody. 2. Somebody disables it to unblock the work. This is a reasonable decision and usually the right one. 3. The reason is not written next to the skip, or it is written in a message that scrolls away. 4. The interface the case exercised moves on. The case now fails for a second reason nobody knows about. 5. Six months later, re-enabling it means rewriting it, which nobody has budget for, so it stays. At no point does anyone decide "this criterion will not be verified". The decision is made by accumulation, and the record keeps saying the opposite the entire time. ## Making the hole visible again The repair is to stop treating a link as evidence and start treating **a link with a live case behind it** as evidence. - Fold execution state into the finding rule: if every case linked to a criterion is disabled, skipped or has never produced a result, report the criterion as a gap. It is one extra condition and it converts a silent state into a visible one. - Give every skip an **owner and an expiry** recorded beside the case. When the expiry passes the choice becomes explicit: repair, replace, or record that the criterion is unverified. - Distinguish the two skips that look alike. A case that is skipped because it is unreliable is producing no evidence right now. A case that is skipped because the feature is switched off is a different fact and should be recorded as such, against the switch rather than against the criterion. - Report disabled cases in the same view as unlinked criteria, not in a separate suite-health page that a different person reads. ## When the skip is still the right call None of this argues for leaving an unreliable case in the running set. A case that fails randomly trains people to ignore failures, and that costs more than either kind of gap. The discipline is not "never skip"; it is **never let a skip be silent**. Disable the case, keep the link, and let the criterion fall back into the unverified column where a reader can see it, with a name and a date attached. That way the cost of the skip lands on the person who chose it, in the week they chose it, instead of on whoever is holding the release months later. The senior version of the answer adds one more thing: check what the case asserted before you fix it. A case that has been disabled for a long time is a poor guide to what the criterion needs today, because the criterion may have changed underneath it. Re-enabling it green is not the same as verifying the requirement — it may only mean the case no longer checks anything that matters.
- How do you stop a temporary skip from becoming a permanent one?Record an owner and an expiry beside the skip, and put that expiry where the team already looks. When it passes, the choice is explicit: repair the case, replace it, or write down that the criterion is unverified. A skip with no expiry has already become permanent; nobody has noticed yet.
- A case is quarantined for being unreliable rather than broken. Does its criterion still count as unverified?Yes, while it is quarantined. A case whose result is ignored produces no evidence, so the criterion behind it has none either. Quarantine is a legitimate way to stop an unreliable case blocking everyone, but the honest reading moves that criterion into the unverified column until the instability is fixed — which is also what keeps quarantine short.
- A case disabled a year ago now passes when you re-enable it. What have you learned?Less than it looks. The criterion may have changed while the case sat still, so a green result can mean the case no longer checks anything that matters rather than that the behaviour is correct. Read what it asserts against the criterion as it stands today before you treat the pass as evidence.
It is a smoke alarm with the battery taken out: the fixture on the ceiling still tells everyone who walks in that the room is protected.
saying these in an interview costs you the question
- Treats the presence of a link as proof that something ran
- Says a skipped case is safer than having no case
- Leaves skips in place with no owner and no expiry
- Reports disabled cases as verified because the chain joins up
- Re-enables a long-skipped case without checking what it still asserts