Entry and exit criteria (2026)

TL;DR

Entry criteria are the conditions that make a planned test activity ready to begin. Exit criteria are the evidence conditions that make it reasonable to stop, transition, or recommend a decision. Effective criteria are specific, observable, risk-based, owned, and paired with an explicit exception process.

Key Takeaways

• Entry criteria confirm that a test activity can produce trustworthy evidence, while exit criteria define when that evidence is sufficient for a decision.
• Every criterion should name a measurable signal, owner, evaluation point, and exception path.
• A missed criterion creates a decision about risk, it should not trigger an automatic pass or fail without context.
• Use different criteria for component, API, system, migration, performance, accessibility, and production validation activities.
• Defect counts and pass percentages are supporting signals, not proof that testing is complete.
• Record waivers with impact, compensating controls, accountable approval, expiration, and follow-up.

Entry and exit criteria turn vague statements such as ready for QA and testing is done into reviewable conditions. Entry criteria protect the validity and efficiency of a test activity. Exit criteria describe the evidence needed to finish that activity and inform the next decision, including a release decision.

The goal is not to build a ceremonial gate. Useful criteria expose assumptions, dependencies, residual risk, and decision ownership. This guide shows how to define them for Agile delivery, APIs, migrations, nonfunctional testing, automation, and production rollout.

TL;DR

Criteria guide a decision. They do not transfer accountability to a spreadsheet or dashboard.

1. What Are Entry and Exit Criteria?

Entry and exit criteria are observable conditions attached to a defined test activity or delivery transition. Entry criteria answer whether prerequisites are adequate to begin. Exit criteria answer whether planned evidence is complete enough to stop, hand off, deploy, or make another accountable decision.

For system testing, entry might require a uniquely identified build, deployed interfaces, stable identity provider, test accounts, approved acceptance examples, health checks, and known environment limitations. Exit might require priority risk coverage, acceptable results on critical journeys, reviewed defects, completed required accessibility evidence, and a documented residual-risk summary.

Criteria are contextual. Unit testing, contract testing, exploratory sessions, performance experiments, disaster recovery exercises, and production canary validation need different readiness and completion signals. A universal checklist usually becomes either too weak to protect anything or too large to use.

Do not confuse exit criteria with a claim that no defects remain. Testing samples product behavior under selected conditions. Exit criteria make the stopping logic and uncertainty visible. They also create a shared vocabulary for tradeoffs. Instead of QA is blocking, the team can discuss which condition is unmet, why it matters, what evidence could satisfy it, and who can accept the exception. The software test plan template provides a broader home for criteria, scope, environments, and responsibilities.

2. Distinguish Gates, Definitions, and Acceptance Criteria

Several delivery concepts sound similar but operate at different levels. Acceptance criteria define expected product behavior for a story or capability. A definition of ready describes team expectations before work enters a workflow stage. A definition of done describes the shared completion standard for an increment. Entry and exit criteria apply to a named test activity, phase, environment, or release decision. A quality gate is a control point that evaluates selected signals.

These can reinforce one another without being copied. A story can meet its acceptance criteria while the release remains unsafe because a migration rehearsal failed. A build can enter exploratory testing despite incomplete documentation if learning is the goal. A performance test should not start when shared background traffic makes measurements invalid, even if functional testing is complete.

Keep each artifact close to its decision. Duplicated rules drift, especially when multiple teams own pipelines, release checklists, and test management tools. Link to the authoritative condition and show its current evaluation rather than rewriting it everywhere.

3. Design Measurable Testing Entry Criteria

Begin with the question: what must be true for this test to produce trustworthy, timely evidence? Group prerequisites by product, build, environment, data, people, oracles, tools, and dependencies. Then remove conditions that do not protect the purpose of the activity.

A good entry criterion is specific and observable. Environment is stable is weak. Deployment health checks pass, identity and payment sandbox probes succeed, and no known environment issue invalidates the planned checkout scenarios is testable. Requirements complete is unrealistic. Acceptance examples for discount stacking are approved, with two open assumptions listed in the session charter may be sufficient.

For each criterion, record:

• The exact signal and its source.
• The owner who supplies or verifies it.
• When it is evaluated and how long it remains valid.
• Why failure matters to the test objective.
• Whether it is mandatory, conditional, or advisory.
• The escalation or waiver path.

Entry is not necessarily all-or-nothing. If profile editing is ready but invoice generation is blocked, testers can begin the independent scope. Document the partition so results are not later reported as full system coverage. If the purpose is early learning, a rough prototype may satisfy entry even though it could not support formal release evidence. Match rigor to the decision.

4. Design Risk-Based Testing Exit Criteria

Start with the decision the evidence must support. Feature completion, integration handoff, migration approval, and public release have different consequence. Identify unacceptable outcomes, priority risks, required controls, and known uncertainty. Then define evidence that reduces those risks to the organization's tolerance.

Useful exit dimensions include planned risk coverage, critical scenario results, unresolved defect disposition, regression scope, required nonfunctional evidence, traceability for regulated controls, environment validity, flaky-test treatment, and stakeholder review. Use quantitative thresholds only when the measurement is meaningful and its denominator is clear.

95 percent tests passed is weak if the failed 5 percent contains payment authorization or if many tests were never designed for a new risk. Prefer All release-critical payment and entitlement scenarios passed on candidate build RC-7; two medium display defects have documented workarounds and accepted risk. Counts can summarize, but risk statements decide.

Exit criteria may include completed learning rather than all-green results. A time-boxed exploratory session can exit when the charter is executed, notes are debriefed, material findings are filed, and follow-up risks are assigned. A performance experiment can exit with a failed hypothesis if measurements are valid and the next decision is clear. The risk-based testing guide explains how to rank coverage before writing completion conditions.

5. Build Criteria for Functional and API Testing

For feature testing, entry commonly includes a deployed identifiable build, testable acceptance examples, available accounts and roles, controlled data, dependency status, and sufficient observability. It may also require developer checks, but avoid using QA entry as the first place code is exercised. Include interface contracts when multiple services change.

Example functional entry criteria:

1. Candidate build and commit are recorded.
2. Smoke probes for sign-in, catalog, and checkout pass.
3. Required buyer, administrator, and support roles exist.
4. Payment sandbox and email stub are reachable.
5. Test data reset is available and documented.
6. Known limitations are listed against planned scenarios.

API exit criteria should validate more than status codes. They may require contract compatibility, authorization by role and resource, idempotency for retries, boundary and invalid payload results, persistence, emitted events, observability, and consumer-critical flows. If a service introduces a backward-incompatible contract, a perfect local test pass does not meet an integration exit condition.

Keep smoke entry probes minimal and diagnostic. If the smoke suite takes an hour or mutates shared data unpredictably, it delays feedback and obscures the failed dependency. Separate environment health from product acceptance. A healthy database does not prove the deployed feature is correct, and a product defect does not always mean the environment is invalid.

6. Define Criteria for Regression and Automation

Regression entry criteria should confirm that the change set is known enough to select coverage, the candidate build is deployed, impacted components are available, required data is controlled, and the automation environment represents the intended target. If change impact is uncertain, that uncertainty should expand discovery or exploratory work rather than pretending the suite is universally comprehensive.

Automation results need quality checks before they support exit. Classify failures as product defect, test defect, environment failure, data issue, unsupported configuration, or unknown. Rerunning until green hides information. A flaky critical check may mean the product is fine, but it also means the evidence is unreliable. State whether the behavior was verified through an independent method and create an owner for test repair.

Possible regression exit criteria include:

• All selected critical checks produce trustworthy results on the candidate build.
• Every failure is investigated and dispositioned.
• Manual or service-level evidence covers any quarantined critical automation.
• Changed components receive the agreed exploratory and integration coverage.
• Unresolved product risks have accountable decisions.

Do not set 100 percent automated tests passed as a universal gate. Obsolete tests, infrastructure outages, and unrelated quarantined checks can block delivery without increasing confidence. Conversely, a green suite may omit the changed risk. The regression testing strategy guide shows how to build a change-informed scope.

7. Define Criteria for Nonfunctional Testing

Performance entry criteria protect measurement validity. Require a representative topology and configuration, controlled workload generators, synchronized clocks, stable monitoring, known background traffic, test data scale, observability across dependencies, and agreed workload models. Running a load test against an undersized shared environment can be useful for debugging, but it cannot support a production capacity conclusion unless that limitation is explicit.

Performance exit criteria should refer to business outcomes and measured percentiles or resource behavior with defined sampling. Avoid inventing a target after seeing results. State transaction mix, duration, data volume, cache state, error classification, and excluded intervals. Averages can hide tail latency, so use the statistic specified by the service objective.

Security entry may require authorized scope, safe accounts, data handling controls, contact and stop conditions, and isolated targets. Exit may require disposition of findings, retest of remediations, compensating controls, and sign-off by the designated security owner. Accessibility exit might require keyboard, name-role-value, focus, contrast, zoom, screen reader, and automated checks according to the product's stated standard, plus reviewed exceptions.

Recovery testing needs known failure injection, backups, restoration ownership, rollback procedures, observability, and protection against shared-environment damage. Its exit criteria should cover restored service and data integrity, not just successful process completion. Nonfunctional evidence is decision-specific and should not be compressed into one generic NFR passed checkbox.

8. Handle Data Migration and Release Readiness

Migration testing has unusually important entry conditions because invalid setup can create false confidence or permanent damage. Require a versioned migration artifact, representative sanitized dataset, backup and restore proof, mapping rules, reconciliation queries, expected reject handling, idempotency policy, runtime estimate method, and a rehearsal environment that matches relevant production characteristics.

Exit should cover record counts by meaningful category, financial or domain totals, referential integrity, rejected and transformed records, sampling of high-risk entities, application behavior on migrated data, audit fields, performance, rollback or forward-fix evidence, and sign-off from data owners. Matching total row count is insufficient. A duplicated account and a missing account can cancel numerically.

Release readiness combines evidence without reducing it to QA approval. The release owner should see critical path status, unresolved risks, migration result, security and compliance obligations, monitoring, feature controls, rollback readiness, support communication, and incident contacts. QA provides a recommendation and its basis. The accountable business or release role decides whether residual risk is acceptable.

Use staged rollout criteria where possible. Entry to a canary might require a healthy candidate and dashboards. Exit from canary might require error, latency, business outcome, and support signals within agreed bounds for a defined observation window. Specify what triggers expansion, pause, or rollback before rollout begins.

9. Manage Exceptions, Waivers, and Changing Scope

A criterion can be missed for a legitimate reason. The safe response is an explicit exception, not a quiet edit to make the dashboard green. Record the unmet condition, why it matters, current evidence, affected scope, worst credible outcome, compensating controls, accountable approver, expiration, and follow-up.

For example, a target mobile device may be unavailable. The team could proceed using the previous OS version and device cloud coverage if the change is service-only, while limiting rollout and monitoring device-specific crashes. That is a reasoned exception. Simply deleting the device from scope after testing begins hides residual risk.

Criteria also change when scope changes. If a feature flag removes a capability from the release, update the test scope, release configuration, customer exposure, rollback plan, and future activation entry conditions. Confirm the path is actually unreachable, not merely hidden in the UI. If a dependency is deferred, retest assumptions at the interface.

Maintain a decision log for material waivers. Repeated exceptions expose systemic problems such as unstable environments, late requirements, unavailable data, or weak automation. Fix the source rather than normalizing permanent waivers. An exception process should make responsible delivery possible, not provide a shortcut around inconvenient evidence.

10. Automate Quality Gates Transparently

Pipeline automation can evaluate objective criteria, such as required jobs, artifact identity, contract results, and approved deployment configuration. Human-reviewed conditions, such as accepted residual risk, should remain explicit inputs with an audit trail. Do not bury the entire release decision in an opaque score.

This runnable Node.js example evaluates a small release gate. Save it as gate.mjs and run node gate.mjs:

const release = {
  buildId: 'rc-17',
  criticalChecks: { passed: 48, failed: 0, unknown: 0 },
  highRisks: [],
  rollbackVerified: true,
  approver: 'release-owner'
};

function evaluate(candidate) {
  const failures = [];
  if (!candidate.buildId) failures.push('build identity missing');
  if (candidate.criticalChecks.failed > 0) failures.push('critical checks failed');
  if (candidate.criticalChecks.unknown > 0) failures.push('critical results unknown');
  if (candidate.highRisks.some((risk) => !risk.acceptedBy)) {
    failures.push('high risk lacks accountable decision');
  }
  if (!candidate.rollbackVerified) failures.push('rollback not verified');
  if (!candidate.approver) failures.push('release owner missing');
  return { ready: failures.length === 0, failures };
}

const result = evaluate(release);
console.log(JSON.stringify(result, null, 2));
process.exitCode = result.ready ? 0 : 1;

The code checks observable facts and accountability, not whether the product is defect-free. In a real pipeline, protect approval identity, prevent stale evidence, bind results to the exact artifact, and show why a gate failed. Allow an authorized exception through a separate recorded path rather than editing results.

11. Review and Improve Entry and Exit Criteria

Review criteria after releases, incidents, delays, and false blocks. Ask which conditions predicted trouble, which were ignored, which produced ceremony without information, and which important risks had no criterion. Sample the evidence source to make sure a green indicator still means what people think it means.

Measure outcomes such as time lost after premature entry, invalid test runs, unknown automation results at decision time, exception frequency, late discovery of unmet prerequisites, and escaped risks tied to missing evidence. Do not optimize only for gate pass rate. A gate that always passes may be irrelevant, while one that frequently fails may expose a real systemic constraint.

Assign owners to criteria and version material changes. Retire conditions when architecture or policy makes them obsolete. Add examples to ambiguous rules. Keep the primary set short enough to use, with detailed evidence linked underneath. Teams should understand why a condition exists and which decision it protects.

Run a pre-mortem for major releases: imagine the release caused severe harm, then ask what evidence would have warned the team. Add or strengthen criteria where the signal is feasible and proportional. Also ask whether rollback, monitoring, or gradual exposure can reduce the need for a brittle pre-release prediction. Entry and exit criteria should evolve with the product's risk, not fossilize around an old process.

12. Entry and Exit Criteria Templates

A compact criterion record can use: ID, activity, condition, evidence source, owner, evaluation time, status, risk if unmet, and exception authority. Keep status values controlled: met, unmet, not applicable with rationale, or waived with decision link. Avoid mostly done.

Example entry statement: SYSTEM-E3: Payment sandbox health probe and signed authorization test pass within 30 minutes of checkout execution. Owner: environment lead. If unmet, payment scenarios pause because results cannot distinguish product and dependency failure.

Example exit statement: SYSTEM-X5: All release-critical entitlement scenarios produce expected UI, API, and stored-state outcomes on the candidate build. Every failure is dispositioned, and any accepted residual risk names the release owner and monitoring condition.

Example suspension statement: PERF-S2: Pause measurements if background traffic changes by more than the agreed operating band or if telemetry loses dependency spans. Resume only after a clean observation interval and workload validation.

Use the template to sharpen reasoning, then link automation and reports. A dashboard should allow a decision maker to move from status to evidence and owner quickly. If a criterion cannot be explained in one or two sentences, split it or clarify the protected risk.

Interview Questions and Answers

Q: What are entry criteria in testing?

Entry criteria are the observable prerequisites needed for a test activity to produce useful evidence. They can cover build identity, environment, data, dependencies, oracles, tools, and people. I tailor them to the activity instead of applying a universal checklist.

Q: What are exit criteria in testing?

Exit criteria describe the evidence conditions needed to finish or transition a test activity and support the next decision. They include risk coverage, trustworthy results, defect disposition, required controls, and residual-risk communication. They do not prove the absence of defects.

Q: Is 100 percent test pass a good exit criterion?

Not by itself. The suite may omit important risks, include obsolete checks, or hide unknown results through reruns. I focus on critical risk evidence, failure disposition, coverage validity, and explicit accepted exceptions.

Q: Who approves an exception to exit criteria?

The person or role accountable for the affected business or release risk should approve it. QA explains the evidence and consequence, while engineering explains technical and recovery factors. The waiver should include compensating controls and an expiration.

Q: Can testing begin if an entry criterion is not met?

Yes, if the team consciously changes the activity, partitions ready scope, or accepts the risk through the defined authority. The unmet condition and limitation must remain visible so partial evidence is not later presented as complete coverage.

Q: How are exit criteria different from acceptance criteria?

Acceptance criteria define expected feature behavior. Exit criteria define when a test activity has enough credible evidence for a transition or decision. A feature can satisfy acceptance examples while release-level migration or security exit criteria remain unmet.

Q: What is a suspension criterion?

It defines a condition under which continuing the test would be unsafe, wasteful, or produce invalid evidence. A matching resumption criterion states what must be restored and rechecked before execution continues.

Q: How do you create risk-based exit criteria?

I identify the next decision, unacceptable outcomes, high-priority product risks, and required controls. Then I define observable evidence for those risks, plus defect disposition and exception ownership. Counts support the summary but do not replace the risk argument.

Common Mistakes

• Writing subjective conditions such as environment stable or testing complete.
• Copying one checklist across every test level and product.
• Treating a pass percentage as proof of acceptable risk.
• Changing scope silently when a criterion is difficult to meet.
• Letting reruns convert unknown automation into green evidence.
• Creating gates without owners, evidence sources, or exception authority.
• Blocking early learning because production-grade entry conditions are absent.
• Recording a waiver without compensating controls or expiration.
• Reporting QA sign-off without stating residual risk and decision ownership.
• Keeping obsolete criteria after the architecture or release process changes.

Conclusion

Entry and exit criteria make readiness, completion, and exception decisions visible. The best criteria protect evidence quality and important product risks while leaving accountable people room to respond to context. They are specific enough to evaluate, small enough to use, and traceable to owners and evidence.

Choose one current test activity and replace its three vaguest readiness or completion statements with measurable records. Add the risk if unmet and the exception authority. That small exercise usually exposes more delivery uncertainty than another generic checklist.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• AI test data generation with Faker and LLMs (2026)
• API error handling and negative testing: A Practical Guide (2026)
• Appium gestures and swipe: A Practical Guide (2026)
• Bug severity and priority examples (2026)
• Comparing GPT and Claude for QA tasks (2026)
• Cucumber data tables and scenario outline (2026)