Agile Test Quadrants

The Framework

Brian Marick's agile test quadrants organize testing activities by two dimensions: business-facing vs technology-facing, and supporting the team vs critiquing the product. The quadrants help teams ensure they invest in all types of testing, not just the ones that are easiest to automate.

                    Business-Facing
                         |
    Q2: Functional    |  Q3: Exploratory
    tests, story      |  testing, usability
    tests, prototypes |  testing, UAT,
    (Supporting       |  alpha/beta testing
     the Team)        |  (Critiquing the
                      |   Product)
    ------------------+------------------
    Q1: Unit tests,   |  Q4: Performance
    component tests,  |  testing, security
    integration tests |  testing, load
    (Supporting       |  testing
     the Team)        |  (Critiquing the
                      |   Product)
                         |
                    Technology-Facing

Quadrant 1: Unit and Integration Tests (Technology-Facing, Supporting the Team)

What It Includes

• Unit tests
• Component tests
• Integration tests
• API tests

Characteristics

• Fully automated: No manual execution
• Run continuously: On every push and PR
• Developer-driven: Written primarily by developers, reviewed by QA
• Fast feedback: Results in seconds to minutes

QA's Role in Q1

• Review developer-written tests for coverage gaps
• Ensure integration tests cover API contracts and database interactions
• Monitor test reliability (flake rates)
• Advocate for adequate unit test coverage in the DoD

Example

// Unit test (Q1)
test('calculateTotal applies 10% discount for orders over $100', () => {
  const items = [{ price: 60 }, { price: 50 }];
  expect(calculateTotal(items)).toBe(99); // $110 - 10% = $99
});

// Integration test (Q1)
test('POST /api/orders creates order in database', async () => {
  const response = await request(app)
    .post('/api/orders')
    .send({ items: [{ productId: 1, quantity: 2 }] });
  expect(response.status).toBe(201);
  expect(response.body.orderId).toBeDefined();
});

Quadrant 2: Functional and Story Tests (Business-Facing, Supporting the Team)

What It Includes

• Functional tests (verifying acceptance criteria)
• Story tests (automating user stories)
• Prototypes and mockups for verification
• BDD scenarios (Given/When/Then)

Characteristics

• Mostly automated: Automated where possible, with some manual verification
• Run on PRs and merges: Gate code before it reaches main
• QA-driven: Written primarily by QA engineers
• Business language: Tests express business rules, not technical details

QA's Role in Q2

• Write and maintain functional test suites
• Translate acceptance criteria into automated tests
• Verify that features meet business requirements
• Collaborate with PO to define expected behavior

Example

// Functional test (Q2) -- written in business terms
test('user can complete checkout with a valid coupon', async ({ page }) => {
  await page.goto('/products');
  await page.click('[data-testid="add-to-cart-premium-plan"]');
  await page.click('[data-testid="go-to-checkout"]');
  await page.fill('[data-testid="coupon-input"]', 'SAVE20');
  await page.click('[data-testid="apply-coupon"]');
  await expect(page.locator('[data-testid="discount"]')).toHaveText('-$20.00');
  await page.click('[data-testid="complete-purchase"]');
  await expect(page).toHaveURL('/order-confirmation');
});

# BDD scenario (Q2)
Scenario: Apply valid coupon at checkout
  Given I have a product in my cart
  When I enter coupon code "SAVE20"
  And I click "Apply"
  Then I should see a $20 discount
  And the total should reflect the discount

Quadrant 3: Exploratory and Usability Testing (Business-Facing, Critiquing the Product)

What It Includes

• Exploratory testing (creative, unscripted investigation)
• Usability testing (is it easy to use?)
• User acceptance testing (UAT)
• Alpha and beta testing
• Accessibility testing (manual review)

Characteristics

• Manual by design: Automation cannot replace human creativity and judgment
• Continuous during sprint: Not just at the end
• QA and user-driven: QA explores, users validate
• Finds unknown unknowns: Discovers issues nobody thought to write a test for

QA's Role in Q3

• Conduct structured exploratory testing sessions
• Identify usability issues that automated tests miss
• Coordinate UAT with business stakeholders
• Test edge cases, error recovery, and unusual user paths

Exploratory Testing Session Structure

Session Charter: "Explore the new checkout flow focusing on error recovery"
Duration: 60 minutes
Focus areas:
  - What happens when payment fails?
  - What happens when the user navigates away mid-checkout?
  - What happens with slow network?
  - What happens when the session expires during checkout?

Findings:
  - Bug: Back button after payment failure shows empty cart (SHOP-891)
  - Bug: No timeout message when payment API is slow (SHOP-892)
  - Observation: Error messages use technical language ("HTTP 500") instead of user-friendly language
  - Suggestion: Add a progress indicator during payment processing

Why Q3 Cannot Be Automated

Automated tests verify known, expected behavior. Exploratory testing discovers unknown, unexpected behavior. A robot does not wonder "what if I paste an email address into the phone number field?" or notice that the checkout button is barely visible on a dark background. Human intuition and creativity are irreplaceable in Q3.

Quadrant 4: Performance, Security, and Load Testing (Technology-Facing, Critiquing the Product)

What It Includes

• Performance testing (response times, throughput)
• Load testing (behavior under heavy traffic)
• Stress testing (behavior beyond expected load)
• Security testing (penetration testing, SAST/DAST)
• Reliability testing (chaos engineering, failover)

Characteristics

• Automated with human analysis: Tools generate data, humans interpret results
• Run before major releases: Not on every PR (too expensive)
• Specialized skills: Often requires dedicated performance or security expertise
• Non-functional focus: Not about features working, but about how well they work

QA's Role in Q4

• Define performance budgets (LCP < 2.5s, API p95 < 500ms)
• Run load tests and analyze results
• Coordinate security scans and triage findings
• Monitor production performance as a continuous activity

Example

// k6 load test (Q4)
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  vus: 100,        // 100 virtual users
  duration: '5m',  // Run for 5 minutes
  thresholds: {
    http_req_duration: ['p(95)<500'],  // 95% of requests under 500ms
    http_req_failed: ['rate<0.01'],    // Less than 1% failure rate
  },
};

export default function () {
  const res = http.get('https://staging.example.com/api/products');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 500ms': (r) => r.timings.duration < 500,
  });
  sleep(1);
}

Balancing the Four Quadrants

The key insight: all four quadrants are necessary. Teams that only automate Q1 tests miss business-level gaps. Teams that only do Q3 exploratory testing miss structural issues. A mature QA strategy covers all four quadrants with appropriate investment.

Investment Guide

Early-stage teams should invest heavily in Q1 (unit tests) because they provide the fastest feedback. Mature teams should distribute effort more evenly, with significant Q4 investment in performance and security.

Quadrant Summary

Hands-On Exercise

1. Map your current testing activities to the four quadrants. Which quadrants are well-covered? Which are neglected?
2. Identify one testing activity in each quadrant and estimate the time your team spends on each
3. Conduct a 30-minute exploratory testing session using the charter format above
4. Define a performance budget for one critical API endpoint and write a simple load test
5. Propose a quadrant rebalancing plan if you find your team is over-invested in Q1 and under-invested in Q3