docs(qa): add QA strategy, definition of done, and bug tracking docs

[fray-cloud]

Summary

• Adds docs/qa/qa-strategy.md — test levels, CI quality gates, E2E scenario coverage
• Adds docs/qa/definition-of-done.md — DoD checklist for all task types
• Adds docs/qa/bug-tracking.md — bug report template, severity matrix, triage process

These files were left untracked on feat/#53 after PR #71 merged (PRO-71).

Test plan

• CI lint/build passes on this branch
• docs/qa/ directory present in dev after merge

🤖 Generated with Claude Code

Summary by Sourcery

Add formal QA documentation for testing strategy, definition of done, and bug tracking processes.

Documentation:

• Introduce a QA strategy document covering test levels, standards by team, E2E coverage, and CI quality gates.
• Add a definition-of-done checklist for backend, frontend, bug fixes, and infrastructure/CI changes.
• Document the bug tracking process, including reporting template, severity matrix, triage workflow, and label conventions.

[sourcery-ai]

Reviewer's Guide

Adds a new QA documentation suite under docs/qa/ covering test strategy and levels, CI quality gates, definition of done checklists by work type, and a bug tracking & triage process, with cross-links between the documents.

Sequence diagram for bug reporting and triage process

sequenceDiagram
    actor Reporter
    participant Paperclip
    participant QALead
    participant DevTeam
    participant PM
    participant CI

    Reporter->>Paperclip: Create_issue_with_bug_label_and_severity
    Paperclip-->>QALead: Notify_new_bug
    QALead->>Paperclip: Review_and_adjust_severity

    alt Critical_or_High
        QALead->>DevTeam: Assign_bug_and_request_hotfix
        DevTeam->>CI: Push_fix_branch_and_open_PR
        CI-->>DevTeam: Run_tests_and_report_status
        DevTeam->>QALead: Request_verification
    else Medium_or_Low
        QALead->>PM: Add_bug_to_sprint_backlog
        PM->>DevTeam: Prioritize_and_assign_in_sprint
        DevTeam->>CI: Implement_fix_and_open_PR
        CI-->>DevTeam: Run_tests_and_report_status
        DevTeam->>QALead: Request_verification
    end

    QALead->>CI: Verify_fix_in_CI_results
    QALead->>Paperclip: Mark_issue_done_and_add_regression_label_if_applicable

Loading

Flow diagram for applying Definition of Done by work type

flowchart TD
    Start[Start work item] --> Identify[Identify work type]

    Identify --> AllTasks[Apply All Tasks DoD checklist\nCode review, CI pass, no new ESLint errors, TS compiles, self-tested]

    AllTasks --> Decision{Work type}

    Decision --> Backend[Backend feature\napi-server or worker-service]
    Decision --> Frontend[Frontend feature\nweb]
    Decision --> BugFix[Bug fix]
    Decision --> Infra[Infrastructure or CI change]

    Backend --> BackendChecks[Backend DoD\nUnit tests, integration tests, Swagger/OpenAPI updated, DB migration safe]
    Frontend --> FrontendChecks[Frontend DoD\nE2E updated, no console errors, i18n keys, responsive layouts]
    BugFix --> BugChecks[Bug fix DoD\nRoot cause documented, regression test added, fix verified in CI]
    Infra --> InfraChecks[Infra/CI DoD\nPipeline passes end-to-end, docs updated, rollback plan noted]

    BackendChecks --> Done[Move item to done]
    FrontendChecks --> Done
    BugChecks --> Done
    InfraChecks --> Done

Loading

File-Level Changes

Change	Details	Files
Introduce a QA strategy document describing test levels, ownership, coverage expectations, E2E scenario coverage, and CI quality gates for dev and main branches, with links to supporting QA docs.	Define unit, integration, and E2E test scopes, locations, tools, and ownership across backend, frontend, and shared packages. Specify per-team testing standards and minimum coverage expectations, especially for critical business modules and shared utilities. Document current E2E coverage table for initial sprint user journeys in the web UI. Define CI quality gates for PRs to dev and main, including required test types and manual QA sign-off. Link out to definition-of-done and bug-tracking documents for complementary process details.	docs/qa/qa-strategy.md
Add a formal Definition of Done (DoD) checklist segmented by task type to standardize acceptance criteria before work is marked done.	Define global criteria for all tasks around code review, CI status, linting, TypeScript compilation, and self-testing. Add backend feature-specific criteria for tests, API documentation updates, and DB migration expectations. Add frontend feature-specific criteria for E2E coverage, console cleanliness, i18n keys, and basic responsive checks. Define bug-fix expectations around root-cause documentation, regression tests, and CI verification. Define infra/CI-change expectations including pipeline validation, documentation, and rollback planning.	docs/qa/definition-of-done.md
Document a unified bug tracking, severity, and triage process including templates, SLAs, and labeling conventions.	Introduce a structured bug report template including environment, repro steps, expected vs actual behavior, severity, and evidence. Define a priority/severity matrix with clear definitions and SLAs for critical, high, medium, and low issues, focused on trading impact. Describe the triage workflow and responsibilities for reporters, QA lead, dev teams, and PMs, including regression test requirements. Standardize issue labels for bugs, regressions, flaky tests, unreproducible issues, and wont-fix decisions.	docs/qa/bug-tracking.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've left some high level feedback:

• The SLAs and CI gates in bug-tracking.md and qa-strategy.md are quite strict (e.g., 4-hour critical fixes, mandatory E2E on all PRs); consider explicitly scoping them by environment/team size or marking them as targets rather than hard guarantees to keep the process realistic and maintainable.
• In qa-strategy.md, several rules are tool- and path-specific (e.g., Jest vs. Vitest, exact directories, tsc --noEmit in CI); if these are likely to evolve, consider centralizing or referencing existing conventions so the doc doesn’t drift when tooling or project layout changes.
• The bug triage flow in bug-tracking.md assumes Paperclip and specific roles (QA Lead, PM); it may be clearer to define these as role types and configurable tools, or to note how this maps to the current issue tracker and team structure.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The SLAs and CI gates in `bug-tracking.md` and `qa-strategy.md` are quite strict (e.g., 4-hour critical fixes, mandatory E2E on all PRs); consider explicitly scoping them by environment/team size or marking them as targets rather than hard guarantees to keep the process realistic and maintainable.
- In `qa-strategy.md`, several rules are tool- and path-specific (e.g., Jest vs. Vitest, exact directories, `tsc --noEmit` in CI); if these are likely to evolve, consider centralizing or referencing existing conventions so the doc doesn’t drift when tooling or project layout changes.
- The bug triage flow in `bug-tracking.md` assumes Paperclip and specific roles (QA Lead, PM); it may be clearer to define these as role types and configurable tools, or to note how this maps to the current issue tracker and team structure.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}