QA & Development Coordination | Shift-Left Testing
Bridge QA and development teams with shared boards, acceptance criteria integration, and feedback workflows. GitScrum catches issues early and reduces rework cycles.
16 min read
Quality assurance works best when integrated throughout development rather than treated as a final gate before release. GitScrum enables close QA-dev collaboration through shared task views, structured acceptance criteria, testing workflows, and feedback mechanisms that catch issues early, reduce rework, and create shared ownership of quality across the entire team.
QA Integration Models
Embedded vs Separate QA
QA TEAM STRUCTURES:
┌─────────────────────────────────────────────────────────────┐
│ HOW QA INTEGRATES WITH DEVELOPMENT │
├─────────────────────────────────────────────────────────────┤
│ │
│ EMBEDDED QA (Recommended for Agile): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ DEV TEAM SCRUM ││
│ │ ┌─────────────────────────────────────────────────────┐ ││
│ │ │ @dev-maria @dev-carlos @dev-ana @qa-tom │ ││
│ │ │ │ ││
│ │ │ QA is full team member: │ ││
│ │ │ • Joins sprint planning │ ││
│ │ │ • Participates in refinement │ ││
│ │ │ • Same standup, retro │ ││
│ │ │ • Tests during sprint, not after │ ││
│ │ │ │ ││
│ │ │ Ratio: 1 QA per 3-5 developers │ ││
│ │ └─────────────────────────────────────────────────────┘ ││
│ │ ││
│ │ Pros: ││
│ │ • Faster feedback loops ││
│ │ • QA context on business requirements ││
│ │ • Bugs fixed same sprint they're found ││
│ │ • Quality becomes team responsibility ││
│ │ ││
│ │ Cons: ││
│ │ • QA may get pressured by sprint deadline ││
│ │ • Less QA-to-QA knowledge sharing ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SEPARATE QA TEAM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ DEV TEAM BOARD QA TEAM BOARD ││
│ │ ┌─────────────┐ ┌─────────────┐ ││
│ │ │ Dev tasks │ ──► │ QA queue │ ││
│ │ │ │ Pass │ │ ││
│ │ │ │ to QA │ │ ││
│ │ └─────────────┘ └─────────────┘ ││
│ │ ││
│ │ QA tests after dev completes: ││
│ │ • Handoff when "Dev Done" ││
│ │ • QA tests in separate phase ││
│ │ • Bugs go back to dev board ││
│ │ ││
│ │ Pros: ││
│ │ • QA specialization and expertise ││
│ │ • Objective testing (not influenced by dev) ││
│ │ • Better for compliance/regulated industries ││
│ │ ││
│ │ Cons: ││
│ │ • Handoff delays ││
│ │ • "Throw it over the wall" mentality ││
│ │ • Bugs found later cost more to fix ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ HYBRID MODEL: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ Embedded QA for in-sprint testing ││
│ │ + ││
│ │ QA specialists for release validation ││
│ │ ││
│ │ Best of both: Speed + thoroughness ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Workflow Design
Shared Board Structure
QA-DEV INTEGRATED BOARD:
┌─────────────────────────────────────────────────────────────┐
│ WORKFLOW COLUMNS │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┬──────────┬──────────┬──────────┬──────────────┐│
│ │ Backlog │ In Dev │ In QA │ In UAT │ Done ││
│ ├─────────┼──────────┼──────────┼──────────┼──────────────┤│
│ │ │ WIP: 3 │ WIP: 2 │ │ ││
│ │ ┌─────┐ │ ┌─────┐ │ ┌─────┐ │ ┌─────┐ │ ┌─────┐ ││
│ │ │Task1│ │ │Task3│ │ │Task5│ │ │Task7│ │ │Task9│ ││
│ │ └─────┘ │ │@maria│ │ │@tom │ │ │@client│ │ │ ✓ │ ││
│ │ ┌─────┐ │ └─────┘ │ └─────┘ │ └─────┘ │ └─────┘ ││
│ │ │Task2│ │ ┌─────┐ │ ┌─────┐ │ │ ┌─────┐ ││
│ │ └─────┘ │ │Task4│ │ │Task6│ │ │ │Task10│ ││
│ │ │ │@carlos│ │ │@tom │ │ │ │ ✓ │ ││
│ │ │ └─────┘ │ └─────┘ │ │ └─────┘ ││
│ │ │ │ │ │ ││
│ └─────────┴──────────┴──────────┴──────────┴──────────────┘│
│ │
│ WIP LIMITS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ In QA column has WIP limit = number of QA people × 2 ││
│ │ ││
│ │ Why: Prevents QA bottleneck, keeps flow moving ││
│ │ ││
│ │ When QA full: ││
│ │ • Devs can't move more to QA (blocked) ││
│ │ • Signal: Either help QA or slow down new dev ││
│ │ • Consider: Developer assists with testing ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ COLUMN DEFINITIONS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ In Dev: ││
│ │ • Developer actively coding ││
│ │ • Unit tests written ││
│ │ • Exit criteria: Code complete, self-tested ││
│ │ ││
│ │ In QA: ││
│ │ • QA actively testing ││
│ │ • Using test environment ││
│ │ • Exit criteria: All test cases pass, no open bugs ││
│ │ ││
│ │ In UAT: ││
│ │ • Stakeholder/PM reviewing ││
│ │ • Business acceptance testing ││
│ │ • Exit criteria: Approved for release ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Task Transitions
HANDOFF CLARITY:
┌─────────────────────────────────────────────────────────────┐
│ WHAT MOVES TASKS BETWEEN COLUMNS │
├─────────────────────────────────────────────────────────────┤
│ │
│ DEV → QA TRANSITION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Before moving to QA, dev must: ││
│ │ ││
│ │ ☐ Code complete and merged to dev branch ││
│ │ ☐ Unit tests passing ││
│ │ ☐ Deployed to test environment ││
│ │ ☐ Acceptance criteria reviewed ││
│ │ ☐ Test data prepared (if needed) ││
│ │ ☐ Brief QA on any technical notes ││
│ │ ││
│ │ Add checklist to task in GitScrum ││
│ │ Must be completed before column move allowed ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ QA → UAT TRANSITION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Before moving to UAT, QA must: ││
│ │ ││
│ │ ☐ All test cases executed ││
│ │ ☐ All critical/high bugs fixed and retested ││
│ │ ☐ Test summary documented ││
│ │ ☐ Environment stable for UAT ││
│ │ ☐ UAT stakeholder notified ││
│ │ ││
│ │ Remaining low-priority bugs: Documented, tracked ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ QA → BACK TO DEV (Rejection): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ When QA finds blocking issue: ││
│ │ ││
│ │ 1. Create linked bug task (type: bug) ││
│ │ 2. Move original task back to In Dev ││
│ │ 3. Assign bug to original developer ││
│ │ 4. Include in bug: ││
│ │ • Steps to reproduce ││
│ │ • Expected vs actual ││
│ │ • Screenshots/videos ││
│ │ • Test environment details ││
│ │ ││
│ │ Label: qa/rejected for tracking rejection rate ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Acceptance Criteria Integration
Writing Testable Criteria
ACCEPTANCE CRITERIA BEST PRACTICES:
┌─────────────────────────────────────────────────────────────┐
│ CRITERIA THAT QA CAN ACTUALLY TEST │
├─────────────────────────────────────────────────────────────┤
│ │
│ FORMAT: Given-When-Then │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Task: User Password Reset ││
│ │ ││
│ │ Acceptance Criteria: ││
│ │ ││
│ │ ✅ TESTABLE: ││
│ │ AC1: Given user on login page ││
│ │ When they click "Forgot Password" ││
│ │ Then email input form is shown ││
│ │ ││
│ │ AC2: Given valid email entered ││
│ │ When they submit form ││
│ │ Then reset email sent within 30 seconds ││
│ │ And success message displayed ││
│ │ ││
│ │ AC3: Given invalid email format ││
│ │ When they submit form ││
│ │ Then validation error shown ││
│ │ And no email sent ││
│ │ ││
│ │ ❌ VAGUE (Don't do this): ││
│ │ • "Password reset should work" ││
│ │ • "User-friendly error messages" ││
│ │ • "Fast email delivery" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ INCLUDE EDGE CASES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ AC4: Given email not in system ││
│ │ When they submit form ││
│ │ Then generic success message shown ││
│ │ (security: don't reveal if email exists) ││
│ │ ││
│ │ AC5: Given reset requested twice in 5 minutes ││
│ │ When they submit again ││
│ │ Then rate limit message shown ││
│ │ And no second email sent ││
│ │ ││
│ │ AC6: Given reset link clicked after 24 hours ││
│ │ When link opened ││
│ │ Then "Link expired" message shown ││
│ │ And "Request new reset" option offered ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
QA During Refinement
QA PARTICIPATION IN PLANNING:
┌─────────────────────────────────────────────────────────────┐
│ SHIFTING QUALITY LEFT │
├─────────────────────────────────────────────────────────────┤
│ │
│ QA IN BACKLOG REFINEMENT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Before sprint planning, QA reviews stories: ││
│ │ ││
│ │ QA asks: ││
│ │ • Are acceptance criteria testable? ││
│ │ • What edge cases are missing? ││
│ │ • What test data is needed? ││
│ │ • Are there integration points to test? ││
│ │ • What could break in existing features? ││
│ │ ││
│ │ QA adds: ││
│ │ • Additional acceptance criteria for edge cases ││
│ │ • Notes about test environment needs ││
│ │ • Estimate of QA effort ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ QA IN SPRINT PLANNING: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ QA contributes to: ││
│ │ ││
│ │ • Story pointing (testing effort included) ││
│ │ • Sprint capacity (QA availability matters) ││
│ │ • Task breakdown (testing tasks visible) ││
│ │ ││
│ │ Create explicit QA subtasks: ││
│ │ ☐ Write test cases ││
│ │ ☐ Prepare test data ││
│ │ ☐ Execute test cases ││
│ │ ☐ Regression testing ││
│ │ ││
│ │ This makes QA work visible in sprint ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ THREE AMIGOS SESSION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Before coding starts, 15-min meeting: ││
│ │ ││
│ │ Participants: ││
│ │ 1. Developer - how to build it ││
│ │ 2. QA - how to test it ││
│ │ 3. PO/Business - what we need ││
│ │ ││
│ │ Outcome: ││
│ │ • Shared understanding of requirements ││
│ │ • Edge cases identified early ││
│ │ • Acceptance criteria refined ││
│ │ • Everyone aligned before work starts ││
│ │ ││
│ │ Track in GitScrum: Discussion thread per feature ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Bug Management
Bug Workflow
BUG HANDLING PROCESS:
┌─────────────────────────────────────────────────────────────┐
│ FROM DISCOVERY TO CLOSURE │
├─────────────────────────────────────────────────────────────┤
│ │
│ BUG TASK TEMPLATE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Title: [Component] Brief description ││
│ │ ││
│ │ **Environment:** ││
│ │ Browser: Chrome 120 ││
│ │ OS: Windows 11 ││
│ │ Test environment: staging.app.com ││
│ │ ││
│ │ **Steps to Reproduce:** ││
│ │ 1. Navigate to /dashboard ││
│ │ 2. Click "Export" button ││
│ │ 3. Select "CSV" format ││
│ │ 4. Click "Download" ││
│ │ ││
│ │ **Expected Result:** ││
│ │ CSV file downloads with data ││
│ │ ││
│ │ **Actual Result:** ││
│ │ Error message: "Export failed" ││
│ │ ││
│ │ **Attachments:** ││
│ │ [Screenshot of error] ││
│ │ [Console log errors] ││
│ │ ││
│ │ **Labels:** type/bug, severity/high, component/export ││
│ │ **Linked to:** Task #123 (Export feature) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ BUG WORKFLOW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ QA Finds Bug ││
│ │ │ ││
│ │ ▼ ││
│ │ ┌─────────┐ ││
│ │ │ New Bug │ (Created in GitScrum) ││
│ │ └────┬────┘ ││
│ │ │ ││
│ │ ▼ ││
│ │ ┌─────────┐ ││
│ │ │ Triaged │ (Severity/priority set, assigned) ││
│ │ └────┬────┘ ││
│ │ │ ││
│ │ ▼ ││
│ │ ┌─────────┐ ││
│ │ │ In Fix │ (Developer working on fix) ││
│ │ └────┬────┘ ││
│ │ │ ││
│ │ ▼ ││
│ │ ┌─────────┐ ││
│ │ │ Verify │ (QA retests the fix) ││
│ │ └────┬────┘ ││
│ │ │ ││
│ │ ┌───┴───┐ ││
│ │ │ │ ││
│ │ Pass Fail ││
│ │ │ │ ││
│ │ ▼ ▼ ││
│ │ Done Reopen ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Bug Metrics
TRACKING QA EFFECTIVENESS:
┌─────────────────────────────────────────────────────────────┐
│ METRICS THAT MATTER │
├─────────────────────────────────────────────────────────────┤
│ │
│ QUALITY METRICS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Defect Escape Rate: ││
│ │ Bugs found in production vs found in QA ││
│ │ ││
│ │ Target: < 10% escape to production ││
│ │ ││
│ │ Calculate: ││
│ │ Label bugs: found/qa or found/production ││
│ │ Filter and count in GitScrum ││
│ │ ││
│ │ Month │ Found in QA │ Escaped │ Escape Rate ││
│ │ ─────────┼─────────────┼─────────┼──────────── ││
│ │ January │ 45 │ 8 │ 15% ⚠️ ││
│ │ February │ 52 │ 4 │ 7% ✓ ││
│ │ March │ 38 │ 3 │ 7% ✓ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PROCESS METRICS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Rejection Rate: ││
│ │ Tasks sent back from QA to Dev ││
│ │ ││
│ │ High rate means: ││
│ │ • Devs not self-testing ││
│ │ • Unclear requirements ││
│ │ • Acceptance criteria gaps ││
│ │ ││
│ │ Track: Label qa/rejected, analyze trends ││
│ │ ││
│ │ Average Time in QA: ││
│ │ How long tasks stay in QA column ││
│ │ ││
│ │ Long time means: ││
│ │ • QA bottleneck (need more QA) ││
│ │ • Complex features (expected) ││
│ │ • Bug ping-pong (process issue) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SPRINT QUALITY DASHBOARD: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Create saved filter in GitScrum: ││
│ │ ││
│ │ Sprint 24 Quality Summary ││
│ │ ────────────────────────── ││
│ │ Stories tested: 12 ││
│ │ Bugs found: 18 ││
│ │ Critical bugs: 2 ││
│ │ Bugs fixed: 16 ││
│ │ Bugs carried over: 2 (both low priority) ││
│ │ Rejection rate: 25% (3/12 rejected first pass) ││
│ │ ││
│ │ Review in retro: Why 25% rejection rate? ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Communication Patterns
Daily Sync
QA-DEV DAILY COORDINATION:
┌─────────────────────────────────────────────────────────────┐
│ KEEPING EVERYONE ALIGNED │
├─────────────────────────────────────────────────────────────┤
│ │
│ EMBEDDED QA IN STANDUP: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ QA shares: ││
│ │ • What I tested yesterday ││
│ │ • What I'm testing today ││
│ │ • Blockers (waiting for fix, environment down, etc.) ││
│ │ ││
│ │ Plus: ││
│ │ • Bug summary (X new bugs found, Y awaiting fix) ││
│ │ • Ready for testing (pull from In QA column) ││
│ │ • Environment status (test env working?) ││
│ │ ││
│ │ Use GitScrum Team Standup for async standups ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DEV-QA PAIRING: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ For complex features, pair test: ││
│ │ ││
│ │ • Dev shows QA how it works ││
│ │ • QA asks questions, explores edges ││
│ │ • Bugs found fixed immediately ││
│ │ • Both learn from each other ││
│ │ ││
│ │ Schedule: 30 min session when moving to QA ││
│ │ Track: Time logged by both in GitScrum ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ BUG DISCUSSION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ When dev disagrees with bug: ││
│ │ ││
│ │ ❌ Don't: Close bug as "works as designed" ││
│ │ ✅ Do: Discuss with QA and PM ││
│ │ ││
│ │ Options: ││
│ │ 1. Clarify requirements → Update AC, close bug ││
│ │ 2. It's a real bug → Fix it ││
│ │ 3. It's an enhancement → Convert to story, backlog ││
│ │ 4. Won't fix → PM decision, document why ││
│ │ ││
│ │ Use Discussions in GitScrum for async debates ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Automation Integration
Connecting Manual and Automated Testing
TEST AUTOMATION COORDINATION:
┌─────────────────────────────────────────────────────────────┐
│ MANUAL + AUTOMATED TESTING │
├─────────────────────────────────────────────────────────────┤
│ │
│ WHAT TO AUTOMATE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✅ Automate: ││
│ │ • Regression tests (run every build) ││
│ │ • Smoke tests (critical path) ││
│ │ • Data-driven tests (many inputs) ││
│ │ • API tests (stable, fast) ││
│ │ ││
│ │ ❌ Keep Manual: ││
│ │ • Exploratory testing ││
│ │ • Usability testing ││
│ │ • New features (not stable yet) ││
│ │ • Visual/UI verification ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TRACKING AUTOMATION TASKS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ When story is done, create follow-up: ││
│ │ ││
│ │ Task: "Automate tests for [feature]" ││
│ │ Labels: type/automation, priority/medium ││
│ │ Linked to: Original story ││
│ │ Assigned to: QA automation engineer ││
│ │ ││
│ │ Don't block release, but track automation debt ││
│ │ ││
│ │ Automation coverage metric: ││
│ │ Stories with automated tests / Total stories ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CI INTEGRATION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ GitScrum + CI Pipeline: ││
│ │ ││
│ │ 1. Dev pushes code ││
│ │ 2. CI runs automated tests ││
│ │ 3. GitHub/GitLab integration updates task ││
│ │ 4. Build status visible on task ││
│ │ ││
│ │ If tests fail: ││
│ │ • Task stays in Dev (can't move to QA) ││
│ │ • Dev fixes before QA even looks at it ││
│ │ ││
│ │ This catches bugs before human QA starts ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘