2.3Anatomy of Each DoD Item
Code Review
Code review is the first quality gate. It catches logic errors, security issues, and design problems before testing begins.
QA perspective on code review: QA engineers should participate in reviews, especially for:
- Test code (is it deterministic, isolated, well-named?)
- Application code that affects testability (are there data-testid attributes, API contracts?)
- Configuration changes (environment variables, feature flags)
Unit Test Coverage
Unit tests verify individual functions and methods in isolation. They are the fastest tests and should cover all significant logic paths.
What "coverage does not decrease" means in practice:
- New code must have unit tests
- Deleting code may decrease coverage (that is acceptable)
- Refactoring should maintain or improve coverage
- A specific threshold (e.g., 80%) is less important than the trend
Integration Tests
Integration tests verify that components work together: API endpoints, database queries, service interactions.
When a story adds or changes an API endpoint, integration tests should verify:
- Happy path: correct request returns correct response
- Error paths: invalid input returns appropriate error codes
- Edge cases: boundary values, empty collections, large payloads
Browser Tests
Browser tests verify the end-to-end user experience in a real browser. They should cover the primary user flows added or changed by the story.
Not every story needs browser tests. A backend-only change that modifies a database query does not need a new browser test (though existing browser tests should still pass).
Exploratory Testing
Exploratory testing is manual, creative testing that automated tests cannot replicate. It discovers issues that no one thought to write a test for.
Exploratory testing checklist:
- Try unexpected inputs (emojis, very long strings, special characters)
- Test with slow network conditions
- Test with different user roles and permissions
- Test the feature on mobile viewports
- Try to break the feature by using it in ways the spec does not describe
Test Evidence
"Trust but verify" applies to testing too. Link to the CI run that shows tests passing, include screenshots of manual testing, and reference the specific test files.
Evidence examples:
- CI run URL:
https://github.com/org/repo/actions/runs/12345 - Screenshot:
screenshot-checkout-mobile.png - Test file reference:
tests/checkout/payment.spec.ts
No Critical or High-Severity Defects Open
A story is not done if it has known critical or high-severity bugs. These must be fixed within the story's scope, not deferred to another sprint.
Low and medium severity bugs can be tracked as follow-up stories, but they should be documented and linked.
Accessibility
Accessibility is not a "nice to have" -- it is a legal requirement in many jurisdictions and a quality standard.
Minimum accessibility checks:
- Keyboard navigation: Can every interactive element be reached with Tab?
- Screen reader labels: Do buttons and inputs have meaningful aria-labels?
- Color contrast: Is text readable against its background?
- Focus indicators: Can you see where keyboard focus is?