Five Questions With Gil Broza
Perhaps more germane to this blog, however, is that Gil Broza has been working on software for close to two decades and has been XPing and Agileing for much of that time. Regardless of whether you have a financial, bioinformatics, or content delivery system to maintain or to build, Gil can show you, coach you, and help you do so in an Agile and Industrial XP fashion. You may have heard Gil talking at Agile 2008, at DDJ's own SD Best Practices conference, or at one of Industrial Logic's workshops on various XP-related topics.
Here is what Gil has to say:
DDJ: What has most surprised you as you have learned about testing/in your experiences with testing?
GB: While many organizations prefer to hire intelligent, bright, hard-working testers, some companies appear to think that any warm body will do. Even after almost two decades in the software world, this mindset still amazes me. I guess it arises from the concept of the test plan, or from the notion that given a feature's spec and a working build, a person should really just need to "bang on it" for X hours to prove its correctness. As a firm believer in Exploratory Testing and think-once-then-automate, I think testers require careful hiring just like any other role.
DDJ: What do you think is the most important thing for a tester to know? To do? For developers to know and do about testing?
GB: A critical principle in software development, I believe, is the concept that "testing" and "tests" aren't about finding bugs. Rather, they ascertain the software's fitness to the customer's purpose and goals.
As an XP trainer and coach, I teach developers many practices that were considered anathema a decade ago. Not so much the less-than-intuitive notion of test-driven development, but the fact that developers are responsible for low-level testing of *code that they wrote*, and the related fact that such testing must be done in code rather than by banging on the UI. I believe it's critical for developers to engage in these practices so they produce code that is proven to stand on its own two feet (and keep standing on them as time passes). I also believe testers and other customers on a project should hold developers accountable for this testing. Once they are comfortable with these notions, I want developers to know that those tests aren't really just for validation; they should be small, focused specifications of the code's intent. This, to me, is part and parcel of ascertaining the software's suitability to purpose.
DDJ: What do you see as the biggest challenge for testers/the test discipline for the next five years?
GB: Unfortunately, too many testers today are saddled with energy-sapping, boring repetition of verification tasks. They are supposed to follow test plans established months and years ago that keep growing and expanding. That means spending little thought and having little slack to strategize and reconsider options. In many organizations this lowers testers' stature and the expectations from them. Combined with methods that leave testing to the end of a cycle, when inevitably time must be compressed, this is just not a recipe for respect and reliance on testers' true capabilities.
As more organizations become Agile, the role of tester will change. From post-factum verification, it will move upstream to specification; testers will help drive development by storytesting (specifying high-level tests) just before the associated code is written. They will specify more and validate less, thus engaging more of their system-thinking skills. They will automate tests that deserve automation, so they can continue exploring further scenarios. Rather than just discovering defects late in the game, their work will really become Assurance of Quality. The challenge will be for organizations to accept testers' increased significance and contributions, and for testers to accept the new challenges.
DDJ: Going meta (to channel Jerry Weinberg), what else should I ask you? What would you answer?
GB: The question would be: "Given XP's heavy emphasis on test automation, is there still room for testers?"
Yes! Testers on an XP project are considered customers: they help shape the product. That means they partake in writing the stories, composing storytests, and exploratory testing. They constantly analyze and look for gaps and help developers as well as lead customers plug those gaps. There is plenty of brain work for testers.
DDJ: Is there anything else you would like to say?
GB: The average company doesn't employ enough testers.
[See my Table Of Contents post for more details about this interview series.]