Development Ticket Template
Every ticket that involves implementation work uses this template. The Quality Gates and Definition of Done sections are mandatory and must be filled in before work starts, not after.
Copy the raw Markdown below into your issue tracker and fill in the placeholders.
Title: [Short description of the feature or fix]
Type: Feature / Bug / Refactor
What needs to be built or changed, and why.
What must be true for this ticket to be complete from a product perspective. Written before implementation begins.
- e.g. The valve opens within 100 ms of pressure falling below the lower threshold
- e.g. A fault event is raised when pressure exceeds the configured safety limit
- e.g. The system recovers to normal operation after a fault is reset
Mandatory. Agreed between developer and reviewer before implementation starts.
| Gate | Requirement |
|---|---|
| Unit tests | Which classes require unit tests? List them explicitly. |
| Branch coverage | 100% branch coverage for all business logic classes in this ticket |
| Integration tests | Which hardware interactions require integration tests? List them, or write "none". |
| CI | All unit and component tests must pass on the pull request |
| Code review | Tests reviewed alongside production code, not separately |
- Implementation complete and compiling cleanly
- Unit tests written and passing for all business logic introduced or changed in this ticket
- Integration tests written and tagged
HwIntegrationwhere hardware is involved - CI green on the pull request (unit and component tests, no hardware required)
- Coverage goal met for all business logic classes in this ticket
- Code review approved: production code and tests reviewed together
- Test plan updated if this ticket changes the scope of a component covered by an existing plan
- No skipped tests without a comment stating the reason
Optional. Specific scenarios, boundary values, or edge cases the reviewer should look for in the tests.
- e.g. Boundary: test exactly at threshold, not just above and below
- e.g. Edge case: zero input value should not cause division by zero
- e.g. Sequence: fault must be triggered before reset is tested
| Field | Purpose | Who fills it in |
|---|---|---|
| Acceptance Criteria | Product-level requirements; defines what the feature must do | Developer with input from product owner |
| Quality Gates: Unit tests | Names the specific classes that need tests; prevents vague commitments | Developer before starting |
| Quality Gates: Branch coverage | Sets the coverage expectation explicitly per ticket | Developer before starting |
| Quality Gates: Integration tests | Identifies hardware paths that cannot be faked | Developer before starting |
| Definition of Done | Checklist enforced at code review | Developer; reviewed by reviewer |
| Test Notes | Guides the reviewer to scenarios worth scrutinising | Developer |
Placing quality gates in the ticket rather than a separate process document serves two purposes.
First, it makes the testing obligation visible at the point where work is planned. When a developer picks up a ticket, they see immediately which classes need tests and what the coverage expectation is. There is no ambiguity about whether tests are required.
Second, it gives the code reviewer a concrete checklist. A reviewer who sees a business logic class without tests, or a coverage result below the stated goal, has a clear basis to request changes before approving the pull request.
See also: Testing Processes, Test Plan Template, Test Architecture Patterns
