Entry and Exit Criteria
Know when to start testing and when to stop. Without clear criteria, you burn budget on broken builds or ship before you're ready.
1 The Hook — Why This Matters
In 2023, a Christchurch-based SaaS company kicked off system testing for a major dashboard release. The build arrived on a Monday morning with no entry criteria checklist. The Test Lead assumed it was ready and handed it to the team. By Wednesday, 80% of tests had failed — not because the product was terrible, but because the test environment was pointing to a stale database, two microservices were still on the previous release, and the authentication token had expired over the weekend.
The testers spent four days debugging the environment instead of testing the software. When the real defects finally surfaced, the sprint was nearly over and retest time had evaporated. The release shipped late, over budget, and with known issues.
Contrast that with an Auckland fintech team who defined exit criteria before testing began: zero critical defects, 95% test case execution, performance benchmarks met, and security scan clean. When the criteria were green, the CTO signed off with confidence. When one criterion failed, the release was delayed by 48 hours — and nobody argued, because the rules were agreed in advance. Criteria remove politics from quality decisions.
2 The Rule — The One-Sentence Version
Entry criteria are the conditions that must be true before testing starts. Exit criteria are the conditions that must be true for testing to be considered complete.
Both must be specific, measurable, agreed by stakeholders, and written down before testing begins. Vague criteria (“the build should be stable”) create vague outcomes. Specific criteria (“all smoke tests pass in the target environment for three consecutive builds”) create accountability.
Concrete Examples
| Type | Criterion | Why It Matters |
|---|---|---|
| Entry | Code complete and merged to release branch | Ensures the build contains the features under test |
| Entry | All smoke tests pass in the target environment | Catches environment misconfiguration before the team wastes time |
| Entry | Test data anonymised and privacy-approved | Prevents regulatory breaches under NZ Privacy Act 2020 |
| Entry | Requirements traceability matrix updated | Ensures every requirement has at least one test case |
| Exit | 100% of planned test cases executed | Proves coverage; partial execution leaves unknowns |
| Exit | Zero critical / high-severity defects open | Critical defects in production are unacceptable risk |
| Exit | No new defects in 72 hours (stability window) | Catches late-breaking issues and flaky fixes |
| Exit | Performance benchmarks met (e.g., p95 < 2s) | Functional correctness is not enough; speed matters |
| Exit | Stakeholder sign-off received in writing | Protects the team from post-release blame |
3 The Analogy — Think Of It Like...
A restaurant kitchen.
Entry criteria are what the head chef checks before service starts: ingredients are prepped, stations are clean, ovens are at temperature, and the health inspector's last report had zero critical violations. If any of these are missing, service does not begin. Exit criteria are what must be true before a dish leaves the pass: it matches the ticket, temperature is correct, plating standards are met, and the expediter has signed off. The exit criteria do not say “the food tastes good.” They say “internal temperature exceeds 74°C and the garnish matches the menu photo.” Specific, observable, and non-negotiable. A test team without criteria is a kitchen without recipes: everyone is guessing, and the customers feel it.
4 Watch Me Do It — IRD Tax Filing Portal
Here is how a Test Lead would define entry and exit criteria for a new IRD tax filing feature on the New Zealand government web portal. Follow this pattern for any project you lead.
- Understand the business and regulatory context Tax filing has hard deadlines (e.g., 7 July for most individual returns). A delay is not just inconvenient; it may be illegal for users. This raises the bar on stability and data integrity criteria.
- Define entry criteria with named owners Each criterion has a person who can confirm it is met. Example: “Test environment provisioned and matching production topology” — owner: DevOps Lead. “Test data anonymised and signed off by privacy officer” — owner: Compliance Manager.
- Define exit criteria with measurable thresholds Avoid binary pass/fail where possible. Use numbers: 100% test case execution, zero P1/P2 defects, 95% of automated regression green, p95 response time under 2 seconds. Numbers remove argument.
- Add suspension and resumption criteria When do you pause testing? If the environment is down for more than four hours, or if a data corruption bug makes test results unreliable. When do you resume? When the environment is stable and the blocker is verified fixed.
- Get stakeholder sign-off before testing starts The product owner, development lead, and Test Lead all review and agree. This document becomes the contract that governs the release decision.
| Criterion | Detail | Owner |
|---|---|---|
| Entry: build | Deployed from CI/CD with green unit-test and static-analysis stages | Dev Lead |
| Entry: smoke | 100% of smoke tests pass in staging environment | Test Lead |
| Entry: data | Anonymised tax-year dataset approved by privacy officer | Compliance |
| Exit: coverage | 100% test cases executed; 95% automated regression pass | Test Lead |
| Exit: defects | Zero P1/P2 open; P3/P4 have accepted workarounds documented | Product Owner |
| Exit: performance | p95 page load < 2s; p99 API response < 500ms | Performance Engineer |
| Exit: sign-off | Product Owner and Test Lead sign release certificate | Both |
Scenario: A Waikato manufacturing company wrote exit criteria for a factory-floor MES system: "All tests pass, critical defects fixed, performance acceptable, operations team trained." Sounds good. But when release day arrived:
- "All tests pass" — Did not specify which tests or coverage target. Three regression tests were never executed.
- "Critical defects fixed" — No severity framework. One "critical" defect (a typo in a tooltip) was still open, but felt low-risk.
- "Operations trained" — Two out of five ops engineers attended training. The others were on holiday.
Result: Management said, "close enough," and shipped. In week one, a production incident crashed the floor scheduler, costing NZD 45,000 in lost production. The incident was caught by the three untested regression paths.
The fix: Criteria must be binary: either met or not met. "95% of automated regression suite executed and passed" is measurable. "Operations sign-off from all five floor leads before go-live" is verifiable. Vague criteria feel rigorous but enable the very politics they were meant to prevent.
5 When Rigid Criteria Help / When They Hurt
✅ Rigid criteria help when...
- The project has compliance or regulatory requirements (IRD, health, finance)
- Multiple vendors or teams need a shared definition of “done”
- The team has a history of shipping with last-minute “just this once” waivers
- Stakeholders are distant and need objective status reports
- Testing is outsourced and the contract depends on measurable deliverables
❌ Criteria become harmful when...
- They are so strict that testing can never realistically begin
- They become a bureaucratic checkbox exercise with no business value
- The team spends more time arguing about criteria than testing
- Criteria are written by people who will never execute them
- They cannot adapt to genuine scope changes or emergency patches
Before you define entry/exit criteria, ask:
- Who will enforce these criteria when pressure to ship increases? (Governance matters.)
- Are these criteria realistic for your team's velocity, or are they aspirational?
- How will you measure each criterion objectively? (If you cannot measure it, you cannot defend it.)
- Have you involved both developers and stakeholders in defining them, or are you imposing them unilaterally?
6 Common Mistakes — Don't Do This
🚫 Entry criteria that are impossible to meet
I used to think: Setting a high bar would force the team to improve.
Actually: Entry criteria like “zero known defects before system testing” are impossible in any non-trivial system. When criteria are unattainable, the team either ignores them or invents workarounds that undermine trust. Set criteria that are demanding but realistic. If 90% of projects fail entry, your criteria are broken, not your projects.
🚫 Exit criteria that ignore business risk
I used to think: “All tests pass” was a strong exit criterion.
Actually: “All tests pass” ignores whether the tests were any good, whether the right areas were covered, and whether the business can tolerate the remaining risk. A better criterion combines execution coverage, defect severity, stability windows, and stakeholder sign-off. Exit criteria must answer: “Is the remaining risk acceptable to the business?” not just “Did we run the tests?”
🚫 Changing criteria mid-project without stakeholder agreement
I used to think: If the deadline moved, I could just relax the exit criteria.
Actually: Changing criteria without written agreement is a unilateral risk transfer. If you lower the bar to hit a date, document who authorised it, what coverage was sacrificed, and what the business impact is. A Test Lead who quietly weakens criteria to avoid conflict becomes the person blamed when production fails. Transparency is protection.
🚫 Confusing exit criteria with “zero bugs”
I used to think: Testing isn't done until all bugs are fixed.
Actually: Zero bugs is a fantasy in complex software. Exit criteria define acceptable risk, not perfection. A low-severity UI alignment issue may be acceptable if the alternative is missing a regulatory deadline. The goal is informed consent: stakeholders understand what remains open, agree the risk is acceptable, and sign off. That is professional testing. Waiting for zero bugs is paralysis.
When this technique fails
Criteria without teeth fail silently. You write them, stakeholders nod, then pressure mounts: "Can't we just ship?" If you have no documented criteria, you have no ground to stand on. Even worse, criteria that are too loose (e.g., "testing done when the team is tired") create confusion about when to actually stop. The worst failure is setting criteria, meeting them, then shipping anyway and having production fail—that loses trust in the entire process.
7 Now You Try — Write the Criteria
Scenario: A Wellington council is launching a new online dog registration portal. Owners must renew annually, pay by credit card or direct debit, and receive a digital tag. The go-live date is 1 July, the start of the new financial year. Penalties for late registration begin on 1 August.
Task: Write three entry criteria and three exit criteria for system testing of this portal. Make each specific, measurable, and relevant to the NZ context. Then click reveal to see a model answer.
Model answer:
| Type | Criterion | Justification |
|---|---|---|
| Entry | Payment gateway integration certified in sandbox environment by the NZ bank | Without verified payment flow, system testing cannot validate the core transaction path |
| Entry | Dog ownership test data covers all NZ council zones and microchip formats | Ensures postcode and microchip validation rules are testable across the full dataset |
| Entry | Accessibility audit passed WCAG 2.1 AA for screen-reader compatibility | Council websites must be accessible to all residents under NZ standards |
| Exit | 100% of payment flows (Visa, Mastercard, direct debit) pass end-to-end | Payment failure = revenue loss and resident complaints to elected councillors |
| Exit | Zero P1/P2 defects; P3 defects have documented workarounds accepted by council | Protects the council from service-desk overload at go-live |
| Exit | Load test confirms 500 concurrent users with p95 response under 3 seconds | Registration spikes in late July; the portal must not collapse under demand |
How did you do? If your criteria were specific, had measurable thresholds, and addressed NZ-specific concerns (payment methods, council zones, accessibility), you are thinking like a Test Lead who protects both the team and the public.
8 Self-Check — Can You Actually Do This?
Click each question to reveal the answer. If you got all three, you are ready to define criteria on a real project.
Q1. What is the difference between entry criteria and exit criteria?
Entry criteria are pre-conditions: what must be true before testing can begin (e.g., build deployed, smoke tests green, test data ready). Exit criteria are completion conditions: what must be true for testing to stop and the product to be considered releasable (e.g., coverage targets met, defect thresholds passed, stakeholder sign-off received). One gates the start; the other gates the finish.
Q2. Why should exit criteria be agreed before testing starts, not during the final week?
Because exit criteria defined under release pressure become negotiation points, not quality gates. When the deadline is tomorrow and everyone is exhausted, “all tests pass” becomes “well, most tests pass.” Pre-defined, agreed criteria remove emotion from the release decision and give the Test Lead objective grounds to delay if quality is insufficient. It shifts the conversation from “are you being difficult?” to “did we meet the criteria we all agreed on?”
Q3. Give one example of an entry criterion that is realistic and one that is unrealistic for a typical web application.
Realistic: “Smoke tests pass in the staging environment on the current build.” This is achievable, measurable, and directly relevant to test readiness. Unrealistic: “Zero known defects exist in the codebase before system testing begins.” This is unattainable in any non-trivial system and would delay testing indefinitely while developers chase minor issues that system testing itself is designed to find.
9 Interview Prep — Lead-Level Q&A
Interviewers want to know if you can set boundaries, enforce them under pressure, and navigate release politics.
Q1. Tell me about a time you had to hold the line on exit criteria despite pressure to release early.
I had defined exit criteria with the product owner: zero P1 defects, 90% test execution. Two days before the release, a P1 was found, and the deadline was immovable—the client had announced the launch date publicly. I called a meeting with the product owner, dev lead, and client. I showed the criteria we had all agreed on, explained the risk of shipping with the defect, and offered two options: delay 48 hours for the fix, or go live with a documented mitigation plan. The client chose to delay. Holding the line protected the product and the team's credibility.
Q2. How do you handle disagreement about whether exit criteria have been met?
Make the criteria objective. If a criterion says "all tests pass," and two tests fail, it is unmet—no debate. If the criterion says "90% pass," and we have 88%, we are failing. When disagreement happens, it usually means the criterion was vague to begin with. I would ask: "What does 'pass' mean? How do we measure it?" then write it down for next time. Transparency prevents politics.
Q3. What do you do if exit criteria become unrealistic during the project?
I treat it like a scope change. If the original criteria said "100% regression pass" but the scope doubled, the criteria probably need adjustment. I do not quietly lower the bar; I propose a change, document who agrees, and get written sign-off from stakeholders. This way, when the release happens, everyone understands what we committed to and what we actually delivered on.