Agile Testing Explained: Values, Quadrants, and Process

The Origin of Agile Testing

Agile testing is a software testing practice based on the values of Agile software development. It's a continuous process, where the product is developed and tested through the development life cycle rather than sequential, where testing is a separate phase. As part of the Agile testing process, the entire team is responsible for high product quality through collective ownership of all testing aspects.

Although a review of the history seems a bit too academic, I believe that to understand the true meaning of Agile testing we must know its origin.

Agile testing started in the late 1990s. It was originally introduced in an Extreme Programming ("XP") project named Chrysler Comprehensive Compensation System, also known as C3. This project was to replace the payroll application with a single system that had no user interface (it uses files to read employee statistics that were analyzed and sent to a print vendor to process deposits).

The C3 project is an important milestone from an Agile perspective as it became famous as the birth project of XP. Under the leadership of Kent Beck (an American software engineer and the creator of extreme programming who took ownership of the project after it failed to reach a stable state), it became the first real project to embrace all the practices that are now known as Extreme Programming.

The C3 project had no separated testing groups. Instead, the testing was conducted by the same group. From the different XP principles, including pair-programming, they created test-driven development (TDD).

To understand why test-driven development worked so well in this project, that had no testing teams, let's return to the layers of the product that had no user interface. This little detail makes all the difference, as it allows programmers to test their code with a clear definition of the expected results. This is the perfect scenario for programmers who had no test groups to rely on.

As the project became a success (at least relative to its earlier phases), the popularity of Extreme Programming and its principles increased in the industry. By the time the project was canceled (1999), there were many other software projects following XP and replicating C3's early success.

As the popularity of Extreme Programming continued to grow, it had a great influence on the testing field as it promoted new ideas such as the removal of the testing role and that all tests should be automated.

Key Takeaway: Agile testing started in the late 1990s on the Chrysler Comprehensive Compensation System, an Extreme Programming project under Kent Beck where the same group wrote and tested the code and test-driven development emerged.

Agile Testing in Scrum

XP is an Agile framework that has a specific technical guideline for Agile software development. At the beginning of this chapter, we saw how it changed testing in the Agile environment.

However, as the years went by, Scrum won as the leading Agile framework that set the standards for Agile software development. Scrum focuses on the framework of the development process but ignores the "how-to" for handling the practical side of software development and particularly how to conduct tests in this environment.

Furthermore, Scrum does not specify any information about any test role, as it embraces team ownership of the product with the expectation that they should decide how to do the work without external interference. As you can imagine, the lack of a real definition for this topic resulted in many misconceptions, innovations, and experiments. Now, after a few decades, there is still no agreed definition that fully addresses this topic.

The Scrum Guide has since made the team structure clearer. It states that a Scrum Team has no sub-teams or hierarchies, and it calls every person doing the work a Developer, whatever their specialty. It also holds those Developers accountable for instilling quality by adhering to a Definition of Done. Scrum still names no tester role, because testing is part of what the whole team owns in each Sprint.

Key Takeaway: Scrum names no tester role and calls every person doing the work a Developer, so testing is owned by the whole Scrum Team through the Definition of Done in each Sprint.

The Agile Testing Values

Software testers before the transition to Agile used to work in dedicated testing departments and act as the control gate for quality. Now that the organization has started the Agile transition, those testers are integrated into small teams and in many cases have the feeling that they are less important to the overall process.

An Agile transition affects almost all aspects of the organization, such as mindset, culture, and development practices. A vast impact on such important aspects has a direct influence on how the organization conducts its testing, which is of course a major part of the development process.

Agile teams must adopt a new way of thinking when it comes to software testing. This is the only way to adapt to the nature of Agile development. A good start is to examine the four values of the Agile Manifesto, which provide all the answers we need to enter a new era of testing.

The values set the mindset, but a team still needs a way to decide which tests to run. The Agile Testing Quadrants, a matrix Brian Marick created and Lisa Crispin and Janet Gregory adapted, sort that work along two axes: business-facing against technology-facing, and supporting the team against critiquing the product. The four groups cover unit tests and TDD, acceptance tests and worked examples, exploratory and usability testing, and performance, load, and security testing. The quadrant numbers are labels, not an order of work.

Check out this video on integrating testing into Agile workflows, it breaks down key practices that help Agile teams maintain quality without micromanagement.

Key Takeaway: The four Agile Manifesto values set the Agile testing mindset, while the Agile Testing Quadrants sort the actual test work along business-facing against technology-facing and supporting the team against critiquing the product.

Individuals and interactions over processes and tools

This value values the human factor over any processes and tools, a standard in traditional software development. We can see it in how Agile teams are built as cross-functional, with both developers and testers. The main idea of integrating software testers with other roles within the same team is demonstrated by two main points.

First, at the center of Agile software development is a team that can produce an incremental working product at the end of each sprint to increase value for the customer. Can they do it without testing it? No, because each story must be developed and tested within the same sprint as part of the Definition of Done.

The second reason is that many pitfalls and delays are related to the lack of synchronization between departments which directly impacts the quality of the testing effort. In Agile, we build small integrated teams that help prevent many of these impediments. A critical clarification about ignoring processes and tools: agile testing uses different tools at all levels of the testing process. This is the only way to do it effectively.

Key Takeaway: Agile teams are built cross-functional so each story is developed and tested in the same sprint, and valuing people over processes does not remove testing tools, which Agile testing uses at every level.

Working software over comprehensive documentation

This value suggests that an Agile organization should be able to provide working software at any time. In traditional software development, there is a strict separation between the different project phases and explicitly between development and testing (the testing phase can only start once the previous development phase is completed).

This approach is ineffective as most of the tests are conducted at the end of the development process, which increases the risk to the entire release process as quality issues found at this stage will significantly impact the release timeline.

In the Agile development process, testing starts right from the beginning of any new development, as part of the Definition of Done of each user story. This way, the team can release working software that is fully developed and tested.

One of the main activities of traditional testing is comprehensive test documentation which is a mandatory part of any testing project.

Agile testing leaves little room for documentation. As a result, an Agile team will have to adopt new practices based on light test design and specification processes to allow maximum time for test exploration.

The focus of testing now shifts to the things that matter; there is no time to create detailed Software Test Design (STD) that include precise steps or results. Instead, agile teams must rely on advanced techniques like checklists, exploratory testing, error guessing, and mind maps.

Key Takeaway: Agile testing starts at the beginning of each user story rather than after development ends, and replaces detailed Software Test Design documents with checklists, exploratory testing, error guessing, and mind maps.

Customer collaboration over contract negotiation

The third value refers to customers. In Agile, collaboration with the customer is one of the most important things, as user satisfaction takes precedence over everything else. The collaboration starts at the beginning of the project by creating the project backlog, which contains the customer wish list. After that, agile teams use the same approach for their test practices, constantly looking out for the customer's best interests and needs.

From a testing perspective, the product backlog can be seen as the skeleton of the test plan. The team aims to develop a quality product that meets customer demands. Therefore, testers must become involved at the very beginning of the project.

Key Takeaway: The product backlog carries the customer wish list and acts as the skeleton of the Agile test plan, so testers must be involved from the start of the project.

Responding to change by following a plan

The ability of the business to adapt during a project is critical in Agile perception. We live in a dynamic environment, making it almost impossible to design one plan to follow throughout the project. To remain relevant, organizations must gain the ability to absorb change (customer demands, new technology, etc.) that is likely during the project's lifecycle.

The key to this perception is that the organization must understand that changes are part of any project and be ready to handle them. Again, testing is a great example. In the past, test teams created a whole test plan for the entire project, which reduced their ability to absorb changes, each change added more risk, and more tests had to be done.

In an Agile environment, tests are written for limited features and stories. As a result, there is no need to design complete comprehensive test plans for the entire project, allowing the team to adjust their test plan at the lower levels of the project, reduce unwanted risks and increase the effectiveness of the entire development process

Key Takeaway: Agile teams write tests for limited features and stories instead of one comprehensive test plan for the whole project, which lets the test plan absorb change without adding release risk.

How Does AI Change Agile Testing in 2026?

AI changes who drafts the tests, not who owns the quality. Agile testing still places quality with the whole team, and AI tooling now does a larger share of the drafting work inside each sprint. The 2025 DORA State of AI-assisted Software Development report found that 90% of survey respondents use AI at work, and that more than 80% believe it has increased their productivity. The same report found that 30% report little or no trust in the code generated by AI, and that AI adoption continues to have a negative relationship with software delivery stability. Faster code production with flat or falling stability is a testing problem, and it lands on the team rather than on a separate quality gate.

Test tooling has moved the same way. Playwright ships three test agents: a planner that explores the application and produces a Markdown test plan, a generator that turns that plan into executable test files and verifies selectors and assertions against the running app, and a healer that runs the suite and repairs failing tests. Teams set them up with the npx playwright init-agents command and connect them to a coding agent such as VS Code, Claude Code, Codex, or opencode.

The four values above decide whether that help is worth taking. A planner's Markdown test plan is a written specification, so a team that dropped documentation entirely gives an agent nothing to work from, while a team that reviews that plan with its product owner turns customer collaboration into an input the tooling can read. Generated tests still need a person to judge whether they assert the behavior the story asked for. Collective ownership is what stops a sprint from shipping a large set of passing tests that check the wrong thing.

Key Takeaway: AI changes who drafts Agile tests, not who owns quality, so the team still reviews the plans and tests produced by agents such as the Playwright planner, generator, and healer.