QA and QC in Scrum: A Comprehensive Guide for PMs, Developers, and QA Engineers

Table of Contents

Introduction: Why QA and QC Are Critical in Scrum

In Scrum agile development, Quality Assurance (QA) and Quality Control (QC) are not merely technical activities but key strategies for ensuring product success, reducing risks, and improving team efficiency. This article explores these practices from three perspectives:

Project Managers and Clients: How QA/QC reduces project risks, improves ROI, and enhances customer satisfaction
Development Teams (RD): Specific practices and tools that help development teams improve quality
QA Engineers: Immediately applicable testing strategies, automation practices, and best examples

Core Differences Between QA and QC: From Concept to Practice

QA (Quality Assurance): Preventive Strategy

Definition: QA is a set of preventive processes and activities aimed at establishing quality standards during development to prevent defects from occurring.

Core Philosophy: “Prevention is better than cure”—establish correct processes and standards before problems arise.

Practical Examples:

Defining “Definition of Done” (DoD) during Sprint Planning
Establishing Code Review processes
Designing test strategies and test plans
Building automated testing frameworks

QC (Quality Control): Detective Activities

Definition: QC involves testing and inspection to identify defects in products and ensure they meet quality standards.

Core Philosophy: “Verification and Validation”—ensure products meet requirements and specifications.

Practical Examples:

Unit Testing
Integration Testing
System Testing
User Acceptance Testing (UAT)

Relationship Between QA and QC

Comparison Aspect	QA (Quality Assurance)	QC (Quality Control)
Objective	Prevent defects	Detect and fix defects
Timing	Throughout development lifecycle	Primarily after development
Responsibility	Entire team	Primarily QA engineers
Methods	Process improvement, reviews, training	Testing, inspection, verification
Deliverables	Process documents, standards, guidelines	Test reports, defect lists

Project Manager and Client Perspective: Business Value of QA/QC

1. Reducing Project Risks

Problem Scenario: Major defects discovered late in project lead to launch delays or quality issues.

QA/QC Solutions:

Early risk identification: Through QA reviews during Sprint Planning, potential risks identified at requirements stage
Continuous verification: Each Sprint’s incremental delivery undergoes complete testing
Improved predictability: Through automated testing and CI/CD, impact of every change can be quickly assessed

Real Case: After implementing QA processes, an e-commerce platform reduced major pre-launch defects from average of 15 to 3, and launch delay incidents decreased 70%.

2. Improving Return on Investment (ROI)

Cost Comparison:

Fixing defects in requirements phase: Cost 1x
Fixing defects in development phase: Cost 10x
Fixing defects in testing phase: Cost 15x
Fixing defects post-launch: Cost 100x

QA Investment Returns:

Invest $1 in QA processes (requirements review, design review)
Can save $10-100 in later fixing costs

Actual Data: According to IEEE research, 60-80% of software project defects originate from requirements and design phases, yet less than 20% of QA resources are typically invested in these phases.

3. Enhancing Customer Satisfaction

Three Levels of Quality:

Meeting requirements: Product delivers requested features (QC verification)
Defect-free: Product is stable and reliable (QC testing)
Exceeding expectations: Product is user-friendly with excellent performance (QA design review)

Practical Recommendations (for PMs):

Present test coverage and defect trends in every Sprint Review
Establish “Quality Dashboard” to track quality metrics in real-time
Include QA/QC activities in Sprint schedule planning, avoid compressing testing time

Development Team (RD) Perspective: Practical Methods and Tool Integration

1. Integrating QA Activities into Scrum Process

Sprint Planning Phase

QA Activities RD Should Participate In:

Requirements clarification: Work with PO and QA to confirm Acceptance Criteria for User Stories
Testability assessment: Ensure each User Story has clear testing methods
Testing strategy discussion: Decide which features need unit tests, integration tests, E2E tests

Practical Example:

User Story: Users can pay with credit cards

Acceptance Criteria:
1. Support Visa, MasterCard, JCB
2. Display clear error messages on payment failure
3. Send confirmation email after successful payment

Testing Strategy:
- Unit tests: Payment logic, error handling
- Integration tests: Payment gateway API integration
- E2E tests: Complete shopping flow
- Manual tests: Error message presentation, email format

Daily Scrum Phase

Quality Information RD Should Share:

Did yesterday’s completed features pass unit tests?
Is there technical debt needing attention?
Are there testing difficulties encountered?

Sprint Review Phase

Quality Evidence RD Should Present:

Test coverage reports
Automated test execution results
Performance test data (if applicable)

2. Development Team Quality Practices

Practice 1: Test-Driven Development (TDD)

Why TDD Helps RD:

Write tests before code, ensuring code meets requirements
Tests serve as documentation, helping new team members quickly understand code logic
Tests protect refactoring, reducing risk of introducing new defects

Practical Example:

# 1. Write test first (Red)
def test_calculate_discount():
    order = Order(total=1000, discount_code="VIP20")
    assert order.calculate_final_price() == 800  # 20% discount

# 2. Write code to pass test (Green)
class Order:
    def calculate_final_price(self):
        if self.discount_code == "VIP20":
            return self.total * 0.8
        return self.total

# 3. Refactor to improve code quality (Refactor)
class Order:
    DISCOUNT_RATES = {
        "VIP20": 0.2,
        "VIP10": 0.1
    }

    def calculate_final_price(self):
        discount_rate = self.DISCOUNT_RATES.get(self.discount_code, 0)
        return self.total * (1 - discount_rate)

Practice 2: Continuous Integration (CI) and Automated Testing

CI Pipeline RD Should Establish:

Code commit → Git Push
Automated build → Compile, package
Automated testing → Unit tests, integration tests
Code quality checks → SonarQube, ESLint
Deploy to test environment → Automatic deployment
Feedback results → Slack, Email notifications

Recommended Tools:

CI Platforms: Jenkins, GitLab CI, GitHub Actions, CircleCI
Testing Frameworks: JUnit (Java), pytest (Python), Jest (JavaScript)
Code Coverage: JaCoCo, Coverage.py, Istanbul

Practice 3: Code Review

Effective Code Review Checkpoints:

Does code follow team Coding Standards?
Are there obvious logic errors or potential bugs?
Is there appropriate error handling?
Are there sufficient unit tests?
Are there security vulnerabilities (SQL Injection, XSS, etc.)?
Are there performance issues (N+1 queries, memory leaks, etc.)?

Code Review Best Practices:

Each Pull Request should not exceed 400 lines of code (beyond this, thorough review becomes difficult)
Review time controlled within 60 minutes
Use checklists to ensure review completeness
Automated checks (linters, static analysis) support manual review

3. Common RD Challenges and Solutions

Challenge 1: “Writing tests takes too much time, affecting development progress”

Solutions:

Short-term: Indeed takes 20-30% more time
Long-term: Reduces debugging and fixing time by 50-70%
Strategy: Prioritize tests for core logic and error-prone areas

Challenge 2: “Test environment unstable, tests frequently fail”

Solutions:

Use Docker to containerize test environments, ensuring consistency
Mock external dependencies (APIs, databases), reduce environmental factors
Establish dedicated test database, avoid conflicts with development environment

Challenge 3: “Legacy code has no tests, difficult to refactor”

Solutions:

Apply “Boy Scout Rule”: Add tests for areas when modifying
Prioritize adding tests for high-risk, high-change modules
Use “Golden Path Testing”: Test main flows first, gradually add edge cases

QA Engineer Perspective: Testing Strategies and Best Practices

1. QA Role Positioning in Scrum

Traditional Waterfall vs. Scrum QA:

Comparison Aspect	Traditional Waterfall	Scrum Agile
Participation timing	After development completion	From Sprint Planning onwards
Testing cycle	Concentrated testing late in project	Continuous testing each Sprint
Relationship with development	Separate department, handoff-based	Same team, collaboration-based
Scope of responsibility	Find defects	Prevent defects + Find defects

Core Responsibilities of Scrum QA:

Help define “Definition of Done” (DoD)
Participate in requirements clarification, ensure testability
Design testing strategies and test cases
Execute tests (manual + automated)
Track defects and verify fixes
Provide quality reports and improvement suggestions

2. Testing Strategy: The Testing Pyramid

Testing Pyramid Principle:

        /
       /    E2E Tests (10%)
      /----
     /       Integration Tests (20%)
    /--------
   /           Unit Tests (70%)
  /-----------

Why This Distribution?

Unit Tests: Fast, stable, easy to maintain, should comprise majority
Integration Tests: Verify module interactions, moderate use
E2E Tests: Cover critical business flows, but slow and fragile, minimal use

3. Testing Activities in Each Sprint

Sprint Planning (Sprint Day 1)

Work QA Should Complete:

Review User Stories’ Acceptance Criteria
Identify testing scope and risks
Estimate testing workload and include in Sprint planning
Determine which test environments and test data are needed

During Sprint Execution (Days 2-9)

Activities QA Should Perform:

Test case design: Design test cases based on User Stories
Test data preparation: Create data needed for testing
Automated test writing: Write automated tests for new features
Continuous testing: Test immediately after developers complete features
Defect tracking: Record defects and verify fixes

Sprint Review (Sprint Last Day)

Information QA Should Provide:

Test execution results summary
Test coverage reports
Defect statistics and trend analysis
Risk assessment and recommendations

Sprint Retrospective

Questions QA Should Reflect On:

Were testing activities completed on time?
Were there any testing gaps?
Is automated test coverage sufficient?
Is team collaboration smooth?
How to improve in next Sprint?

4. Automated Testing Practices

When Should Tests Be Automated?

Tests Suitable for Automation:

Repeatedly executed tests (like regression tests)
Data-driven tests (multiple input validations)
Cross-browser/cross-platform tests
Performance and stress tests

Tests Not Suitable for Automation:

One-time tests
Tests requiring human judgment (UX, visual design)
Cases where automation cost exceeds manual testing cost

Automated Testing Tool Selection

Web Application Testing:

Selenium: Most widely used, supports multiple languages
Playwright: Emerging tool, fast and stable
Cypress: Developer-friendly, suitable for frontend testing

API Testing:

Postman: Easy to use, supports automation
Rest Assured: Java ecosystem
pytest + requests: Python ecosystem

Mobile Application Testing:

Appium: Cross-platform support
Espresso: Android native
XCUITest: iOS native

5. QA Workflow Example

Complete Testing Workflow:

1. Receive User Story
   - User Story: Users can reset password
   - Acceptance Criteria:
     * Receive reset link after entering email
     * Link valid for 24 hours
     * New password must meet security rules (8+ characters, uppercase/lowercase)

2. Design Test Cases
   - Normal flow testing
   - Boundary value testing (password length)
   - Negative testing (invalid email, expired link)
   - Security testing (CSRF, XSS)

3. Prepare Test Data
   - Create test user accounts
   - Set up test email inbox

4. Execute Tests
   - Manual testing of new features
   - Run automated regression tests
   - Record test results

5. Defect Management
   - Found defect → Record in Jira
   - RD fixes → Verify fix
   - Verification passes → Close defect

6. Test Report
   - Test case execution rate: 95%
   - Test pass rate: 92%
   - Number of defects: 3 (fixed)
   - Risk assessment: Low risk, ready for release

6. Common QA Challenges and Solutions

Challenge 1: Insufficient time, testing compressed

Resolution Strategies:

Include testing work in estimates during Sprint Planning
Establish “DoD” requiring all features to pass testing before completion
Increase automated testing percentage, speed up regression testing
Adopt risk-based testing, prioritize high-risk features

Challenge 2: Frequent requirement changes, test cases need constant updates

Resolution Strategies:

Adopt BDD (Behavior-Driven Development) style for test writing
Link test cases with User Stories, update synchronously with requirement changes
Use parameterized tests to reduce number of test cases

Challenge 3: High maintenance cost of automated tests

Resolution Strategies:

Adopt Page Object Model design pattern, improve maintainability
Build shared function libraries, avoid duplicate code
Regularly refactor test code, delete obsolete tests
Use stable locator strategies (prioritize ID, data-testid)

Real Cases: Successful Scrum QA/QC Practices

Case 1: FinTech Company Quality Transformation

Background: Before adopting Scrum, a fintech company had post-launch defect rate of 50+ per month, frequent customer complaints.

Implemented QA/QC Improvements:

Established “Definition of Done”: All features must pass unit tests, integration tests, Code Review
Introduced TDD: Core financial logic developed using TDD
Built CI/CD Pipeline: Every commit automatically executes 1000+ test cases
Early QA involvement: Participate in requirements clarification from Sprint Planning

Results:

Post-launch defect rate reduced to below 5 per month (90% reduction)
Test coverage increased from 30% to 85%
Customer satisfaction improved from 6.5 to 8.8 (out of 10)
Development speed actually increased 20% (due to reduced bug fixing time)

Case 2: E-commerce Platform Automated Testing Practice

Background: E-commerce platform needed frequent feature updates, but regression testing took too long (3 days).

Implementation Strategy:

Built automated testing framework (Selenium + Python)
Prioritized automating high-frequency features: login, search, add to cart, checkout
Established test data factory, quickly generate test data
Integrated into CI Pipeline, automatically execute before each deployment

Results:

Regression testing time reduced from 3 days to 2 hours
Test case count increased from 200 to 800
Defect detection timing moved earlier (from testing phase to development phase)

Frequently Asked Questions (FAQ)

Q1: Do Scrum teams need dedicated QA engineers?

A: Depends on team size and product complexity:

Small teams (5 or fewer): Developers can serve as QA, but need clear testing standards
Medium teams (6-9 people): Recommend at least 1 dedicated QA
Large teams (10+ people): Recommend QA to RD ratio of 1:3 to 1:4

Regardless of team size, quality is the entire team’s responsibility, not just QA’s.

Q2: How to maintain testing quality in fast-iterating Scrum?

A: Key strategies:

Shift left testing: Start designing tests in requirements phase
Automation first: Automate repetitive tests
Risk-based testing: Prioritize testing high-risk features
Continuous integration: Trigger automated tests with every code change

Q3: What should automated test coverage target be?

A: No absolute standard, but common industry targets:

Unit tests: 70-80%
Integration tests: 40-60%
E2E tests: Cover critical business flows (about 20-30 main scenarios)

Key is not pursuing 100% coverage, but covering critical paths and high-risk areas.

Q4: How to convince management to invest in QA/QC?

A: Use data to speak:

Calculate “defect fixing cost”: Requirements phase vs. post-launch cost difference (can be 100x)
Show “quality metric trends”: Defect count, test coverage, launch incidents
Reference industry data: 60% of software project failures are quality-related
Provide ROI calculation: Invest $X in automated testing, can save $Y in manual testing costs

Q5: How can RD and QA collaborate better?

A: Build collaborative culture:

Shared goals: Quality is shared responsibility, not adversarial relationship
Early communication: QA involves in requirements discussions before development starts
Pair testing: RD and QA design test cases together
Knowledge sharing: Regularly hold testing technique sharing sessions
Tool sharing: RD and QA use same testing frameworks

Conclusion: Practice Path from Quality to Excellence

In Scrum agile development, QA and QC are not the “last line of defense” in the development process, but “full-course partners.” The key to success lies in:

For Project Managers and Clients:

View QA/QC as investment for reducing risk and improving ROI, not cost
Reserve sufficient testing time in Sprint Planning
Establish quality dashboards to track quality trends in real-time

For Development Teams:

Adopt practices like TDD, continuous integration, code review
View testing as part of development, not additional burden
Collaborate closely with QA to jointly improve product quality

For QA Engineers:

Transform from test executor to quality advocate
Involve early in requirements phase, prevent defects
Build automated testing, improve testing efficiency
Continuously learn new technologies and testing methods

Ultimate Goal: Build a “Built-in Quality” culture where quality becomes everyone’s responsibility, not just QA’s work.

Through the strategies and practices introduced in this article, whether you’re a PM, RD, or QA, you can more effectively drive quality improvement in Scrum teams, ultimately delivering high-quality products that satisfy customers.

Introduction: Why QA and QC Are Critical in Scrum

Core Differences Between QA and QC: From Concept to Practice

QA (Quality Assurance): Preventive Strategy

QC (Quality Control): Detective Activities

Relationship Between QA and QC

Project Manager and Client Perspective: Business Value of QA/QC

1. Reducing Project Risks

2. Improving Return on Investment (ROI)

3. Enhancing Customer Satisfaction

Development Team (RD) Perspective: Practical Methods and Tool Integration

1. Integrating QA Activities into Scrum Process

Sprint Planning Phase

Daily Scrum Phase

Sprint Review Phase

2. Development Team Quality Practices

Practice 1: Test-Driven Development (TDD)

Practice 2: Continuous Integration (CI) and Automated Testing

Practice 3: Code Review

3. Common RD Challenges and Solutions

Challenge 1: “Writing tests takes too much time, affecting development progress”

Challenge 2: “Test environment unstable, tests frequently fail”

Challenge 3: “Legacy code has no tests, difficult to refactor”

QA Engineer Perspective: Testing Strategies and Best Practices

1. QA Role Positioning in Scrum

2. Testing Strategy: The Testing Pyramid

3. Testing Activities in Each Sprint

Sprint Planning (Sprint Day 1)

During Sprint Execution (Days 2-9)

Sprint Review (Sprint Last Day)

Sprint Retrospective

4. Automated Testing Practices

When Should Tests Be Automated?

Automated Testing Tool Selection

5. QA Workflow Example

6. Common QA Challenges and Solutions

Challenge 1: Insufficient time, testing compressed

Challenge 2: Frequent requirement changes, test cases need constant updates

Challenge 3: High maintenance cost of automated tests

Real Cases: Successful Scrum QA/QC Practices

Case 1: FinTech Company Quality Transformation

Case 2: E-commerce Platform Automated Testing Practice

Frequently Asked Questions (FAQ)

Q1: Do Scrum teams need dedicated QA engineers?

Q2: How to maintain testing quality in fast-iterating Scrum?

Q3: What should automated test coverage target be?

Q4: How to convince management to invest in QA/QC?

Q5: How can RD and QA collaborate better?

Conclusion: Practice Path from Quality to Excellence

Related Articles

Related posts:

Leave a Comment Cancel reply