deepiri-qa-workflow

Deepiri Qa Workflow

Use when the task involves reviewing/approving a Deepiri PR as QA, standing up a QA test environment via team_dev_environments/qa-team/, or onboarding a new QA engineer.

1. Task identification

• Plaky board: check for assigned PR tasks.
• GitHub review inbox: check https://github.com/pulls/inbox for PRs where you've been requested as a reviewer — this is often how an assignment actually surfaces, in addition to Discord/Plaky.
• Scope definition: read the PR description and diff to determine which repo(s) or submodule(s) are affected before touching a local environment. If a PR is connected to other open PRs (shared branch, dependent submodule bump), identify those first — testing one in isolation when it depends on another will produce false failures.
• Status: once assigned, update your status in the availability channel to "Busy," and keep it current in general — it's how leads know who's free to pick up new work.

2. Local environment setup

• Repository access: locate the relevant repo(s)/submodule(s) on GitHub.
• Branch checkout: in the local directory of each affected submodule, checkout the branch the PR is built from — not main, and not a stale local branch with the same name.
• Environment initialization: use the Docker scripts in your deepiri-control-plane clone; use ./setup-deepiri-dev.sh start qa-team:
  • start.sh — bring the environment up.
  • build.sh — rebuild containers when the PR changes dependencies (lockfiles, Dockerfiles, base images) — a plain start.sh will silently run against stale images otherwise.
  • stop.sh — tear the environment down once testing is complete. Don't leave stacks running between PRs; the next reviewer (or your next task) may need the ports/resources clean.

3. Verification and testing

• Health check: after start.sh, confirm every container reports healthy before testing functionality on top of it. A "healthy enough" container that's actually still initializing produces test results that look like the PR's fault when they're the environment's.
• Sorge bot pass: comment /sorge on the PR to get an automated code review flagging things worth looking into. Treat this as a first pass that informs your manual review — it does not replace the code review or testing steps below; run both.
• Code review: read the source for logic and consistency, not just "does it run."
• Frontend PRs: verify UI/UX against the design spec, not just "the page loads."
• Backend PRs: verify functional requirements and data integrity — check what the change actually persists or returns, not only that the endpoint responds.