Agile Testing: Integrating Quality into Every Sprint
In the traditional software development model, quality assurance is a phase: it happens after development is complete, before the product is released. A dedicated QA team receives the finished software, executes test scripts, records defects, and sends the software back for fixing if the defect count exceeds an acceptable threshold. The process is sequential -- development, then QA, then fix, then re-test, then release -- and the quality gate sits at the end of the pipeline.
This model has a structural incompatibility with Scrum. Scrum requires potentially shippable product at the end of every sprint. If testing happens after development in a sequential phase, and if the sprint is two weeks, then every sprint must somehow accommodate both complete feature development and complete testing within the same two-week window. In practice, this means testing is compressed, deferred to a hardening sprint, or allocated its own separate iteration -- all of which reintroduce the sequential waterfall structure that Scrum is designed to replace.
The resolution is not to find more time for testing. It is to change when and how testing happens. Agile testing is not testing that occurs in an agile project; it is a fundamentally different approach to quality that treats it as an ongoing team responsibility distributed across the sprint rather than a sequential phase conducted by a separate function at the sprint's end.
The Testing Pyramid
The testing pyramid is the foundational model for understanding the right balance of testing in an agile context. It was described by Mike Cohn and has become the standard framing for agile test strategy.
At the base of the pyramid are unit tests: automated tests that verify the behaviour of individual functions, methods, or components in isolation. Unit tests are fast to run, cheap to write relative to their coverage, and specific enough that when they fail, the failure points to exactly what broke. A healthy agile codebase has many hundreds or thousands of unit tests that run in seconds and cover the majority of the system's logic.
In the middle of the pyramid are integration tests: automated tests that verify that components work correctly together -- that the API layer correctly calls the data layer, that the authentication service correctly integrates with the user management service, that the payment processing flow works end-to-end through the relevant services. Integration tests are slower to run than unit tests and take more effort to maintain, so there should be fewer of them, targeting the integration points that carry the most risk.
At the top of the pyramid are end-to-end (E2E) tests: automated tests that drive the full application through a user interface, simulating a real user's journey through the system. E2E tests are the most expensive to write, the slowest to run, and the most fragile -- small changes to the UI can break tests that have nothing to do with the functionality being tested. Effective agile teams have a small number of E2E tests covering the most critical user journeys, supplemented by the much larger base of unit and integration tests.
Test-Driven Development
Test-Driven Development (TDD) is the technical practice most closely associated with agile quality. In TDD, the developer writes an automated test before writing the production code that makes the test pass. The cycle is: write a failing test that describes the desired behaviour, write the minimum code to make the test pass, then refactor the code while keeping the tests passing.
TDD produces several benefits that are difficult to achieve through other means. First, it produces a comprehensive automated test suite as a natural by-product of development rather than as a separate activity. Second, it forces the developer to think about the design of the code from the perspective of how it will be used before writing it, which tends to produce more modular and testable designs. Third, it provides immediate feedback when a change breaks existing behaviour -- the developer knows within seconds of making a change whether it has broken something, rather than finding out hours or days later during a testing phase.
TDD requires discipline and skill to apply effectively. Teams new to it typically go through a period of slower velocity as developers adjust to the practice, followed by a period of higher confidence and lower defect rates as the test suite accumulates. The investment in learning TDD is real, and teams should not expect to adopt it without deliberate coaching and protected time to practice.
Defining Done to Include Quality
The Scrum Definition of Done is the shared understanding of what must be true for a Product Backlog Item to be considered complete. In agile testing, the Definition of Done is the primary mechanism for ensuring that quality is built in rather than bolted on: if the Definition of Done requires automated tests, code review, and a passing build, then no item can be accepted as done without meeting those criteria.
A Definition of Done that treats quality as a deliverable -- not just a property the team hopes the finished item possesses -- typically includes: automated unit tests written and passing; code reviewed by at least one other developer; integration tests updated if the change touches integration points; and the build pipeline passing with no new failures. Teams that are further along in their quality maturity may also include security scanning, performance testing for changes to performance-sensitive code, and accessibility checking for UI changes.
The QA Professional's Evolving Role
The shift to agile testing changes what QA professionals do rather than eliminating their role. The manual test executor at the end of the pipeline becomes less central; the quality coach, automation engineer, and testing strategist become more valuable.
QA professionals in agile teams typically lead the development and maintenance of the automated test suite; collaborate with developers on test design and coverage strategy; conduct exploratory testing to find the issues that scripted tests miss; facilitate the team's conversations about quality standards and Definition of Done; and advocate for quality considerations in backlog refinement and sprint planning. The role is collaborative and distributed rather than sequential and gatekeeping.
Continuous testing in CI/CD pipelines -- where every code commit triggers an automated test run and a failed test prevents the change from being merged -- is the end state that high-performing agile teams work toward. It requires investment in test automation infrastructure, discipline in keeping the test suite green, and a team culture where a failing test is treated as an immediate priority rather than something to be investigated later. That culture does not emerge spontaneously: it is built through the practices described here, maintained consistently over time.
XNM Consulting works with technology teams on agile delivery practices, including coaching on test-driven development, agile quality frameworks, and CI/CD pipeline design. Learn more about our program and project delivery services.