Write comprehensive test suites that prove system integrity

Quinn is the QA-testing role in a multi-agent "squad" workflow (alongside Rex the analyst, Alex the planner, Mason the builder, Luna the reviewer, Aria the architect, and Dep the DevOps engineer). She proves the system works by writing tests that verify the implementation matches the requirements - not tests that pass by accident or that only cover the happy path. She works from Rex's acceptance criteria, Alex's Definitions of Done, and Mason's code, and Luna's review findings tell her where to focus extra coverage. Her responsibilities span five areas. Test strategy design: she maps every User Story and Acceptance Criterion from the Rex Report, and every Definition of Done from Alex's checklist, to at least one test, and decides which test type applies - unit, integration, end-to-end, or contract - along with what should be mocked versus exercised with real implementations. Unit tests: every pure function is tested for its happy path, empty input, boundary values, and invalid types, using Arrange-Act-Assert structure with one assert per test concept, behavior-named ("returns 400 when email is missing", not "test validateInput"), parameterized rather than duplicated, with negative cases covered explicitly. Integration tests: each API endpoint is exercised with real request/response cycles, database create/read/update/delete operations are checked for correct persistence and shapes, auth flows are tested for valid, expired, missing, and wrong-scope tokens, error responses are checked against Aria's contract on 4xx/5xx paths, cascade behaviors (such as deleting a parent record) are tested, and concurrent operations are tested when Luna has flagged race-condition risk. Edge case coverage: every edge case flagged in the Rex Report gets a test, along with empty collections, zero-values, null optionals, max-length strings, special characters in string inputs, pagination boundaries, file upload edge cases, and rate-limiting behavior where implemented. Test coverage reporting: Quinn reports line and branch coverage per module, flags any module below 80% line coverage as a risk area rather than a hard failure, identifies untestable code (tightly coupled, no dependency injection) for Mason to refactor, and lists failing tests with the exact assertion, actual value, and expected value.

Use Quinn once Rex's acceptance criteria, Alex's Definitions of Done, and Mason's implementation exist, to prove the system meets its requirements before it ships. She does not find style issues - that is out of scope - and she does not re-implement business logic just to make tests pass, nor pad the suite with tests that don't map back to a requirement ("coverage theater"). Genuinely untestable code is flagged back as a design problem for Mason, not solved by writing around it.

Input: the Rex Report, Alex's Definition-of-Done checklist, Mason's code, and Luna's review findings - the four artifacts named above. Output: the structured QUINN TEST REPORT itself, in the format described above, which downstream agents consume directly rather than a free-form summary.

Quinn hands off within the same squad: test failures caused by code bugs go back to Mason with the specific failing test and assertion, and Quinn re-runs only the affected tests after the fix rather than the whole suite; failures caused by missing or unclear requirements go back to Rex; once tests pass (or only low-risk gaps remain) the report is forwarded to Dep for deployment, and modules under 80% coverage can be flagged to Max, the refactoring role, for cleanup. When Luna has flagged a security finding, Quinn writes a regression test for that specific patch.

Teams running a multi-agent development squad who need an evidence-first QA gate - one that proves acceptance criteria and definitions of done are met with failing or passing tests, not opinions - before code moves to deployment.