How do I set up a manual QA workflow tool for tracking test execution and release readiness across squads?

Here’s a practical way to set up a manual QA workflow tool for tracking test execution and release readiness across multiple squads.

1) Define the core workflow

Keep the workflow simple and consistent across squads:

Backlog → Ready for QA → In Test → Blocked → Passed → Failed → Ready for Release → Released

You can also add:

• Needs Re-test
• Deferred
• Won’t Test
• Hotfix Required

Each test item should have one clear status, plus ownership.

---

2) Standardize the test structure

Make sure every test effort maps to the same hierarchy:

• Release
  • Squad / Team
    • Feature / Epic
      • Test cases / test sessions
        • Execution results

Useful fields:

• Release version
• Squad
• Feature
• Tester
• Environment
• Build number
• Test cycle
• Execution status
• Defect links
• Notes / evidence
• Risk / severity
• Sign-off status

---

3) Choose the right tool format

Depending on your stack and scale:

Simple setup

Use:

• Jira + Confluence
• Notion
• Airtable
• Smartsheet
• Google Sheets for lightweight teams

Better for scaling

Use a QA workflow tool or configure:

• Jira test management add-ons like Xray or Zephyr
• Airtable as a QA operations hub
• Custom dashboard in Power BI / Looker / Tableau
• Automation through Jira + API + dashboarding

For cross-squad visibility, a tool with:

• filtering
• roll-up views
• custom fields
• dashboarding
• permissions is ideal.

---

4) Create the main views

Build views for different audiences:

Squad QA view

Shows:

• test cases assigned to the squad
• current execution status
• blockers
• failed tests
• defect links

Release manager view

Shows:

• total tests planned vs executed
• pass/fail rate
• open defects by severity
• blocked items
• readiness by squad
• release sign-off status

Leadership view

Shows:

• overall release readiness
• squad completion %
• high-risk areas
• trend over time
• go/no-go recommendation

---

5) Define release readiness criteria

Set clear rules for when a release can move forward.

Example release readiness checklist:

• 100% of planned tests executed, or documented exceptions approved
• No open critical defects
• No unresolved blockers
• All high-priority failed tests have a mitigation or re-test plan
• Required sign-offs completed by QA, product, and engineering
• Test evidence attached for critical flows

Make this explicit in the tool with a release readiness status:

• Not Ready
• At Risk
• Ready with Exceptions
• Ready to Release

---

6) Track execution in a consistent way

For each test cycle, capture:

• test case ID
• tester
• date/time
• environment
• expected vs actual result
• pass/fail/blocked
• defect ID
• retest outcome
• evidence attachment

Best practice:

• one row or record per test execution
• do not overwrite old results
• preserve history for auditability

---

7) Make blockers visible

A manual QA workflow succeeds when blockers are obvious.

Track:

• blocker type: environment, data, dependency, bug, access, unclear requirements
• owner
• age of blocker
• ETA to resolution
• impacted tests/releases

Use a separate blockers register or highlight blocked items in red.

---

8) Build rollout governance

Establish routines:

• Daily squad QA standup: progress, blockers, re-tests
• Release readiness review: compare squads, approve exceptions
• Go/No-Go meeting: final decision based on the dashboard

Assign roles:

• QA owner per squad
• release manager
• engineering lead
• product owner
• approver/sign-off owner

---

9) Add automation where it helps

Even with manual QA, automate the boring parts:

• sync defect status from Jira
• auto-calculate coverage and readiness
• notify owners when blockers age > X days
• send reminders for incomplete executions
• generate release readiness reports automatically

---

10) Use a dashboard with a few key metrics

The most useful metrics are:

• Planned vs executed tests
• Pass rate
• Fail rate
• Blocked count
• Open critical/high defects
• Re-test pending count
• Readiness by squad
• Days to release
• Test cycle completion %

Avoid too many metrics at first. Start with the ones that answer:
“Are we ready to ship, and what’s stopping us?”

---

11) Governance and data hygiene

Set rules so the tool stays reliable:

• one owner per record
• mandatory fields for status changes
• consistent naming for releases and squads
• no duplicate test cases
• weekly cleanup of stale items
• archive old cycles/releases

---

12) Suggested minimal setup

If you want something lightweight, set up:

Tables / sheets

1. Releases
2. Squads
3. Test Cycles
4. Test Cases
5. Executions
6. Defects
7. Blockers
8. Readiness Summary

Key links

• Release ↔ Test Cycles
• Test Cycle ↔ Test Cases
• Test Case ↔ Executions
• Execution ↔ Defect
• Release ↔ Readiness Summary

---

13) Example workflow

1. Release is created.
2. Each squad gets its assigned test cycle.
3. QA executes test cases and updates status.
4. Failures create defects.
5. Blockers are logged and tracked.
6. Retest happens after fixes.
7. Readiness dashboard updates automatically.
8. Release manager reviews squad status.
9. Sign-off is recorded.
10. Release is marked ready/released.

---

14) Recommended tool design principle

Design around these 3 questions:

1. What has been tested?
2. What is blocked or failed?
3. Can we safely release?

If your tool answers those clearly, it will work well.

If you want, I can also help you with:

• a sample Airtable/Jira schema
• a dashboard layout
• a RACI for squad QA ownership
• or a template for release readiness criteria