QA Release Workflows

This guide covers how to manage QA testing across different release types - feature releases, version releases, and hotfixes - using a Git branch-per-cycle approach. Each QA cycle lives on its own branch, keeping artifacts clean and isolated across releases.

The Core Pattern

Every QA cycle maps to a Git branch. You start fresh on a new branch, run the STLC, and archive the branch when the cycle closes. The baseline branch (qa/main) holds the most recently approved test suite and acts as the starting point for every new cycle.

qa/main                  ← baseline: last known-good test suite
  │
  ├─ qa/release-v1.2.0   ← full STLC for a version release
  ├─ qa/feature-login     ← scoped cycle for a new feature
  └─ qa/hotfix-payment    ← targeted re-run for a critical fix

Branch naming convention:

Type	Branch name
Version release	qa/release-v<semver>
Feature	qa/feature-<short-name>
Hotfix	qa/hotfix-<short-name>
Regression run	qa/regression-<date>

---

Scenario A - New Feature Release

A new feature has been built and needs full QA coverage from scratch across the affected domains.

Example: A new "Team Invitations" feature touching UI, API, and email flows.

# 1. Branch from qa/main
git checkout qa/main
git checkout -b qa/feature-team-invitations

# 2. Start the STLC
/qa-init

Scope decision at /qa-plan: You only need to cover the domains the feature touches. If the feature is backend-only, skip UI and A11y.

Domains in scope: API, UI, A11y
Out of scope: Performance (no load-sensitive paths changed)

Full cycle runs:

/qa-requirement  → capture feature acceptance criteria
/qa-plan         → derive test strategy (API + UI + A11y only)
/qa-api          → build API test plan for new invitation endpoints
/qa-ui           → script the invitation flow (send → accept → dashboard)
/qa-a11y         → add WCAG checks to invitation pages
/qa-exec         → execute all three domains
/qa-triage       → categorise any failures
/qa-coverage     → release readiness check
/qa-report       → final summary

When complete: Merge qa/feature-team-invitations back to qa/main. The updated ui-test.yaml and api-test-plan.md on qa/main now include the new feature coverage.

---

Scenario B - Version Release

A full release (e.g. v2.0.0) involving multiple features, dependency upgrades, and cross-domain changes. Needs end-to-end coverage.

Example: v2.0.0 with a redesigned checkout flow, new payment API, and updated accessibility requirements.

git checkout qa/main
git checkout -b qa/release-v2.0.0

All domains in scope. Run the full STLC:

/qa-requirement  → gather all requirements for this release
/qa-plan         → full coverage: API + UI + A11y + Perf
/qa-api          → test all changed endpoints
/qa-ui           → script the complete checkout flow
/qa-a11y         → WCAG AA audit on all changed pages
/qa-perf         → load test the new payment endpoints
/qa-exec         → full execution
/qa-triage       → triage any failures
/qa-coverage     → release readiness gate
/qa-report       → stakeholder summary

Tip: For a major release, run /qa-coverage twice - once after Design to check no gaps were missed in planning, and again before shipping to confirm all failures are resolved.

When complete: Merge qa/release-v2.0.0 to qa/main and tag it:

git checkout qa/main
git merge qa/release-v2.0.0
git tag qa-v2.0.0

---

Scenario C - Hotfix

A critical bug in production needs a targeted fix and a fast, scoped re-test. No need to re-design tests - reuse what already exists on qa/main and only re-run the affected domain.

Example: A payment API returning 500 on certain card types. Fix is deployed to staging, needs re-validation.

# Branch from qa/main - the existing artifacts are already there
git checkout qa/main
git checkout -b qa/hotfix-payment-500

No planning or design phase needed. The api-test-plan.md on qa/main already covers the payment endpoints.

/qa-impact   → record what changed (payment endpoint fix)
              → flags API domain for re-run
/qa-exec     → execute API tests only
/qa-triage   → confirm fix resolves the failure
/qa-report   → targeted hotfix summary

Why skip /qa-plan and /qa-api? The existing test plan already has coverage for this endpoint. You're validating a fix, not designing new tests. /qa-impact documents the change scope without triggering a full redesign.

When complete: Merge back to qa/main. The triage and report artifacts on qa/main now reflect the hotfix validation.

---

Scenario D - Regression Run (No Redesign)

Periodic regression check: the application hasn't changed significantly, but you want to verify nothing has broken since the last cycle.

git checkout qa/main
git checkout -b qa/regression-2026-05

All artifacts (ui-test.yaml, api-test-plan.md, load-tests/dq-nbomber.yaml) are already present from qa/main.

/qa-exec   → run all domains against existing artifacts
/qa-report → append new dated entry to qa-summary.md

No planning, no design, no triage (unless failures appear). The fastest cycle - typically runs in the time it takes to execute the tests.

---

The Baseline (qa/main)

qa/main is the always-valid test suite - the QA equivalent of your production branch.

Rules for qa/main:

• Never commit directly to qa/main
• Only merge a QA cycle branch after all P0/P1 issues are resolved and /qa-report shows GO or GO WITH RISK (accepted)
• The artifacts on qa/main always reflect the last approved release

What lives on qa/main:

ui-test.yaml          ← full UI + A11y interaction script
api-test-plan.md      ← full API test plan
load-tests/
  dq-nbomber.yaml     ← load test configuration
qa-plan.md            ← current cycle scope (versioned sections)
dq-qa.config.json     ← project configuration
requirements/         ← requirements docs (versioned sections)

---

Selective Domain Re-runs

Not every change touches every domain. Use /qa-impact to record what changed and it will flag which domains need re-running.

Change type	Domains to re-run
Backend API change	API, Perf (if load-sensitive)
Frontend UI change	UI, A11y
New page or component	UI, A11y
Infrastructure / config	Perf
Copy / content change	A11y (contrast, headings)
Full release	All
Hotfix (single endpoint)	API only

/qa-impact              → flags affected domains
/qa-exec                → runs only flagged domains (confirm scope when prompted)

---

Quick Reference

Situation	Branch from	Skills to run	Merge back?
New feature	qa/main	Full STLC, scoped domains	Yes, after GO
Version release	qa/main	Full STLC, all domains	Yes, tag it
Hotfix	qa/main	/qa-impact → /qa-exec → /qa-report	Yes, after GO
Regression	qa/main	/qa-exec → /qa-report	Yes
Exploration / spike	qa/main	Any	No - discard