What are entry criteria for a test cycle, and what do they prevent?
answer
- Conditions before the cycle may start
- Build, environment, data, agreement
- Answerable yes or no by an outsider
- The smoke subset green on this build
- The agreed way to say not yet
basics
~20 sEntry criteria are the conditions that must hold before a test cycle starts: a deployed build with a known change list, a healthy environment, seeded data, and agreed acceptance criteria. They prevent a cycle from burning its budget on setup failures.
solid answer
~50 sEntry criteria are the agreed conditions that must be true before a test cycle is allowed to start — often called a **definition of ready for test**. The usual set: a build deployed to the intended environment with a published change list, the environment healthy and its dependencies reachable or stubbed, test data seeded to a known state, acceptance criteria agreed and testable, and the smoke subset green on that exact build. The point is not ceremony. A cycle started on a half-ready build spends its time diagnosing infrastructure, and every failure it reports has to be re-triaged once the setup is fixed. Entry criteria also give whoever owns the cycle a defensible way to say *not yet* without it sounding like an opinion. Keep them few, binary and observable — each one answerable yes or no by somebody who was not in the room when it was written.
code
pseudocode · 14 linesready_for_test(cycle):
checks = [
("build deployed to test env", deployed_version(env) == cycle.build),
("change list published", cycle.change_list is not empty),
("dependencies reachable", all(ping(d) for d in env.dependencies)),
("data seeded", seeded_personas(env) == expected_personas),
("smoke subset green", smoke_result(cycle.build) == "pass"),
]
unmet = [name for (name, ok) in checks if not ok]
if unmet is empty:
return START
if waiver_recorded_for(unmet, approved_by=cycle.owner):
return START_WITH_WAIVER
return HOLDgo deeper
Be ready to list the usual entry conditions in your own words — build deployed and identified, environment up, data seeded, acceptance criteria agreed, smoke subset green — and to say why starting without them wastes the cycle.
An interviewer expects you to explain the wording discipline: each criterion binary and observable, checked by someone uninvolved, few enough to verify in minutes. Show that you know 'stable enough' is not a criterion.
Demonstrate that you have used them under pressure: a recorded waiver instead of a silent start, re-triage of failures contaminated by a bad environment, and the habit of attributing lost time to the unmet condition rather than to slow testing.
Own the tradeoff between a set so loose it is decorative and one so strict nothing starts. Be able to say how you would tune the criteria after a quarter of evidence, and how waivers get reviewed rather than accumulated.
## What an entry criterion is An **entry criterion** is a condition the team has agreed must hold before a test cycle is allowed to begin. It is a *process* condition, and that is what separates it from the other thing called a criterion in the same conversation: a feature's **acceptance criteria** describe what the software must do to be considered correct, while an entry criterion describes whether the situation is fit for anyone to start checking anything at all. Teams that work in short iterations often carry the same idea under the name **definition of ready for test**. ## The usual set Most teams' entry criteria fall into five families. 1. **Build identity.** A build is deployed to the intended environment and you can name exactly what is in it — a version string, and a change list of what merged since the last cycle. Without this, a failure cannot be attributed and a fix cannot be confirmed. 2. **Environment health.** The environment is up, its collaborators are reachable or replaced by agreed stand-ins, and background jobs and schedulers are in the state the cases assume. 3. **Data readiness.** Test data is seeded to a known state, including the awkward accounts — the expired one, the one at a limit, the one in a locale that formats dates differently. 4. **Agreement.** Acceptance criteria for the scope are written, reviewed and testable; anything ambiguous has been raised before execution rather than discovered as a disputed defect. 5. **A live check.** The smoke subset passes on that exact build. This is the one criterion that is not a promise but a measurement, and it is usually the most valuable of the five. ## Few, binary, observable The quality bar for an entry criterion is whether a person outside the conversation can answer it yes or no. "The build is stable enough to test" fails that bar: stable by whose judgement, measured how? "The smoke subset passed on build 4.19.2 in the shared test environment" passes it. Vague criteria do not merely fail to help — they are worse than nothing, because they create the appearance of a gate while leaving the decision exactly where it was, in the loudest person's hands. ## A worked cycle An 11-person team building a document e-signing flow agrees five entry criteria for each cycle. On one cycle the build lands at 09:40 with a change list of 14 merges, but the signature-callback dependency is returning errors and the data seed produces only 3 of the 9 signer personas the suite assumes. The criteria are not met; the cycle starts anyway, because the date is close. By mid-afternoon, 22 of the first 31 failures trace to the missing personas and the unreachable callback. All 22 have to be re-run once the environment is repaired, and two of them were filed as defects and had to be withdrawn — which cost developer time as well as test time. The one genuine defect of the day, an off-by-one at the signer-limit boundary where an envelope capped at 12 signers quietly accepted a 13th, is not found until the following morning. The lesson is not the defect. It is that a day of execution produced results nobody could trust, and the team paid for the same cases twice. ## The two failure modes Entry criteria go wrong in both directions. **Too loose**, and they are decoration: nobody checks them, cycles start on anything, and the criteria are quoted only in the post-mortem. **Too strict**, and no cycle ever legitimately starts — "zero open defects in the component" is the classic overreach, since a component always has open defects and the team simply learns to ignore the list. A useful set is short enough to check in a few minutes at the start of the cycle. When a criterion cannot be met and the team decides to proceed anyway, that should be a recorded **waiver**, not a silence: which criterion was unmet, who decided to proceed, and what the expected cost is. The waiver is what makes the later conversation about wasted effort a fact rather than a memory. ## Who owns them The criteria are agreed by the people affected — whoever produces the build, whoever owns the environment, and whoever executes — and written before the cycle rather than argued during it. Ownership matters because the value of an entry criterion is almost entirely in the moment of pressure: it exists so that *not yet* is a previously agreed position rather than an individual's resistance. ## The symmetry with the exit side Entry criteria protect the cycle's budget; exit criteria protect the release decision. Both work by the same discipline — written in advance, phrased so they can be checked, and either met, waived on the record, or not met. A team that gets the entry side right usually finds the exit conversation easier, because it is already in the habit of stating conditions instead of impressions.
- Who decides that an entry criterion has been met?Whoever owns the cycle checks it, but the criterion has to be phrased so that the check is not a judgement call — a version match, a green smoke result, a seeded-data count. If deciding whether a criterion is met needs a debate, the criterion is written wrong. Agreement on the wording belongs to everyone affected: the people who produce the build, own the environment and execute the cases.
- The date is fixed and an entry criterion is unmet. What do you do?You can still start — the criteria are not a veto — but you record a waiver naming the unmet criterion, who decided to proceed and the expected cost, and you plan for re-execution of anything the gap contaminates. What you must not do is start silently, because then the wasted re-runs look like slow testing rather than a known consequence of a known decision.
- How is an entry criterion different from a feature's acceptance criteria?An acceptance criterion is about the software: it states an observable behaviour the feature must exhibit. An entry criterion is about the situation: it states whether the build, environment, data and agreements are in a state where checking that behaviour is worth doing. Confusingly, a written and agreed set of acceptance criteria is itself often one of the entry criteria — but the two answer different questions.
A pre-flight checklist: none of the items make the flight succeed, they only establish that starting is not a waste of fuel.
saying these in an interview costs you the question
- Treats entry criteria as paperwork with no power to delay a cycle
- Writes criteria like 'the build is stable' that nobody can check
- Confuses entry criteria with a feature's acceptance criteria
- Demands zero open defects before any cycle may start
- Starts on an unready build without recording the decision
- Assumes readiness is the environment owner's problem alone