10 / 57 · 21 Communication & Stakeholder Management · Technical Discussions← prev⊞ allnext →☰ Read as one page
2.2Participating in Architecture Reviews
Architecture reviews are where the biggest quality decisions happen. A poorly chosen architecture can make entire categories of testing impossible or prohibitively expensive. QA engineers belong in these conversations.
What QA Brings to Architecture Reviews
Developers think about how to build it. Product thinks about what to build. QA thinks about how it can break. This perspective is uniquely valuable in architecture reviews because it surfaces risks that neither developers nor product managers are trained to see.
Questions QA Should Ask in Architecture Reviews
| Question Category | Example Questions |
|---|---|
| Testability | "How will we test this in isolation?" "Can we mock this external dependency?" |
| Observability | "How will we know if this is working correctly in production?" "What logging and monitoring is planned?" |
| Failure modes | "What happens when this service is down?" "How does the system degrade under load?" |
| Data integrity | "What happens if the message queue loses a message?" "Is this operation idempotent?" |
| State management | "How do we handle partial failures in this multi-step process?" "Can we roll back?" |
| Security boundaries | "Where are the trust boundaries?" "What happens if this input is malicious?" |
| Performance | "What are the expected latency requirements?" "How does this scale with 10x the current load?" |
How to Contribute Without Overstepping
- Ask questions, do not make demands. "Have we considered what happens when..." is more effective than "You need to add a fallback mechanism."
- Ground your input in testing experience. "In the last three projects, we struggled to test microservice interactions because there was no service virtualization layer. Should we plan for that here?"
- Offer to own the testability assessment. "I would like to take an action item to write up a testability analysis of this architecture. I will have it ready for the next review."
- Know your boundaries. Architecture decisions involve trade-offs. Your job is to surface the testing and quality implications, not to dictate the architecture.