BG: It’s just finding their niche of value. I’ll use iContact as an example of my most recent company where I was building an agile team, and part of that was evangelizing testing—the test role. We had different types of testers. We had some testers who were developers in sheep’s clothing; we had a few Java developers who wanted to test and they had twenty years of experience. They were incredibly seasoned developers who were great testers. We had some middle of the road testers who had solid technology chops in our systems and environments with SQL and database skills, networking skills, performance skills, but they couldn’t write code. And then we had a set of folks who I would call good functional, incredibly solid professional testers, but they weren’t comfortable writing scripts. So we had a spectrum. It was about finding the niche in what all of those folks could do.
So the functional testers could have an impact by evangelizing and really leading their teams with exploratory testing. The scripters—and I’m not trying to stereotype these folks—found their niche and were supplementing some of the automation code. There are some tools now that actually enabled them to “write automation.” The middle-tier tools like FitNesse and Cucumber allow non-programmers to “automate.” So it really empowered them. For the developers who were testers, they could now start writing user tests and middle-tier tests.
I think the art is empowering them in their niche. Giving them opportunities, but also connecting them to the customer. All of those testers had the responsibility to solve the right problems; To refine the requirements and user stories and to make sure we were getting acceptance. We had them move to the front of the line instead of being at the back of the line having code thrown in their lap and being gatekeepers. They’re sort of still doing a little bit of that, but they’re really trying to move to the front of the line and make sure they’re solving problems. I don’t think there’s anything more cool, from a tester’s point of view, than working with customers. I don’t know if it gets any better than that. I think what motivates them is being apart of that empowerment.
One of the neat things we did at iContact is that we ran very empowered sprint reviews. I don’t know if you’re familiar with the notion of the sprint review, but it’s the ceremony at the end of the sprint where the team gets up and they show off what they did. And we had a whole team do that. Our testers had a stage every two weeks and everyone in the entire team would say, “All right, show me what you’ve done.” We would not just show features, but we would be showing tests and bugs we found, what activity we would be building into automation, and what performance testing we did. It sort of level set all of the activities across the team. I should stop calling them “testers” versus “developers.” It sort of leveled everything and they became contributors.
JV: What do you look for in a strong candidate for a tester in an agile project?
BG: I think I sort of gave you the answer. I don’t think there’s a stereotype. I think it’s someone who has some strength, either strong professional chops or strong exploratory testing chops, or the ability to interface really well. Maybe someone who has some business analysis in their background and understands requirements analysis and then can translate that into a test case. Or a programmer who has gotten tired of programming. I think it’s an elective mix. I think the common ground is just being engaged and not being complacent. Not waiting around and saying, “Here, just give it to me.” Not waiting for 100 percent requirements to be defined and handed to you. Not waiting for your test plant to be 100 percent defined. You need to really get in the game with the customer. You need to be engaged, inquisitive, thick-skinned, and relentless. I think the soft skills are more important to testers in agile environments than the hard skills are, and I think that’s true of the team in general.