What Agile Testing Actually Is and How It Works

Why is that?

Well, basically because most people still believe that software testing is limited to verifying that something does what it is expected to do, and, to make matters worse, that it can be performed only once the feature or system in question has been completely built. Those two beliefs are the misconceptions I covered in the first part of this article, on what agile testing is not.

In other words, they are not familiar with challenging assumptions (requirements, software design, people's beliefs, etc.) while, or even before, implementing a feature/system.

And also because they are too often not aware of the power of exploring a system regardless of its status of readiness. And yes, software testing (and especially exploratory testing) can be performed at any stage.

So, back to the most Agile environment I've been part of, our board had just three columns, under which we could see a lot of simultaneous tasks related to a given feature (risk analysis, implementation, code review, exploratory testing, writing test cases, executing test cases, etc.(2)).

At the beginning of each iteration, under the To Do column, we would see the features we were about to work on.(3)

During the iteration, most of the features would appear under the In Progress column, and they wouldn't reach the last (Done) column until all the corresponding tasks were completed.

Can you see the difference between this (ideal) set-up and the (unfortunately too common) scenario where testing duties (if any) start only after programming activities have (allegedly) finished?

In that ideal (yet real) work environment, the potential problems spotted by the testers would be immediately shown to the programmers who would usually fix them as soon as possible through the same iteration.

By the way, there was no need to add them to the onerous defect management system: most of the time, a note for the programmers would be enough.(4)

And since we all were working on the same things at the same time, we were a lot more efficient than before (when we used to follow a traditional waterfall process), basically because during an iteration:

• nobody got distracted (to fix something, for example) while already working on something else, since we were still working on the same thing(s);
• nobody could forget what they implemented, tested or fixed, or how they do that, since we were still working on it;
• last but not least, everybody had a better understanding of what we were doing and why.

Removing that column takes more than deleting it from the board. Replace the handover with three agreements: acceptance criteria written as concrete examples during refinement, a definition of done that names the testing work such as risk analysis and exploratory charters, and a work in progress limit on the In Progress column. The limit matters most, because it forces the team to finish one feature together before pulling the next one.

The same point applies to teams that now draft code with AI assistants. A generated change can reach the branch in minutes, so a testing stage that starts only after implementation falls behind on every story. Test the assumptions while the code is written instead: review the acceptance criteria with the person driving the assistant, explore the running build while the branch is still open, and treat generated tests as claims to check rather than proof that the feature works.

Key Takeaway: Teams keep a separate testing stage because they assume a feature must be finished before testing can start, yet risk analysis, code review and exploratory testing can run against software at any stage of readiness.

To sum up, as I see it, Agile is mainly about simultaneity or efficiently doing things as much in parallel as possible.

As a consequence, to me, Agile Testing is essentially what you do when you don't have that inconsistent and disturbing QA column within your board.

So, how about trying to get rid of it once and for all?

Footnotes

1- For the purpose of this paper, it doesn't really matter if they call it Kanban board, Scrum board, or in whatever other way. What matters is how it looks.

2- Yes, since it was a regulated environment, we had to do that too, which didn't prevent us from performing a lot of exploratory testing, though.

3- It is worth mentioning that, at this point, we would have already analyzed and talked together about these features during the corresponding refinement session(s), usually a few days/weeks before.

4- Only if the bug could not be fixed during the same iteration, we would need to resort to the red tape (that is to say, to the tedious defect tracking tool).