From SearchSoftwareQuality.com:

Agile backlash series: Exploring Agile development problems and solutions

 I think Jan Stafford did a great job on this series.  I don’t agree with every opinion from everyone interviewed, but I wouldn’t expect to.  I think it’s fair, honest, insightful, and (best of all) focuses on experiences, challenges, and ideas about overcoming challenges instead of theory, marketing fluff, and excessive exaggeration.  🙂

Of course, I’m always happy when someone is willing to publish quotes of mine like the following excerpts from Why Agile should not marginalize software testers:

“SSQ: You come in frequently to integrate testing into Agile development. What kind ofproblems 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’redoing 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 arereally good and don’t put any bugs in the code, and your clients are right there on site and doinguser acceptance testing pretty much in line, what’s the job of the tester? Yes, maybe you don’tneed 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 peopledon’t find. That’s what they do. Developers are creators. Testers are explorers. Their job, theirwhole 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 itought to do. Sure, I want it to be pretty stable; but I don’t want developers thinking about everypossible thing that can go wrong…

So there’s a value in having the tester’s perspective; that of a person who has dedicated anentire career to figuring out what is it that the user is going to do that no one expects them todo, and what’s it going to do to my system. There’s also value in that testing involves businessrisk mitigation….

…in Agile you might need fewer testers; maybe you’re replacing some of yourtesting with your real users, your acceptance test people. That’s not eliminating test. It ischanging personnel.

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

Barber:  …one of my hesitations ofover-trusting acceptance test-driven stuff.  I’m not against acceptance testing, I’m just alittle hesitant, because until you actually put it in people’s work environment, they don’t realizethat they’re using it differently. I can’t say that’s a problem with the process. It’s just a humanthing.

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 therecollaborating, and we’re doing stuff together? Aren’t I too close?’  Well, yes, but that’s notyour whole job anymore. In Agile, it’s no longer the tester’s job to say, “This is no good. Itshouldn’t ship.’…

In Agile, the tester’s job to make sure that everything that gets checked in is shippable…

Until testers are willing to accept that change in role, they’re going to resist the wholething. 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 visionand keep that vision in sync with the end user’s vision.’

…[testers]who have enough technical chops to be able to do a little simple unit testing, execute the unittest or read through some code fare well in Agile. But it’s the attitude more than the technicalskills that really help.”

Seriously though, read the whole series, it’s worth it.
 
—
Scott Barber
Chief Technologist, PerfTestPlus, Inc.
About.me

Co-Author, Performance Testing Guidance for Web Applications
Author, Web Load Testing for Dummies
Contributing Author, Beautiful Testing, and How To Reduce the Cost of Testing

“If you can see it in your mind…
     you will find it in your life.”