Back for another session on the Testing the Limits hot seat is James Bach – one of our most popular guests and one of the most widely recognized figures in testing today. A prolific author, speaker, coach and consultant, James has been disrupting the testing industry since 1987. For more on James’ background, his body of work and his testing philosophy in general, you can check out his blog, website or follow him on Twitter.
In part one of our latest interview, we get his thoughts on his previous life as a developer; how testers should interact with engineers; the biggest waste of time in testing today; the skills that most testers lack and more.
uTest: In a recent lecture you said that you hated being a developer, saying it was like completing 25 crossword puzzles every day (i.e. boring and repetitive). What’s the one piece of advice you would offer to those are who are thinking of making the transition from dev to testing?
JB: I advise: make that transition– but please, study testing as you do.
Testing is not just another programming problem. Yet, too often, a programmer mentality sees testing as just the process of manipulating software. Sometimes, programmers dream of robot armies to do their “testing.” The quest for the clever tool then eclipses the mission of excellent testing. This is a little like trying to invent an android that can talk to your wife so that you don’t have to.
You can use all your tech skills, programmers. It’s fine to write software. But what testing is really about is rapid, deep learning. To do that, you have to get your face, and all the rest of you, right up close to that product. You must wrestle with the product– yes– by hand. Or as we like to say where I come from: you need to do your testing sapiently.
uTest: In that same presentation you also talked about the importance of making friends with developers. Why is the tester-developer relationship so adversarial at times?
JB: I don’t know, why does my wife not like it when I report defects in her? People are strange that way…
Seriously, it’s easy to see the dynamic. Anyone who creates a piece of work and submits it for judgment is going to feel judged. That’s not a pleasant feeling. And the problem is compounded by testers who glibly declare that this or that little nit or nat is a “defect,” as if anything they personally don’t like is a quality problem for everybody. It is further compounded when programmers and testers are separated by large distances or other communication barriers, not to mention the process barriers.
Even though technical people are renowned and sought after for their social skills (I understand United Nations programmers were just about to solve the Arab-Israeli situation a few months ago, had it not been for the need to calm tensions between the Koreas.) testers and developers are people who see the world very differently. It’s a special challenge to relax and smile when a bug report seems to have been ignored.
Personally, I make a set of explicit commitments to any developer I work with on a project. I write them down and deliver them. This seems to help.
uTest: You’ve said many times that belief is a sin for testers – something we assume you’ve learned from experience. Was there anything in particular that led you to this truism? Or was it just years of experience?
JB: It’s not a matter of experience, but reason. Our job is vigilance. To lose vigilance is to abdicate our responsibility. Vigilance, in testing, means being a good skeptic. We must reject certainty in any form. We’re the Knights of May Be. To believe is to cease questioning; to fall asleep at our posts.
I use lots of information. I work hard not to believe it. This is my discipline.
uTest: What’s the biggest waste of time in testing today?