How to Write Acceptance Criteria That Prevent Post-Launch Defects

Most post-launch defects don’t originate in code. They originate in acceptance criteria, or the absence of them. A developer who builds exactly what the criteria described has done their job correctly. If the criteria were vague, incomplete, or ambiguous, the resulting software will reflect that ambiguity faithfully.

This is not a theoretical problem. Requirements defects are consistently identified as the most expensive category to fix, because they propagate through every downstream activity: design, development, testing, and user acceptance. By the time a requirements defect surfaces in production, the cost of resolution is 30 to 100 times higher than if it had been caught before development began.

Writing good acceptance criteria is where that cost is controlled. Here’s what good criteria actually look like, who should write them, and the anti-patterns that consistently produce defects.

 

What Good Acceptance Criteria Look Like

The most reliable format for acceptance criteria is Given/When/Then, also called Gherkin format. It forces specificity and produces criteria that are directly translatable into test cases.

The structure is:

Given: the precondition or starting state. 

When: the action the user or system takes. 

Then: the expected outcome, with specific, measurable values.

The key principle is that the “Then” clause must be testable. If a QA specialist cannot write a test case that produces a pass or fail result from the criterion as written, the criterion is not yet complete.

 

Before and After: Vague Criteria Rewritten as Testable Criteria

The difference between vague and testable criteria is most clearly illustrated through examples. Here are four common patterns and how to fix them.

Example 1: Validation Behaviour

Vague: “The form should validate required fields before submission.”

Testable: “Given I am on the new user registration form, When I click Submit with the Email Address field empty, Then I see the inline error message ‘Email address is required’ displayed beneath the Email Address field, and the form is not submitted.”

The vague version leaves open: which fields are required, what the error message says, where it appears, and whether the form partially submits. The testable version answers all of those questions.

 

Example 2: Performance Behaviour

Vague: “The dashboard should load quickly.”

Testable: “Given I am an authenticated user with a standard licence, When I navigate to the main dashboard, Then the dashboard renders fully within 3 seconds on a standard broadband connection (50 Mbps).”

Without a specific threshold, every developer’s subjective definition of “quickly” becomes equally valid. There is no test to write against the vague version.

 

Example 3: Permission Behaviour

Vague: “Only admins can delete records.”

Testable: “Given I am logged in as a user with a Standard role, When I view any record in the Contacts module, then the Delete button is not visible. Given I am logged in as a user with an Admin role, When I view a record in the Contacts module, then the Delete button is visible and functional.”

The vague version doesn’t specify what “cannot delete” means in the UI. Is the button absent, disabled, or does it produce an error? Each interpretation requires different development and testing.

 

Example 4: Integration Behaviour

Vague: “When an order is created, it should sync to the ERP.”

Testable: “Given a new order is marked as Confirmed in the CRM, When the sync job runs (every 15 minutes), Then the order appears in the ERP within 20 minutes of confirmation, with the OrderID, CustomerID, LineItems, and TotalValue fields populated. If the sync fails, an alert is generated in the monitoring dashboard.”

Timing, field mapping, and failure handling are all absent from the vague version. Each gap is a potential defect that will only surface after the integration is built and tested, at significant cost to fix.

 

Who Should Write Acceptance Criteria

Acceptance criteria should be produced through collaboration between the Business Analyst, the QA specialist, and the product owner or business stakeholder. They should not be written by the developer who will implement the feature.

This is not because developers lack the capability. It’s because a developer writing their own acceptance criteria will unconsciously write criteria that reflect how they intend to build the feature, rather than criteria that capture what the business actually needs. This introduces a blind spot that testing against developer-authored criteria will not catch.

 

The Workflow That Produces the Best Results

The practical workflow:

The Business Analyst drafts the initial criteria based on requirements elicitation with the business stakeholder. The QA specialist reviews for testability, identifying ambiguities, missing edge cases, and untestable statements. The business stakeholder confirms the criteria reflect their intent and signs off. The developer reviews and flags any technical constraints before implementation begins.

This sequence takes more time upfront. It consistently saves more time, and cost, downstream.

 

Common Anti-Patterns That Produce Defects

Four anti-patterns appear repeatedly in the acceptance criteria of projects that experience high post-launch defect rates.

 

Criteria That Are Too Broad

“The system should handle all edge cases” is not an acceptance criterion. Neither is “The user experience should be intuitive.” These statements cannot be tested and exist only to make the user story look complete. Remove them and replace them with specific, enumerated criteria for each meaningful scenario.

 

Criteria That Assume Implementation Details

“The system will use a modal dialogue to confirm deletion” mixes a business requirement with an implementation decision. The acceptance criterion should specify the behaviour, such as “The user must confirm their intent before a record is permanently deleted,” and allow the developer to determine the appropriate UI pattern. Criteria that prescribe implementation create brittleness and constrain the developer without adding quality.

 

Criteria Written After Development Begins

Acceptance criteria written to match what was already built are not acceptance criteria. They are post-hoc documentation. They provide no quality value because the opportunity to catch requirements defects before development has passed. Criteria must be agreed before development of the story begins.

 

Criteria Without Negative Paths

Most acceptance criteria focus on the “happy path,” meaning what happens when everything works correctly. Good criteria enumerate the negative paths: what happens when validation fails, when a required service is unavailable, when the user performs an action in an unexpected sequence. Negative path scenarios represent a disproportionate share of post-launch defects.

 

How Acceptance Criteria Flow into Test Cases

The direct relationship between acceptance criteria and test cases is the most practical argument for investing in criteria quality. A well-formed Given/When/Then criterion maps to a test case with almost no additional interpretation required.

The Given clause becomes the test precondition, the state the test environment must be in before the test begins. The When clause becomes the test action, the specific steps the tester executes. The Then clause becomes the expected result, the pass/fail assertion.

When QA specialists write test cases from acceptance criteria of the quality described above, the process is efficient and the coverage is predictable. When they write test cases from vague criteria, they spend time making judgement calls about what to test, their coverage is inconsistent, and defects escape that could have been specified upfront.

 

Why This Is the One Practice to Get Right

The discipline of writing testable acceptance criteria is ultimately a risk management practice. The cost of an hour of rigorous criteria writing at the start of a sprint is trivial compared to the cost of a defect discovered in UAT or, worse, in production. If you address only one quality practice on your next implementation, make it this one.