Five Questions With James Bach

James Bach has been testing for longer than I've been out of high school. After a few years of programming he decided that testing was much more interesting and has been having fun with that ever since. You might know him as the co-author of Lessons Learned In Software Testing: A Context-Driven Approach. Or as a proponent of Rapid Software Testing. Probably you don't know him as Richard Bach's son. Here's what James has to say:

DDJ: What has most surprised you as you have learned about testing / in your experiences with testing?
JB: There are many things that surprise me. I can't choose just one.

Since testing is primarily a process of thinking and imagining, it surprises me that most authors of testing textbooks and standards have so little education and insight about the workings of the human mind. There is so much information available on this subject!

Since written test procedures cost so much and have so little value as instruments of bug finding, it surprises me that almost the entire testing industry accepts without question that most tests should be written down in procedural form.

DDJ: What is the most interesting bug you have seen?
JB: A bug is interesting when it teaches me something. Many years ago, when I was 15, I wrote my first program for money. It was a program to graph stock prices. One particular line of Applesoft Basic contained the statement "N0=0", which simply created a variable called "N0" and sets it to a value of zero. However, when that line was executed, the entire contents of the graphics screen shifted an inch to the right. I was gobsmacked! I knew there was no function in my code that could cause that effect. In fact, there was no function of that sort anywhere on the Apple II computer. It took me five days to find the culprit: I had carelessly created an array that spanned the entire graphics screen memory. When I defined the new variable "N0", Applesoft needed to make space for the floating point value and had to shift the position of the big array up in memory by several bytes. This caused all the graphics on the screen to shift at once. It also explained why filling up the array had been causing garbage to appear on the screen (a bug I had ignored as too small to worry about).

I learned several things from the bug. I think the most important lesson was simply that the connection between cause and effect in a computer can be so obscure and complex that we just can't ever be certain that we know what we are looking at when we look at a running program. Of course, since then, computers and software have only become many orders of magnitude more complex.

DDJ: How would you describe your testing philosophy?
JB: I would say I have a comprehensive philosophy of testing, and that Jerry Weinberg, more than any other single person, taught me that philosophy. If I had to point to one book that best expresses my philosophy of testing, it would be Jerry's book Introduction to General Systems Thinking. Yet Jerry, when you interviewed him, says he has no philosophy.

Jerry said that philosophy is the love of knowledge. I agree, but testing is *how* I love knowledge. The practice of testing is therefore the practice of philosophy. The name my community gives itself is the Context-Driven school of testing.

My particular approach to testing is to consider it to be a problem of humans penetrating the illusions of complex systems in the service of other humans. I solve that problem. It's a matter of skill supported by heuristics and tools.

DDJ: Is there something which is typically emphasized as important regarding testing that you think can be ignored, is unimportant?
JB: Instead of "expected results", I find it more useful to think of reasonable results.

Instead of "test cases", I find it more useful to think about test ideas and test activities.

Instead of "black box" or "white box" testing, I just say testing.

Instead of insisting on "requirements" or "specifications", I just insist on negotiating a mission of testing that I believe I can fulfill. I might not need any special information to fulfill that mission.

I think that the ISEB and ISTQB certification programs are an embarrassment. I hope no one pays attention to them. Actually, I don't know of any tester certification program that is worthy of respect.

DDJ: What do you see as the biggest challenge for testers/the test discipline for the next five years?
JB: 1. To learn how to test. Most testers, in my experience, seem to have little idea how to do it.

2. To learn how to coach testers. We need better ways to systematically train each other.

3. To reject the false prophets of certification. Bad certification programs cheapen our craft.