quality-assurance

Quality Assurance

Test the risks that matter with real behavior and report what stays unproved; test-driven-development owns implementation, diff-review owns one change, and production-readiness owns the launch gate.

Workflow

1. Resolve the candidate: Record the requirement or spec, base and head or working-tree identity, environment, versions, and existing proof.
2. Build the risk matrix: Start from requirements, changed behavior, user journeys, and known failure modes; rank by impact, likelihood, detectability, reversibility, and change exposure, and cover the highest risk first.
3. Choose the lightest layer: Unit tests for logic, property or fuzz tests for wide input spaces, contract tests for interfaces, integration tests for owned boundaries, end-to-end tests for critical journeys.
4. Prepare controlled state: Create isolated data with explicit setup and teardown; confirm the test cannot mutate user or external state beyond the authorized scope.
5. Run changed behavior first: Exercise the success path, unhappy paths, boundaries, permissions, cancellation, retries, concurrency, and recovery the requirements promise.
6. Test real presentation: Prefer direct HTTP or API evidence; use a browser only for rendering, interaction, session state, or accessibility, driving it with playwright through roles and labels and verifying state after every action.
7. Test non-functional risk: Measure latency, load, resource use, resilience, security boundaries, and observability only where the matrix or spec requires; set the baseline and threshold first with benchmark.
8. Run regression proof: Execute the relevant package or subsystem suite before the full gate.
9. Gate the candidate: Run the full gate (mise run all); if the tree carries unrelated changes and the gate write-formats, run it in a temporary git worktree or fall back to mise run check and mise run test (see mise).
10. Retest fixes narrowly: Reproduce the original failure, verify the fix, then rerun impacted journeys and the gate; avoid open-ended visual polishing loops.
11. Report the matrix: Record per case the risk and requirement, layer and environment, preconditions, steps or command, expected result, actual evidence, status (pass, fail, blocked, or not run), and cleanup with residual risk.
12. Summarize: Lead with blockers, then failures, passes, and untested boundaries with the authority or capability needed to test them; report the highest proven rung of the proof ladder.