Quality Assurance & Testing

Quick ref

Mission: Prove every change works, keeps working and meets the Definition of Done before anyone says "done". Rules: failing test before the fix or feature (TDD) · every bug fix ships a regression test · deterministic tests of public behavior · never weaken tests or lint to get green Skills by default: code-review · simplify (L3) · library-docs (browser-verify = the eyes at the end of a seen change; run only when the user asks) DoD: tests cover the change, edge and error paths included, review findings resolved or justified.

Entry

Guest (no Waymark block in context) → ../waymark/references/coexistence.md §3. Reads:

• Learnings: ~/.waymark/learnings/dept-qa.md if it exists.
• Stack profile: Commands + Testing.

Brief questions

1. What behavior is being added, changed or broken? (observed vs expected for bugs)
2. Why / for whom does it matter — which user journey or acceptance criterion does it protect?
3. Where do the tests live — which pyramid level (unit, integration, e2e) and which files?
4. How is it reproduced or exercised — exact steps, inputs, data, viewport?
5. Which gate commands apply (from project memory) and are any already red before the change?
6. Is UI affected? Prove it with specs and the build, then the eyes (browser-verify): a measurement or a real click on the local dev server after the last change.
7. What does done look like — which tests must pass and what must be observed running?

Scope

• Owns: test strategy and pyramid, TDD, regression tests, running and interpreting quality gates, browser verification (the eyes automatic at a seen change; wider only when the user asks), code review of the diff, the quality score, the Definition of Done every department inherits.
• Does not own: what to build → dept-product · layer rules → dept-architecture · CI pipelines and release → dept-devops · security testing depth → dept-security · accessibility design decisions → dept-ux-ui.

Procedures

In procedures.md (same folder), one section per task; a reported bug → Quick bug triage first:

• Quick bug triage (L1)
• Test pyramid — choose the level
• New feature or behavior (TDD: red / green / refactor)
• Bug fix
• Run the quality gates yourself
• Browser verification (the eyes: automatic at a seen change; wider only when the user asks)
• Code review (L2+, before done or a PR)
• Quality score (L3 or explicit request only)

Rules

• See a new test fail before making it pass.
• Prefer: keep tests deterministic: control clock, randomness, network and shared state.
• Prefer: test public behavior, not private implementation details.
• Never weaken, skip or delete tests or lint rules to get green.
• Never mock the unit under test or mock so much the test proves nothing.
• Never run the quality score on L0/L1 work unless asked.

Tools

Definition of Done

• Bug fixes have a regression test that failed first
• Edge cases and error paths covered
• code-review findings resolved or justified (L2+)
• Quality score with fixes for areas < 8 (L3 or on request)

Hand-offs

• To dept-product: acceptance criteria missing or ambiguous.
• To dept-architecture: a bug or score reveals a structural or boundary problem.
• To dept-ux-ui: ui-audit finds accessibility or hierarchy issues.
• To dept-security: a finding touches auth, input validation, secrets or dependencies.
• To dept-data: failures caused by state, caching or persistence design.
• To dept-devops: gates pass locally but fail in CI, or build/environment issues.
• To dept-devex: a gate command, skill or registry entry misbehaves.

Learned rules

Grows with use (../waymark/references/learning.md).