Acceptance tests from tickets (Autonomous Requirements)

Acceptance tests from tickets is an L3 workflow where AI agents read requirements tickets (Jira, Linear, GitHub Issues) and automatically generate acceptance tests that encode the intended behavior. These tests fail until the feature is correctly implemented - by design. They are derived from requirements, not from observation of the implementation, which structurally eliminates the circular testing problem that plagues L1-L2 AI test generation.

The workflow looks like this: a product manager or engineer writes a ticket describing the desired behavior ("When a platinum customer applies a discount code, the 20% loyalty tier discount should stack with promotional discounts up to a maximum of 35%"). The AI agent reads the ticket, identifies the testable assertions (loyalty discount is 20%, stacking is permitted, maximum is 35%), and generates acceptance tests that will fail until the implementation satisfies them. The developer's job is to implement the feature against the tests - not to write the tests themselves.

This is the "Autonomous Requirements" capability in the maturity model: requirements are no longer just documentation. They're machine-executable specifications. The acceptance tests generated from the ticket become a formal contract between the product description and the code. When the tests pass, the feature matches the specification. When the feature changes, the tests must be updated - which requires updating the specification.

At Level 3 (Systematic), this workflow is integrated into the ticket lifecycle. Every ticket that describes user-observable behavior triggers automatic acceptance test generation as part of the specification process, before any implementation work begins. The tests are attached to the ticket and included in the PR that closes it.

Acceptance tests from tickets is one of the highest-leverage practices in the maturity model:

• Eliminates circular testing at scale - Tests written from requirements cannot be circular because they don't observe the implementation. The expected values come from the ticket, not the code.
• Makes requirements testable - Vague requirements cannot produce specific acceptance tests. The process of generating tests from tickets surfaces ambiguity in requirements before any code is written.
• Shifts the quality gate earlier - A failing acceptance test at the start of development is infinitely cheaper than a bug report after deployment. Requirements-derived tests move quality left.
• Enables confident AI-generated implementation - When acceptance tests are written from requirements before an AI agent starts implementing, the agent has a clear, objective success criterion. It can iterate until tests pass without requiring human interpretation of "is this correct?"
• Creates a living requirements document - The acceptance test suite is always synchronized with the requirements, because tests are generated from tickets and must be updated when requirements change.

1. Standardize ticket acceptance criteria format - The AI needs structured input to generate structured tests. Define a standard acceptance criteria format for your tickets: "Given [precondition], When [action], Then [expected outcome]." This is the classic Gherkin format, and most AI agents handle it well.
2. Configure the acceptance test generation agent - Set up an AI agent (Claude, GPT-4, or a custom pipeline) that reads ticket acceptance criteria and generates test scaffolding in your test framework. Start with a prompt that includes your test conventions and a few examples.
3. Integrate into the ticket workflow - Configure your project management tool to trigger the acceptance test generation when a ticket moves to "In Development" status. The generated tests should be committed to a branch or attached to the ticket for the implementing developer to find.
4. Validate generated tests before implementation - The implementing developer should review the generated acceptance tests before writing code. If the tests don't capture the intent, fix them before starting - not after. This is the final human checkpoint on requirements quality.
5. Require tests to fail before implementation starts - Confirm that generated acceptance tests fail on the current codebase before the developer begins implementing. A test that passes before implementation is either testing existing behavior (incorrect) or testing something trivial (insufficient).
6. Track acceptance test coverage by feature - Measure the percentage of feature tickets that have corresponding acceptance tests. At L3, this should be 90%+ for feature and bug tickets.

AI generating tests from vague tickets. "Improve the checkout experience" generates no useful acceptance tests. The process of trying to generate tests from vague requirements makes the vagueness visible - which is valuable - but teams need to respond by improving the requirement, not by asking the AI to interpret what "improve" means.

Accepting the first generation without review. AI-generated acceptance tests require human validation before implementation. The agent may misinterpret the acceptance criteria, generate tests at the wrong abstraction level, or miss edge cases the ticket author intended but didn't write explicitly. The review is essential and should be brief - 10 minutes - not skipped.

Letting the implementation inform the acceptance tests. If a developer reads the ticket, starts implementing, and then reviews the AI-generated acceptance tests, they'll naturally interpret ambiguous test cases in ways that match what they've already built. The acceptance tests should be finalized before implementation begins, not during or after.

Over-generating tests from every sentence. Acceptance criteria often includes context, examples, and background information that shouldn't generate tests. The agent needs guidance on which parts of a ticket are testable specifications vs. context. Tuning the prompt - and the ticket format - prevents an overwhelming volume of trivially-true tests.