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 of problems do you see organizations having when integrating testing?Seriously though, read the whole series, it's worth it.
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...
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....
...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 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.’...
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 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.’
...[testers] 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."
--
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."
No comments:
Post a Comment