Test Entry and Exit Criteria: QA Readiness Guide

Testing started on a build that could not produce evidence

QA received a candidate for a profile migration on Monday. Login was broken for migrated accounts, the data job had processed an unknown schema version, and logs did not include account identifiers. By Wednesday the team had filed eight environment defects and learned almost nothing about migration quality. The calendar said testing had started. Meaningful evaluation had not.

Entry and exit criteria protect the signal of a test activity. Entry criteria describe the observable conditions needed to begin that activity productively. Exit criteria describe the evidence and residual-risk conditions needed to stop or hand off responsibly.

They are not promises that software will be defect-free. They are decision controls. A criterion should tell someone what to inspect, who decides, and what happens when it is not satisfied.

Express every criterion as an observable check

“Environment ready” and “requirements complete” are labels, not criteria. Rewrite them so two people can reach the same conclusion.

Attach a source of evidence: build record, smoke result, requirement revision, fixture query, defect view, or monitoring panel. The criterion should not depend on a status copied manually into several documents.

Add an owner for the condition and a decision owner for exceptions. QA may verify that smoke tests pass, while the release manager decides whether to proceed after one non-critical dependency is unavailable.

Time-bound volatile evidence. An environment check from last week does not establish readiness after today’s deployment.

Build entry criteria around failure prerequisites

Entry criteria vary by test activity. Organize them by what could prevent valid findings.

Scope and expectation

• included change set and supported configurations are identified
• acceptance examples cover critical state transitions
• unresolved questions have owners and decision dates
• known exclusions are visible to the release owner

Test object

• build or package identity is immutable and traceable to changes
• developer and lower-level checks meet their agreed gate
• deployment and migration steps completed without unresolved error
• feature flags match the intended test cohort

Means of evaluation

• environment dependencies are reachable or approved simulations are active
• fixtures can create and reset critical states
• logs, events, and correlation identifiers expose important effects
• testers have required access without shared privileged credentials

People and time

• domain and technical contacts are available for triage
• planned window includes execution, correction, and retest
• external approval or specialist review is scheduled

Select only criteria that protect this activity. Requiring every design asset to be final before API contract testing would create a needless gate.

Run a readiness review before reserving the test window

Hold the review near the handoff, not after the team has spent a day discovering blockers. The owner presents evidence; QA samples it; dependencies confirm their part.

For the migration candidate, the review packet could contain:

• build and migration package identifiers
• change list and rollback instructions
• automated component and schema-check results
• count of fixture accounts by migration state
• smoke evidence for login, read, edit, and rollback
• list of open defects and approved limitations
• dashboard query for failed migration events

Use three outcomes: enter, enter with a recorded exception, or do not enter. “Almost ready” must resolve to one of them.

If entry is denied, return ownership to the missing condition rather than asking testers to remain idle. They may perform design, exploratory modeling, or fixture work, but the formal execution clock has not started.

Record the decision and evidence version. This helps distinguish product delay from test execution effort and reveals recurring readiness failures.

Manage exceptions without dissolving the gate

Sometimes the business should proceed despite an unmet criterion. An exception is legitimate when the missing condition, added exposure, containment, and authority are explicit.

An exception record needs:

Do not rewrite the criterion after it fails. That erases the learning. Preserve the exception so later reviews can see whether schedule pressure is repeatedly bypassing the same control.

Some criteria should be non-waivable within the team, such as unavailable authorization evidence for a high-risk access change. State who, if anyone, has higher authority and what escalation is required.

Tie exit criteria to risk and coverage

“All test cases executed” can coexist with severe uncertainty if the wrong cases ran or evidence is unreliable. Exit criteria should cover the leading product risks, planned scope, defects, and operational readiness.

For the profile migration:

• all critical migration states evaluated on the release candidate
• record counts and sampled field mappings reconcile before and after migration
• authorization behavior verified for user, support, and administrator roles
• rollback restores the agreed dataset without orphan records
• no unresolved defect can lose, expose, or misassign profile data
• lower-impact open defects have named impact, workaround, and acceptance
• production rollout signals, alert owner, pause rule, and rollback trigger are confirmed

Execution percentage may support the decision, but it is not the decision. If five low-priority cases remain, explain their coverage gap. If one critical recovery scenario is blocked, a high overall completion rate does not offset it.

Separate test exit from release approval. QA can state that planned evaluation is complete and still recommend against release. The business may accept residual risk through the documented authority.

Define completion for each test level

One universal gate creates confusion across fast feedback and release evaluation. Give each activity criteria appropriate to its purpose.

Handoffs should pass evidence forward. System testing should not rerun every component condition, but it should know which component evidence supports its scope. Production verification should focus on signals unavailable before release, not repeat the entire system suite against customer data.

For continuous delivery, encode fast criteria in pipelines where possible. Schema checks, smoke gates, required approvals, and blocking defect queries can be automated. Judgment-heavy risk acceptance remains a human decision with a recorded rationale.

Prevent criteria from becoming ceremonial

Criteria fail when they are too numerous, cannot be measured, have no owner, or are checked after the decision. They also fail when a team games them.

Watch for these patterns:

• cases are marked not applicable to raise completion
• failed checks are rerun without preserving the first result
• blocking defects are downgraded immediately before release
• the candidate build changes after exit evidence is collected
• exceptions have no expiry and become permanent policy
• “known issue” is used without impact or containment

Require change control on the tested object. If code, configuration, or data migration changes after exit, define which criteria and tests must be repeated. A tiny copy change may need a narrow review; a retry-policy change can invalidate integration evidence.

Keep the gate compact enough to operate. Ten high-value checks with direct evidence are stronger than fifty declarations everyone ticks from memory.

Audit whether the gates improve flow

Review entry failures and exit exceptions after each release. Classify causes such as unstable deployment, missing fixtures, ambiguous requirement, unavailable dependency, insufficient observability, late code, or unrealistic schedule.

Useful measures include time lost after premature entry, frequency of each waived condition, defects linked to bypassed criteria, candidate builds tested per release, and exit decisions later contradicted by production evidence.

Do not optimize for “100 percent entry pass.” If every candidate passes, criteria may be weak or teams may be fixing issues earlier, which is the desired result. Examine the evidence.

Retire a criterion when it no longer protects a plausible failure. Add one after a costly blocker or escaped risk, but first ask whether an existing condition was ignored. Keep the wording with the owning process so it changes when deployment or architecture changes.

Good criteria create clean boundaries in the delivery record: before entry, prerequisites were being established; during testing, valid evidence was being gathered; at exit, remaining exposure was known. That clarity makes schedules more honest and release decisions easier to defend.