Implementation Acceptance Criteria Fields

1. Name (required)

• What it’s for: A short, human-readable identifier for this IAC.

• What to include:

  • Keep it concise but descriptive enough to distinguish this IAC from others on the same component.
  • Include the component or behaviour context, e.g. Login — invalid credentials returns 401 or Invoice upload — file size limit enforced.
  • Avoid generic names like Test 1 or Happy path — the name should allow stakeholders to identify the IAC without reading the full specification.

• Examples:

  • "Login — valid credentials return JWT and redirect"
  • "Invoice upload — file exceeding 500 records is rejected"
  • "Session timeout — unauthenticated request returns 401"

2. Description

• What it’s for: A plain-English statement of the acceptance criteria.

• What to include:

  • Use this field when the Given/When/Then structure does not fit naturally — for example, a visual constraint, a performance envelope, or a non-deterministic outcome.
  • Can also be used to augment a Given/When/Then entry with narrative context.
  • Write from a tester’s perspective: “When X happens, the system must Y.”

• Example: "The API must respond within 200ms for 95% of requests under normal load conditions."

3. Type

• What it’s for: Classifies whether this IAC covers a normal flow or an error/edge case.
• Options:

• Guidance: Ensure each piece of behaviour has both a Happy Path IAC (what correct operation looks like) and one or more Exception IACs (what happens when things go wrong). Exception IACs are frequently overlooked and are a common source of production defects.

4. Given

• What it’s for: The pre-conditions or initial context that must be true before the action occurs.

• What to include:

  • State of the system, user session, database, or external dependencies before the action.
  • Be specific — avoid vague conditions like “Given the system is running”. Instead: “Given a user account exists with email test@example.com and the account is in active status.”

• Examples:

  • "Given the user has a valid JWT token in the Authorization header"
  • "Given an invoice file containing 501 records is prepared for upload"
  • "Given the user's session has been inactive for 31 minutes"

5. When

• What it’s for: The action or event that triggers the behaviour being specified.

• What to include:

  • The specific API call, user interaction, scheduled event, or system trigger.
  • Include the endpoint, method, or interaction point where relevant.

• Examples:

  • "When a POST request is made to /api/auth/login with valid credentials"
  • "When the user clicks the Upload button"
  • "When the session expiry job runs"

6. Then

• What it’s for: The expected outcome — what the system must do in response.

• What to include:

  • The observable result: HTTP status, response body, database state, message sent, UI state, etc.
  • Be precise — specify exact status codes, field names, values, and side effects.
  • If multiple outcomes are expected, list them (one per line or as a numbered list within the field).

• Examples:

  • "Then a 200 response is returned containing a signed JWT with a 24-hour expiry"
  • "Then a 422 response is returned with error code FILE_TOO_LARGE and no file is stored"
  • "Then the session record is deleted and subsequent requests with that token return 401"

Relationships