Making the Switch to Agile Testing

Done Means DONE!

The challenge is not because the testers are too slow, but because the team cannot own "done," and until the team owns "done" and contributes to accomplishing it, the testers will look too sluggish. In every iteration, agile teams can deliver a functional product. They are not obligated to release, but the software is expected to be of sufficient quality. That indicates the testing, which is about risk management, is over. After all, how can you release if you don't know the risks?

Testing provides knowledge about the product being tested. The tests do not establish that the product is perfect or that the engineers are excellent or bad, but instead that the product either does or does not accomplish what we expected to accomplish. This implies that the testing must be consistent with the product. If the product features a graphical user interface, the testing will have to use it at some point. However, there are several strategies for testing inside a system. The approach to test from within the GUI is to develop the tests as you go, so you don't have to test from beginning to end and still get relevant information on the product under test.

If programmers just test at the unit level, they have no idea if a component is complete. If the testers cannot complete the testing from a system-level perspective, they do not know if a feature is functional. How, then, can you consider an iteration done if no one knows if a functionality is ready? You simply cannot. That is why having a collaborative definition of done is crucial. Is a story complete once the developers have tested it? Is a narrative complete once it has been integrated and built into an executable by the developers? What about the setup? How much testing does a feature require to determine whether or not it is complete?

For example, Scrum Master interview questions often probe how teams address the definition of done and ensure all members contribute effectively.

There is no unique correct solution for every team. So, every team must evaluate its product, consumers, and challenges and reach a conclusion, "OK, we can say it's done if: all of the code has been checked in, reviewed by someone, or written in pairs; all of the developer tests have been completed; and all of the system tests for this feature have been created and run under the GUI. Every few days, we'll handle GUI-based checking, but we won't test using the GUI."

I'm not sure whether that's an acceptable definition of done for your business. It would help if you considered the consequences of not doing periodic GUI testing on your product. Perhaps you don't have a graphical user interface for your product, but you do have a database. Do the developer tests require database access? Perhaps, perhaps not. Does the testing process require access permission? I'd assume so, but maybe you have a product I'm not familiar with, and maybe they don't really have to all the time. Perhaps additional automated tests that test db updates or migrations before anything else are required. "Done" is determined by your product and its risks. Consider the consequences of launching a product without various types of testing, and then you'll understand what you require in an iteration to achieve a release-ready product.

Write the definition of done as a pipeline gate, not as a page on a wiki. A rule that only lives in a document gets skipped under deadline pressure, while the same rule encoded as a required check on the pull request cannot be skipped. Map each item in your definition of done to a specific automated check: the unit tests pass, the build produces a deployable artifact, the system tests for that story run green, and coverage on the changed files does not drop. Anything you cannot encode, such as an exploratory testing session, gets a named owner and a checkbox on the story instead of a vague team promise.

Key Takeaway: Agile teams should agree the definition of done together and encode each item as a required automated check, because a definition of done that lives only on a wiki page gets skipped under deadline pressure.

Give a Mouse a Cookie

Once you've determined what you anticipate in an iteration, you'll most likely require testing. Then you'll run into the "Give a Mouse a Cookie" scenario. In a charming child's book that bears the same name, if you give a mouse a cookie, he wants a glass of milk to go with it. Then he'll need a rag to wipe the milk from his lips and a broom to sweep the crumbs off the ground. The need for more and more continues until the mouse becomes exhausted and desires another cookie, which restarts the cycle.

This is what emerges when a testing team seeks the "ultimate" test framework for their product. It's an understandable desire. Unfortunately, you don't always know what the ideal structure is until the project is finished. If you wait until the product is finished, testing will be included towards the end of the project, which is too little, too late.

Rather than building a flawless test framework, consider creating a just-good-enough test framework, for the time being, to refactor it as you go. This gives the testing team enough automation to get started, as well as growing familiarity with the automation as the iteration and project progress. It does not bind you to a framework that no longer serves you because you have invested so much money and time in designing it.

Bear in mind that testers are similar to consumers. Just as your product's consumers can't necessarily tell what they want or need until they see it, testers can't always tell what test automation framework they desire or require until they begin using it.

A just-good-enough framework still needs two rules from the first day: a quarantine rule and a triage rule. A test that fails intermittently teaches the team to ignore red builds, and once the team ignores red builds, the definition of done stops meaning anything. Move a flaky test out of the blocking suite as soon as you spot it, file it against a named owner, and give it a deadline to be fixed or deleted. This matters more now that teams generate large parts of a suite from recorded flows and models, because a suite can grow faster than the team can maintain it.

Key Takeaway: Building a just-good-enough test framework and refactoring it as the project moves lets testing start in the first iteration, because the ideal test framework is only clear once the product is finished.

How Do You Decide Which Tests an Iteration Actually Needs?

Use the agile testing quadrants to sort the work before the iteration starts. The model puts every test on two axes: business-facing against technology-facing, and tests that guide development against tests that critique the product. Brian Marick created the original matrix, and Janet Gregory and Lisa Crispin developed it into the version teams use today. Crispin describes the quadrants as a thinking tool that helps teams plan and execute testing activities, not a checklist to complete.

Quadrant one holds technology-facing tests that guide development, such as unit and component tests. Quadrant two holds business-facing tests that guide development, such as story and functional tests written from worked examples. Quadrant three holds business-facing tests that critique the built product, such as exploratory sessions and user acceptance testing. Quadrant four holds technology-facing tests that critique the product, such as performance, load and security tests. Hold your definition of done up against those four boxes and the gap shows up fast. A team that has only quadrant one covered knows the code compiles and passes its own assertions. It does not know whether the feature does what the customer asked for.

The numbers are labels, not a running order. Crispin is explicit that the quadrant numbering system does not imply any order and that you do not work through the quadrants from one to four in waterfall style. She recommends walking through them during release, theme and iteration planning so the whole team starts by thinking about testing first. Do this per story rather than per release. Many stories need nothing from quadrant four. A story that touches an authentication path or a bulk query needs quadrant four in the same iteration it ships, not in a hardening sprint booked after the release date is already set.

Key Takeaway: Walking each story through the four agile testing quadrants shows which tests that story needs, and the quadrant numbers are labels rather than a running order.

"Done" is the result of a collaborative effort

What does the test squad "sustain" with development when you need to comprehend what "done" means and you construct a just-good-enough framework for testing? By ensuring that the whole team works on a story until it is finished.

Assume you have a story that calls for two programmers and one tester. The feature is created collaboratively by the developers. Simultaneously, the tester reshapes the tests, adds sufficient automation, or integrates the test into the current automation framework. But what if you're shifting to agile and don't have a framework? Then, one (or even more) of the programmers collaborates with the tester to build a suitable framework and integrate the tests for this functionality into it. No law says programmers cannot assist testers in establishing test frameworks, writing test frameworks, or even writing tests to facilitate the completion of a story. Given that you have a team definition of "done," doesn't it make sense for team members to assist one another in getting things done?

Key Takeaway: Programmers helping a tester build the framework and write the tests for a story is a normal way for a team to finish that story inside one iteration.

How Does AI-Generated Code Change Agile Testing in 2026?

AI-generated code moves the bottleneck from writing tests to verifying them, so your definition of done now has to record who read each test. In the State of AI-Generated Code survey, 65 percent of quality assurance practitioners said their development teams actively use AI to generate code, with another 16 percent doing so occasionally. The same survey reports that 58 percent saw their testing workload rise as a result, and that practitioners rated their trust in AI-generated code at 3.16 out of 5.

That changes what the agile testing quadrants have to carry. The original model assumed a person wrote and understood every test. One proposal adds a third axis for test provenance, which splits tests into three groups: human-authored and reviewed, AI-authored and human-verified, and AI-authored and unverified. You do not have to redraw the model to use the idea. Tag generated tests in your suite and keep the unverified ones out of the blocking pipeline until someone has read them.

The limitation is specific. A generated test can pass continuous integration while asserting the wrong behavior, because it was written from the code rather than from what the customer asked for. A green build does not tell you which of the two you have, so a coverage percentage on its own stops being evidence that a story is done. Add one line to your definition of done: every test that gates a merge has been read by a person who can say what it proves. That keeps the whole-team ownership described earlier intact while the number of tests goes up.

Key Takeaway: AI-generated tests make test provenance part of the definition of done, because a generated test can pass continuous integration while asserting the wrong behavior.

Closing

Once you understand what "done" means for a story and the entire team is committed to completing it, you can build a culture where the testing process can convert to agile. The cross-functional project team may move to agile as long as the programmers help with testing frameworks, the business analysts help with narrative refinement, and the testers help deliver data on the product under test.

Switching to an agile methodology involves the entire project team, not just the programmers. If you have testers that can't "catch pace," it's not the responsibility of the testers. It is a problem for the whole team. You need to resolve the issue with the team, change their mindset let them see the benefit of going in this direction. Even if you start with mediocre test frameworks, you can modify them into something spectacular over time, it's up to you.