TLDR; What is Agile Testing? Why… that would be testing in Agile projects and adapting to meet the needs of the team.
I have started going through my “The Evil Tester’s (mini) Guide to Agile Testing” and answering the questions in a more indepth fashion, and the first is “What is Agile Testing?”
MindMap to support the answer
Answer in a Video
Notes
These are summary notes. There is more in the video than I cover here
When we are working on an Agile project we need to have a massive amount of flexibility and tailoring of what we do.
One thing that Agile testing is not. Is a noun.
So when we say “what is Agile testing?”. It’s not thing. it’s not… You can’t buy a bunch of Agile testing, what it is… it’s a verb, it’s an approach, it’s a process.
It is how we test on an Agile project.
It’s the stuff we do, and the way we think. But it’s on an Agile project.
Now it seems kind of tautological, that seems obvious, but for some reason people make it hard and it’s not a new thing, as we’re going to find out.
People get hung up on the words. And they get hung up on the words because they don’t really understand what the words meant before. They didn’t really understand what testing meant before. So Agile testing seems like it’s a new thing.
With Agile we don’t necessarily know what we’re going to do in advance.
We’re going to adapt. We’re going to prioritize some functionality above other functionality and the test approach has to compensate for that. Which makes it unique.
It’s unique for the environment that we’re working in, the particular company. Or the organization; and it might be different in each department in that organization. And it might be different on each team in that organization. And sometimes it’s different for each team member.
The more coherent and consistent an Agile process is, the better it works. So hopefully every team member has the same view but sometimes they don’t.
The test process is not a separate “in parallel” process that we can outsource and offshore, it is a process that merges very tightly with the programming approach.
Because what we’ve got is we’ve got a software development approach.
One part of that software development approach is Programming.
One part of that a software development approach is Testing.
They merge together to get an effective Agile Development Process.
We might have a lot of processes in our normal programming process that mitigate risk (TDD, ATDD).
Therefore the test approach changes because it’s a different risk profile.
The risk is going to be in different places in the system so we test differently to try and accommodate that.
A tester hopefully can test better than other people; and can test differently than other people. So we want to use those skills appropriately on the project so that they’re not just spending their time covering very basic acceptance criteria.
Because pretty much anyone can cover basic acceptance criteria.
The risk profile of the project changes as it goes forward. When it starts, we accept a lot of risk because we’re trying to create something as a Minimum Viable Product to get something out, to validate some assumptions to make sure we’re on the right track, to fully flush out the kind of needs that their users have. But later on we want to make it more robust, we’re not as accepting of issues when the system is live.
As the team learns to work together knowledge transfer takes place. Programmers learn how to test better because they’re working with the testers. Therefore the amount of testing work that the programmers can do changes over time. The test approach changes and adapts.
Agile Testing is not really different in the fundamentals of testing. What is different is that we’ve come to associate testing with a lot of process, with a lot of trappings, with a lot of paraphernalia. A lot of extras.
These extras are a response to a development process that required them because it was doing a lot of things in advance. And testing is very often a response to the development process.
There’s a much greater requirement for verbal communication, for taking responsibility for pointing out risks and problems at the time that they happen.
We don’t need a lot of documentation.
That doesn’t mean we don’t do any.
Trying to write things down is still important.
But it doesn’t mean we need a test management tool, we can use whatever tools that were using to track our project.
We need to understand testing and that’s why we’ve had a problem with Agile testing. Simply because people haven’t understood testing. So they’ve tried to carry forward all the stuff that they did on a traditional waterfall project: all the templates, all the processes. Because they don’t really understand testing.
None of that was testing.
We need to understand the essence of testing.
Essentially with an Agile process: were making this up as we go along. And what that means is we’re responding to the needs and changes in the environment based on our experience, and lessons learned from other people: from things that we see in the world, from conference talks, from articles. We’re pulling all this in. We’re doing experiments. We’re seeing what works.
Whilst it sounds like “make it up as you go along” is a bad thing. We’re making it up as we go along because we are heavily invested in studying other areas that work, that deal with complex dynamic systems, and we learn from those.
Testing has never been about the tester.
Testing has always been about the process that we use, the approach that we take, and the results that we get back. And Agile in particular isn’t about “a tester does the testing”.
It is about “testing as a verb”, a process on the project. And if testers hold that close and say “we do the testing!”. You are not harnessing the flexibility and freedom that you can have on an an Agile project.
You don’t come into Agile and go “right we’re an Agile project now, we do a test strategy, one-page test strategy because it’s Agile, and our process is…” It evolves. It changes based on the needs of the project, based on the skill sets of the people there, based on the current set dynamics, and we expect those to change.
We can only succeed on Agile by understanding and harnessing the essence of testing, and that’s what we as testers have to learn. That’s the value that we add in Agile projects - the essence of testing. And sometimes we’re the only people that can implement that until we teach other people how to do it properly.
