What Agile Testing (Actually) Is

So, now that the first installment of this two fold article has been published (hence you might have an idea of what Agile Testing is not in my opinion), I’ve started feeling the pressure to explain what Agile Testing actually means to me.

Disclosure: in order to do that, I’ll make the most of my practical experience as a tester in the most Agile environment I’ve ever been part of so far.

Before I do that, though, let me give you a practical tip to recognize a really Agile team: look at their task board.(1)

Does it have just three columns (To Do, In Progress, Done)? Chances are they are able to perform Agile Testing.

Is there also another clearly inconsistent column, likely misnamed QA, in the middle? If so, I’d bet neither they get what Agile really means nor are they familiar with efficient/deep/meaningful/genuine software testing.

By the way, I said clearly inconsistent because expressions like “To Do”, “In Progress” and “Done” indicate the status of a task, whereas “QA” (a term which I wouldn’t use anyway: at most, I would call it “Testing”) is a type of task.

So, unless were the other columns named “Business Analysis”, “Programming”, “Deploying”, for instance, that “QA” column wouldn’t make sense at all.

On the other hand, should these other columns exist, they would be a clear indication that the corresponding team is not Agile at all, since they would be still thinking in a serial way, or doing things one after the other.

So, what makes a team to be Agile?

To me, their ability to think/work in parallel, which means being able, among other things, to perform testing at the same time as programming.

Wait, is this possible? —I’m hearing you asking.

Of course it is!

After all, if it was possible, several years ago, for the company (developing software for medical devices under a strictly regulated environment) I was working for at the time, it should be virtually possible for almost every organization in the software industry.

Nevertheless, as I learned afterwards, when I started seeing that weird QA column in the middle of so many task boards, it’s not so common to bump into software teams which really understand/master Agile or Testing, let alone proficiently practice Agile Testing.

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.

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.

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).



Ileana Belfiore

Ileana likes to define herself as a Quality obsessed and Agile enthusiast professional. Born and raised in Italy, currently based in Spain, along her career in IT (first as a CRM analyst/programmer and later on as a software testing specialist and Agile consultant), she has developed a deep understanding of different sectors and products. She currently serves as a freelance hands-on software testing specialist and as a blogger.

See author's profile