How to Define Entry and Exit Criteria in Testing With Clear Evidence

The build is deployed, the test window has started, and someone says the feature is ready. The tester then discovers that the required account cannot be created and the expected result refers to an older requirement. A readiness label has replaced a decision the team could have checked before execution.

Entry criteria in testing define the preconditions for starting a particular activity. Exit criteria define what must be achieved to declare that activity complete. Useful criteria identify an observable condition, the evidence supporting it, the person accountable for it, and what happens when it remains unmet. They also specify which candidate and circumstances the decision covers.

Name the Activity and the Decision It Supports

Start with a bounded statement: “Evaluate customer-record export authorization on candidate EXP-A in staging against permission-policy revision P3.” That is specific enough to identify necessary inputs and meaningful completion evidence. “Start QA” leaves both unclear.

Record the activity's objective, included behaviors, exclusions, candidate, environment, and expected-behavior source. Identify who decides whether it may begin and who receives its completion findings. A short exploratory session, an integration check, and a release-candidate regression run need different gates because they support different decisions.

Keep adjacent concepts separate:

• Acceptance criteria describe expected behavior for a feature or story, such as refusing an export when the user lacks permission.
• A Definition of Ready is a team's agreement about work being sufficiently understood and actionable. A formally named checklist is a local practice, not a required Scrum artifact.
• In Scrum, the Definition of Done describes the quality state required of an Increment. Completing one test activity does not establish that the whole Increment meets it.
• Test entry and exit criteria govern the readiness and completion of the defined testing activity. They can reference those other agreements without replacing them.

Release authority is another boundary. A QA lead may confirm completion of the agreed evaluation and still advise against release. The organization must identify who can authorize deployment and accept residual risk. Finishing the test window does not give the tester that authority.

Turn Each Criterion Into a Checkable Record

A criterion should allow another qualified person to reach the same conclusion from the retained evidence. “Environment ready” gives them little to inspect. “The deployment record identifies EXP-A, and the sign-in and export-service health probes pass after that deployment” names observable conditions.

Use this procedure to turn a broad expectation into a usable record:

1. State the condition and scope. Describe what must be true, for which activity and candidate, without relying on words such as adequate or stable alone.
2. Choose the evidence. Identify a recoverable requirement revision, deployment record, fixture check, execution result, defect record, or review decision. Specify what part supports the condition.
3. Assign accountability. Name the person responsible for supplying the condition and the person verifying it. Identify the authority for an exception separately.
4. Define validity. Record when the check occurs and what changes invalidate it, including a new deployment, changed policy, modified fixture, or unavailable dependency.
5. Specify the response. State whether an unmet condition blocks the activity, permits an explicitly limited subset, or requires escalation under the team's policy.

These fields are a suggested recording convention, not a universal standard or mandatory tool schema. One person may supply and verify evidence where the process allows it. Where independent review is required, assign a different verifier explicitly.

For example: “Before export-authorization execution, Leo supplies a fixture-check result showing that permitted and denied accounts exist in staging under P3; Sofia verifies their effective permissions after the deployment. If either account is unavailable, the corresponding execution cannot begin.” A test-data filename alone would not demonstrate that the accounts have the required state.

Choose Entry Criteria That Protect This Test

Select prerequisites by asking what could prevent valid findings for the stated objective. Avoid importing every criterion from a larger release process. Test design may begin with agreed examples before a runnable build exists; execution against a deployed integration needs different evidence.

For the export-authorization activity, useful entry checks could cover:

• Expected behavior: policy P3 identifies who may export, what revocation means, and the expected denial outcome.
• Candidate and configuration: staging identifies EXP-A and the permission configuration intended for this evaluation.
• Data and access: permitted, denied, and revocable test accounts are available, and the tester can restore their starting states.
• Dependencies and observation: the export service is reachable, and the team can inspect the response, generated file, and relevant audit event.
• People and response paths: a named policy owner can resolve ambiguous expectations, and an environment owner can investigate invalid setup.

A missing dependency need not stop unrelated testing. The activity owner can define a smaller independent scope, record the exclusion, and agree which decision that evidence can support. Testing a screen while its export service is unavailable cannot later be reported as completed export-authorization evaluation.

Review readiness close enough to execution that the evidence still describes the intended setup. Use change-based invalidation rather than inventing a universal freshness window. An account check can become stale immediately after a role change, while an unchanged reviewed policy may remain applicable much longer.

Set Exit Criteria Against the Agreed Objective

Write exit criteria before execution so the team knows what evidence it intends to obtain. For this activity, an exit condition might require the permitted export to succeed and the denied and revoked-permission attempts to produce the specified refusal without exposing customer records. Those are outcome checks, not merely confirmations that test steps were attempted.

Include the disposition of incomplete scope and defects. A blocked check leaves a question unanswered. A failed authorization check supplies evidence of an unacceptable outcome under the example's policy. A defect marked resolved still needs the agreed verification evidence before its associated criterion can be treated as met.

Do not choose a pass-rate or coverage percentage without explaining what is counted and why the threshold supports the decision. A large collection of successful presentation checks cannot compensate for an untested permission boundary. If the team uses a numerical measure, retain the included population, excluded scope, result categories, and rationale for its locally agreed target.

Time and budget may also constrain when testing stops. The ISTQB Foundation Level syllabus recognizes that testing can end without other exit criteria being satisfied when stakeholders review and accept the risk of proceeding without further testing. Record that decision honestly: the activity stopped with identified gaps. The deadline did not turn missing evidence into a pass, satisfy an unmet Definition of Done, or override required organizational controls.

Work Through an Export Authorization Gate

The following is a fictional worked example, not a customer case or a run performed in a tool. Sofia leads a bounded integration evaluation of EXP-A in staging. Ana owns permission-policy P3; Leo owns the environment and fixtures. The scope covers permitted export, denial without permission, and revocation before export. Load testing and a broader privacy assessment are excluded.

The table combines an initial entry review with a later execution review to show how observations develop. The entry fixture problem is corrected before execution begins; the exit observations occur afterward.

Criterion	Evidence Source	Accountable Owner	Check	Outcome
Entry: intended candidate is deployed	Deployment record D-A	Leo	Sofia matches EXP-A and staging configuration	Met at entry review
Entry: expected authorization behavior is agreed	Policy P3 and review decision	Ana	Sofia checks permitted, denied, and revocation outcomes	Met at entry review
Entry: required account states can be established	Fixture check F-A	Leo	Denied account is missing; Leo restores it and Sofia repeats the check	Initially unmet; met after recheck
Exit: permitted export matches P3	Result R-ALLOW and generated file	Sofia	Compare returned records with the permitted fixture	Met on EXP-A
Exit: denied export produces the required response and audit event	Result R-DENY and audit evidence	Sofia	Response shows denial, but the required audit event cannot be inspected	Unverified; audit check blocked
Exit: revocation prevents export	Result R-REVOKE and defect BUG-A	Sofia	A file is returned after permission revocation	Unmet; observed failure

Sofia can explain why execution started: the missing account was restored, and its repeated check satisfied the entry condition. She cannot declare the agreed exit conditions met. R-DENY establishes part of the denial behavior, but the unavailable audit evidence leaves another part unverified. R-REVOKE establishes a failure that requires correction and verification under this activity's policy.

The next actions are specific. Leo restores audit access so Sofia can complete the affected check. Engineering investigates BUG-A. After a corrected candidate is deployed, Sofia identifies which earlier observations remain applicable and repeats the affected execution. The original failed result remains part of the record.

Record Unmet Conditions and Conditional Decisions Separately

A gate record needs to preserve both the observed condition and the decision about continuing. Combining them into one green status hides whether the evidence was satisfactory or someone accepted a limitation. Agree the vocabulary before the first review.

Preserve the Condition and Its Observed Status

A practical local scheme is met, unmet, unverified, and not applicable with rationale. Record a blocked verification as the reason a condition remains unverified. Distinguish that from a product failure observed during a completed check.

Permission to continue is a separate decision. If a required observation is unavailable, record the missing evidence, affected scope, owner, and next action. Do not mark it met because the system seems likely to behave correctly. Not applicable also needs an explanation tied to scope; it should not become a convenient category for difficult tests.

Keep the criterion version that governed the review. If new information genuinely changes the activity, record the revised scope or condition, its rationale, approver, and effect on earlier evidence. Quietly weakening a failed criterion would erase the basis for the original decision.

Authorize Only a Defined Exception

Suppose the fictional team also has a local condition requiring review of the export screen's explanatory label. The label differs from the agreed wording, but Ana determines that the discrepancy does not change the permission behavior. If the organization's policy permits it, a named activity decision owner could authorize continuation with that limited documentation issue outstanding.

The exception should identify the original condition, observed discrepancy, evidence, consequence, permitted scope, accountable approver, containment, expiry or terminating event, and follow-up owner. “Proceed with caution” provides no usable boundary. The record should still show the label condition as unmet, with a separate conditional-continuation decision.

That label exception does not cover BUG-A or the missing audit observation. Under this fictional policy, Sofia has no authority to waive the authorization requirement. She escalates the blocked decision rather than borrowing approval from an unrelated exception.

Determine exception eligibility from the applicable organizational, contractual, regulatory, and product obligations. A local gate exception cannot make unfinished work satisfy Scrum's Definition of Done or authorize bypassing a mandatory control. If no permitted exception authority exists, the activity remains blocked or stops with its unmet conditions recorded.

Recheck Evidence When the Candidate Changes

Bind evidence to the thing evaluated: candidate identity, relevant configuration, environment, data state, expected-behavior revision, test specification, execution result, and check time. A result described only as “latest regression passed” becomes difficult to interpret after any of those inputs changes.

Define recheck triggers with the people who understand the dependencies. A permission-policy change can invalidate expected outcomes; an account reset can invalidate data readiness; a deployment can invalidate candidate-specific results. Review the impact and repeat the affected checks. Preserve the earlier evidence rather than relabeling an old pass as proof for the new setup. The guidance on recovering test specifications and run snapshots develops the connection between approved content and historical execution.

For a team using Sherlock Test Management, its current product description provides a relevant supporting model: AI-proposed case changes require human acceptance, approvals create baseline versions, and finished runs remain associated with the version executed. It also describes recording Pass, Fail, or Blocked results. Those records can support the gate review, while the team still supplies candidate context, evaluates unmet conditions, and records its authorized decision. The Sherlock baseline and run workflow describes app-managed capabilities, not native Jira behavior or an automatic release-approval mechanism.

Before adopting a gate, ask a colleague to recover the evidence for one met condition and one blocked condition without relying on the author's memory. They should be able to identify what was checked, whether it still applies, who owns the gap, and which decision is permitted next. Repair any ambiguity before using the record to start or close the next testing activity.