Agile Testing for QA Teams in Scrum and Kanban

Your sprint ends tomorrow. Three stories still sit in a "Ready for QA" column, a regression suite is red from last night's run, and the product owner just added a "small change" to the acceptance criteria. If this feels familiar, the problem usually is not your skill or your effort—it is the way testing is wired into your delivery process. Agile testing reshapes that wiring. Instead of treating quality as a phase that comes after development, it distributes testing activities across the entire sprint. This article gives you the specific workflows, checklists, and anti-patterns you need to make that shift concrete. You will walk away with a rebalanced test strategy you can bring into your next sprint planning session.

What Is Agile Testing?

Agile testing is a testing practice that follows agile software development principles: iterative delivery, continuous feedback, and whole-team responsibility for quality [1]. Unlike sequential models where testing occupies a distinct phase after coding, agile testing embeds verification and validation into every sprint activity—from backlog refinement through to the sprint review.

The ISTQB Foundation Level syllabus defines testing as a set of activities that should be aligned with the chosen software development lifecycle model [1]. In agile contexts, this means your testing activities are not downstream; they run in parallel with development and sometimes ahead of it.

Why It Matters for QA

When testing is treated as a phase, you inherit two structural problems. First, defects are discovered late, when the cost of fixing them is highest. Second, your team's feedback loop stretches across days rather than hours.

Agile testing solves both. By embedding testing into every ceremony and artifact, you compress the feedback loop, catch ambiguities earlier, and reduce the volume of defects that escape to later stages. In many effective agile teams, the tester's most impactful work happens before a single line of code is written.

Shift-Left Test Strategy: Moving Quality Upstream

A shift-left test strategy means moving testing activities earlier in the development lifecycle. In practice, this has three concrete components for a Scrum or Kanban team.

1. Backlog Refinement as Test Design

Your testing does not begin when a developer marks a story "ready for QA." In well-functioning agile teams, it typically begins during backlog refinement. When the product owner presents a user story, your job is to ask questions that expose hidden assumptions:

• What happens when the input is empty, negative, or above the maximum length?
• Which existing features could this change break?
• Are there implicit performance expectations?

Each answer becomes a test condition you can draft before the sprint even starts.

2. Acceptance Criteria Review

Well-written acceptance criteria are testable. If a criterion reads "the system should respond quickly," that is not testable—push back. Rewrite it as "the API returns a response within 300 ms at the 95th percentile under 500 concurrent users." ISO/IEC 25010 provides a structured quality model—including performance efficiency and functional suitability characteristics—that you can reference when the team debates what "quality" means for a given story [2].

3. Pairing on Unit Tests

In some agile teams, the tester does not write the unit tests—but they influence what gets tested. Sit with the developer during implementation and suggest edge cases. This pairing reduces the number of defects that reach integration testing and strengthens the base of the test pyramid.

What NOT to do: Do not shift left by simply demanding that developers "write more unit tests" without providing test conditions. Shifting left without collaboration often leads to high unit test counts with low defect-detection effectiveness.

How to Rebalance Your Test Pyramid Levels

The test pyramid is a model that recommends a large base of fast, isolated unit tests; a middle layer of integration/service tests; and a small top layer of end-to-end (E2E) UI tests [1]. Many teams have this inverted—heavy on E2E, light on unit coverage. Rebalancing is not a one-sprint project, but you can start with a structured approach.

Step 1: Audit Your Current Distribution

Count the tests in each layer. A common pattern in teams struggling with slow pipelines is a roughly even split across layers—or worse, a majority of E2E tests. Document the current ratio before you propose changes.

Step 2: Identify Candidates for Pushdown

Review your E2E tests and ask: "Does this test genuinely need a full browser session, or is it verifying business logic that could be tested at the API or unit level?" Tests that check data transformations, validation rules, or calculations are usually candidates for pushdown.

Step 3: Set Layer Targets

A frequently used starting heuristic is roughly 70% unit, 20% integration, 10% E2E. However, the right ratio depends on your architecture. A microservices system may need a proportionally larger integration layer because contract testing between services is critical. A monolith with a complex UI might retain more E2E tests than the heuristic suggests.

Common Pitfalls

• Flaky E2E tests stay because "they sometimes catch things." Track flaky-test frequency. If a test fails without a real defect more than a third of the time, it is generating noise, not signal.
• Pushdown happens without updating coverage. When you delete an E2E test, confirm that the equivalent logic is covered at a lower level. Otherwise you are removing safety nets without building new ones.

Test Pyramid Rebalancing Checklist

Exploratory Sprint Testing: The Human Layer

Automated tests verify what you expect. Exploratory sprint testing finds what you did not expect. In agile, exploratory testing is not ad-hoc clicking—it is a disciplined, time-boxed investigation guided by a test charter.

Writing Effective Test Charters

A charter has three parts:

1. Explore: the area or feature under test (e.g., "the checkout flow for guest users").
2. With: the technique or heuristic (e.g., "boundary values on the quantity field and rapid state transitions").
3. To discover: the risk you are investigating (e.g., "data loss or incorrect pricing under concurrent edits").

When to Run Exploratory Sessions

Schedule 60–90-minute sessions mid-sprint, after the first stories reach "dev complete." This timing gives you working software to explore while leaving enough time to log findings before sprint review.

ISO/IEC/IEEE 29119-3 provides templates for test completion reports that you can adapt for documenting exploratory session outcomes—capturing charter, duration, findings, and areas not covered [3]. This documentation is especially useful when your team needs traceability for compliance or audit purposes.

What NOT to do: Do not treat exploratory testing as a substitute for automated regression. They serve different purposes. Exploratory testing is about learning and risk discovery; automated regression is about preventing known defects from returning. Teams that rely solely on one approach tend to develop blind spots.

The Scrum Team Tester's Sprint Workflow

Here is a concrete, day-by-day workflow for a scrum team tester in a two-week sprint. Adapt the timing if you work in Kanban—the activities remain the same, but they flow continuously rather than in sprint-bounded cycles.

Days 1–2: Planning and Preparation

• Participate in sprint planning. For every story the team commits to, ask: "What does 'done' look like from a testing perspective?"
• Draft test conditions for high-priority stories based on acceptance criteria.
• Verify that your test environment matches the sprint's technical scope.

Days 3–7: Parallel Testing and Collaboration

• Review pull requests for testability—not the code logic, but whether the change is structured in a way that supports testing (e.g., are test IDs added to new UI elements?).
• Execute test conditions as stories reach "dev complete."
• Run a mid-sprint exploratory session using the charter format described above.
• Pair with developers on defect fixes—explain what you found, discuss root cause, and verify the fix together.

Days 8–9: Regression and Integration

• Trigger the full regression suite. Triage failures immediately—classify each as a real defect, a flaky test, or an environment issue.
• Run cross-story integration tests for features that interact.

Day 10: Sprint Review and Retrospective

• Present test results in sprint review. Focus on risk: "Here is what we tested, here is what we found, and here is what remains uncertain."
• In retrospective, raise testing process improvements. Track whether improvements from previous retrospectives actually happened.

Sprint Workflow Checklist

Anti-Patterns: What Not to Do

Recognizing failure modes is often more useful than memorizing best practices. Here are patterns that frequently undermine agile testing efforts.

1. The "Mini-Waterfall" Sprint

Stories move in a batch: all development in week one, all testing in week two. This eliminates the feedback loop that makes agile work. The fix: limit work in progress so stories flow through development and testing continuously.

2. Tester as Gatekeeper

When a single tester is the sole owner of quality, developers stop thinking about testability. Quality tends to be more effective as a shared team responsibility [1]. The tester's role shifts from gatekeeper to quality coach—someone who helps the whole team build quality in, rather than inspecting it after the fact.

3. Automating Everything at the UI Level

Full E2E automation of every scenario creates a slow, brittle suite. The test pyramid exists to prevent this [1]. If your pipeline takes 45 minutes because of Selenium tests that could be API-level checks, you are paying a maintenance tax on the wrong tests.

4. Skipping Test Documentation Entirely

Agile values working software over comprehensive documentation—but "over" does not mean "instead of." Lightweight test documentation—charters, test condition lists, and brief session notes—provides traceability without bureaucratic overhead. ISO/IEC/IEEE 29119-3 offers scalable documentation templates that can be adapted to agile contexts without becoming heavy process artifacts [3].

Real-World Example

⚠️ Disclaimer: The following scenario is an illustrative example based on typical industry patterns. The specific metrics are hypothetical estimates designed to demonstrate realistic outcomes, not measured data from a documented project. They should not be cited as factual benchmarks.

Context

A mid-sized fintech team (four developers, one tester, one product owner) running two-week Scrum sprints. The team delivers a consumer-facing payment application with regulatory compliance requirements.

Challenge

Testing was concentrated in the final three days of each sprint. The tester received stories in a batch, had limited time for exploratory investigation, and the E2E regression suite—at roughly 400 browser-based tests—took over 90 minutes to run. An estimated 35% of E2E test failures were flaky (not linked to actual defects), consuming significant triage time. Defects found late in the sprint frequently caused story spillover into the next iteration.

Solution

The team implemented three changes over three sprints:

1. Shift-left participation: The tester joined backlog refinement and began drafting test conditions before sprint planning. This allowed developers to address edge cases during implementation rather than after.
2. Test pyramid rebalancing: The team audited the E2E suite and identified approximately 120 tests that verified business logic (e.g., fee calculations, validation rules) rather than UI behavior. These were rewritten as API-level integration tests. The remaining E2E tests were stabilized by adding explicit waits and reducing shared test data dependencies.
3. Structured exploratory sessions: The team introduced two 90-minute exploratory sessions per sprint using charters focused on newly integrated features and regulatory edge cases.

Results (Illustrative Estimates)

• Pipeline execution time dropped from approximately 90 minutes to approximately 35 minutes after the test pyramid rebalancing.
• Flaky test failures decreased from an estimated 35% to roughly 8% of total E2E runs.
• Late-sprint defect discovery (days 8–10) declined by an estimated 55%, as shift-left practices caught ambiguities earlier.
• The team reported fewer story spillovers and more predictable sprint velocity.

Key Takeaways

• Rebalancing the test pyramid is typically a multi-sprint effort. Starting with a focused audit of pushdown candidates helps make progress measurable.
• Shift-left works most effectively when the tester participates in refinement and planning, not just in code review.
• Structured exploratory sessions tend to surface a different category of defects than automated regression—they complement each other rather than overlap.