Giving a Review as the Quality Person
One day a developer adds you as reviewer on their PR. What you're there for is not what the other reviewers are there for.
Your lens: risk and testability
- What breaks if this ships wrong — and is that path tested?
- Does the change move something tests depend on — selectors, timing, data shapes?
- New user-visible states with no coverage?
- The error path — what does the user see when this fails?
Not your business
Style the linter should catch. Architecture the team already chose. Rewriting their approach into the one you'd have used. A review that relitigates settled decisions gets you removed from the reviewers list — politely, and permanently.
Phrasing that works
Questions beat verdicts. "What happens if the API times out here?" opens a conversation; "this is wrong" opens a fight. You can raise every risk you see without a single declarative sentence.
Grounded in how code review runs on real teams