Our engineers are our QA team. Every engineer owns the quality of the team's work, and our culture backs them up, so we haven't needed a separate QA group.
Every engineer owns quality, for their own changes and for the whole team's work. If you see a gap anywhere, it's yours to raise and help fix.
The project lead leads by example, and makes sure the team assigned to the project is producing quality work. Peer review, product validation and design feedback all strengthen quality, but they don't move ownership away from engineers.
Match verification to the risk
Work out the risks a change introduces, then choose tests and checks in proportion to them. The higher the risk, the deeper you go. These are the areas to think through:
Behavior and regressions
Expected outcomes
Edge cases
Existing records
Empty states
Nearby workflows
Security and data access
Permissions
Tenant boundaries
Sensitive data
Credentials
Reliability and recovery
Failure paths
Retries
Background jobs
Partial completion
Disable or reverse
Performance and accessibility
Realistic data volumes
Expensive operations
Keyboard access
Readable states
Screen sizes
Interface consistency
Existing components
Wording
Interaction patterns
The whole task path
Make review evidence useful
The pull request author explains the change, its risks, what was tested and what reviewers should look at. Reviewers examine both the implementation and its test coverage. Product checks the intended behavior, and design checks the experience.
When you spot a gap, raise it and help resolve it. Quality includes helping a teammate improve a change before it reaches users, not only checking your own code.
Own the production result
Release checks should follow from the risks found during development. Agree on the signals that show a change is working, and on any checks needed after it's turned on.
Any engineer can pause, disable or roll back a release. The change author or project lead coordinates the follow-through. Ordinary follow-up work goes through the project or 1-Offs. A suspected serious production problem is raised as an incident right away, through our internal incident process.
