Manage Learn to apply best practices and optimize your operations.

Why Agile should not marginalize software testers

Scott Barber discusses Agile developers' and managers' perceptions of software testing and how the tester's role can change in Agile organizations.

Many software development cultures put testing at the end of the development processes. Some in Agile development want to push testing and testers even further out of the picture, according to software test consultant Scott Barber.

Not only do software testers often feel the pinch of Agile’s short iterations more than any group on development teams, they may also find their roles reduced, said Barber, Chief Technologist of PerfTestPlus, a software consultancy in Palm Bay, Fla.,  and co-author of both Performance Testing Guidance for Web Applications and Beautiful Testing. In this interview, he discusses Agile developers’ and managers’ perceptions of software testing and how the tester’s role can change in Agile organizations.

SSQ: You come in frequently to integrate testing into Agile development. What kind of problems do you see organizations having when integrating testing?

Scott Barber: The first thing that I hear about is, ‘What do we need testers for if we’re doing Agile? Isn’t everyone in Agile a generalist?’

Well, the answer is that if you are really, really good at Agile and all your developers are really good and don’t put any bugs in the code, and your clients are right there on site and doing user acceptance testing pretty much in line, what’s the job of the tester? Yes, maybe you don’t need as many testers in that case; but that’s not often the case.

SSQ: Why not? Why is the idea of development “generalists” flawed?

Barber: Testers have a certain mindset, a drive to help expose things that other people don’t find. That’s what they do. Developers are creators. Testers are explorers. Their job, their whole mindset, is to find the stuff that others don’t.

I’ve always told developers that I want them to deliver something that does what they think it ought to do. Sure, I want it to be pretty stable; but I don’t want developers thinking about every possible thing that can go wrong. A developer could spend literally all their life on trying to harden it against whatever you can think of. But the truth is the person who is going to be using the software isn’t going to be interacting at the same level as the developer. No matter how much time a developer spends trying to figure out what can go wrong, some user is going to try to do something that you never imagined.

So there’s a value in having the tester’s perspective; that of a person who has dedicated an entire career to figuring out what is it that the user is going to do that no one expects them to do, and what’s it going to do to my system. There’s also value in that testing involves business risk mitigation. It shifts focus from minimum requirements to the QA-centric role into a risk exposure mode.

All that said, in Agile you might need fewer testers; maybe you’re replacing some of your testing with your real users, your acceptance test people. That’s not eliminating test. It is changing personnel.

SSQ: How much emphasis can be put on acceptance testing of applications?

Barber: One of the things that I see from folks who push test out of Agile is they get this beautiful elegant code that does exactly what the developers think it ought to do. Then it ends up in front of a user, and at demo level they love it, too. But then they take it to their jobs, out of that sterile environment, and it doesn’t go so well. That is one of my hesitations of over-trusting acceptance test-driven stuff.  I’m not against acceptance testing, I’m just a little hesitant, because until you actually put it in people’s work environment, they don’t realize that they’re using it differently. I can’t say that’s a problem with the process. It’s just a human thing.

SSQ: What is a key way the tester’s role changes in Agile?

Barber: Testers say, “How am I supposed to protect the user when I’m just sitting there collaborating, and we’re doing stuff together? Aren’t I too close?’  Well, yes, but that’s not your whole job anymore. In Agile, it’s no longer the tester’s job to say, “This is no good. It shouldn’t ship.’ Usually, that call is made by the project manager, the product manager or the Scrum Master.

In Agile, the tester’s job to make sure that everything that gets checked in is shippable. Not that the complete product is shippable, but that what’s checked in is shippable. It’s somebody else’s job to say the collection of things we have checked in is product-able.

Until testers are willing to accept that change in role, they’re going to resist the whole thing. The more resistant testers are, the less developers want them on the team. In Agile, successful testers are those who say, ‘It’s my job now to help the developers achieve their vision and keep that vision in sync with the end user’s vision.’

SSQ: In the Agile test scenario you just described, on what do testers focus the most of their energy?

Barber: Agile testers must have a broad enough skill set that they can lend a hand in some other areas, without handholding, at the very early development level. Beyond that, the ones who have enough technical chops to be able to do a little simple unit testing, execute the unit test or read through some code fare well in Agile. But it’s the attitude more than the technical skills that really help.

Read more of the Agile series:

Agile backlash series: Exploring Agile development problems and solutions

Agile development: What’s behind the backlash against Agile?

Five ways to kill Agile development adoption and projects

Agile problem areas that pain developers and testers

Have your experiences with Agile been good, bad or in between? Do you agree or disagree with the statements made in this article? Let us know. Write to us at

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.