Interview with James Bach: Useful for all Test Engineers

Hi friends,

I found this interview of James Bach on software testing in one blog and felt that it will be useful for all of us and posted in this blog.

James Bach, Co-author of Lessons Learned in Software Testing, is a popular name in the world of testing because of his new and unconventional ideas. Hope that this Interview will be useful for all the testers.

Mallik: Did you have any formal training in software testing ? Were you a developer before moving to testing ? Tell us something about your background and experience.
James Bach: I'm not sure what formal training in software testing would mean. If you mean have I taken testing classes, then the answer is yes, but I didn't consider that to be training, because I already felt that I knew how to test. I've attended bits and pieces of testing training over the years, but mainly I stay away from a classroom setting, because I'm so disruptive. I started as a video game developer after dropping out of school. I moved to testing in 1987 because Apple Computer was hiring testers and I needed a job. Plus, I was intrigued by the idea of testing as a dedicated activity.

Mallik: What is the most interesting bug you have found?
James Bach: I can't say what is the most interesting, but one interesting bug I found was a piece of code X that overwrote part of a second piece of code Y, so that invoking Y sometimes mysteriously invoked the code Z that came right after Y in memory. It took me days to figure that one out, because all the evidence pointed to Z as somehow th culprit, even though it was totally innocent. It taught me how devious and non-linear software can be.

Mallik: Should testers have access to code (under test) or not ? Why ?
James Bach: Testers should have access to any resource that helps them do their job For some testers, in some situations, code can be a valuable resource. My experience is that code often does not help testers much, however, because it's a lot of work to understand.

Mallik: If an organization wants you to interview a candidate for testing position, How would you go about it ?
James Bach: My short answer is that I give them something to test and watch how they test it. Some people who can talk about testing can't do it. Some people who can't talk about testing CAN do it. So I just want to see them do it.

Mallik: Do you think that development/coding skills are essential for a testers ? If its a black box testing then where will they be using it.
James Bach: No I don't think those skills are necessary. But, they are useful. In any high performing test team, I would expect to find at least one programmer. There are three major ways that coding skills help:

• Interviewing programmers.
• Writing test tools.
• Drawing inferences about external behavior based on knowledge of internals.

Mallik: Many organizations associate QA with Process While process is important for everything why is it associated mostly with QA . And do you think that testers are missing out on the primary job of testing and spending too much time on documentation because of process ?
James Bach: First you have to be clear on what you mean by process. Process is a danger word, because it can mean many different things. If you mean, "the way thing happen", then we all are involved in process, even if we don't understand most of the processes by which we work. The aspects of process QA is associated with are process instructions (methods and procedures) or process descriptions (documentation). They are associated with that partly because our craft suffers from terrible ignorance about how highly cognitive processes work. In fact, process instructions and descriptions play a relatively small role, and sometimes no role at
all, in the actual process by which software is created and tested. QA can manipulate the paperwork all they want, but typically they have little impact on the true capability and reliability of the system to produce a good product. QA can however interfere with the process, to make it harder to produce good work. I've seen a lot of that. True QA is project management, project coordination, company management, maintaining close communication with stakeholders, craft-by-craft mentoring, and personal commitment and skill. That true QA because those are the activities that genuinely result in a quality product. But that's not what most QA groups think they are doing, it seems.

Mallik: A tester's main role usually comes into picture too late in the SDLC, and thus, he is expected to compensate for all the slippage that has occured in design as well as development(since the product release deadlines are fixed). Under such constraints, should a tester signoff a product which he himself might not be satisfied with the testing of ?
James Bach: It is not the role of testing to signoff on a product release. The most I would be willing to sign for is that I believe I have provided the necessary information for my clients to make good decisions about the product. If that didn't seem true, then I would not sign.

Mallik: What are your suggestions to the people who wants to come into testing field/budding testers ?
James Bach: I suggest that you test something and try to describe the problems you found and the process you followed. Also, I suggest reading the articles on my site, and viewing Cem Kaner's videos on Google Video.

Mallik: Should a tester restrict to one particular technological domain, and try to achieve expertise or its better to be diverse in testing ?
James Bach: I prefer variety.

Mallik: What must be a tester's approach over the years in order to improve his testing skills ?
James Bach: Pay attention to what happens when you test. Don't just believe what you are told about testing, but rather reinvent and construct the skill for
yourself.

Mallik: How can a fresh college graduate identify, if "testing" is the right profession for him ? I mean, what kind of attitude suits to this profession ?
James Bach:The kind of testing I do rewards people who like to solve puzzles and figure out how machines work. Fast learners. It's the same thing that draws people to programming, but programming requires a longer attention span. I'd rather have a more social activity that involves a lot of short assignments. Testing is like that, for me.

Mallik: How will you differentiate the skills of a tester from that of a programmer ?
James Bach: A tester is a skeptic, a programmer must have faith. Skepticism requires a bigger imagination for what is possible, whereas the programmer must be more able to figure out how to go from what is plausible to what is actual. The programmer must think algorithmically, but for the tester, lateral and logical thinking dominate. Programmers have to focus, but testers need the ability to de-focus. Programmers can be laser-like, whereas testers must shed light in all directions. Programmers and testers both create and use models. Both benefit from technical knowledge, although it is more important for programmers to have that than testers. A tester could be useful even without much technical knowledge, if he has domain knowledge, or quick learning ability. A tester is an applied epistemologist. Epistemology is optional knowledge for programmers.

Mallik: Should a tester also be involved in suggesting solutions for the bugs he has discovered ?
James Bach: Be careful with that. If the tester presumes to act like a designer, that can bruise and confuse the programmer. Having said that, offering ideas is okay, as long as you do so with respect. The testers job is to reveal important information about the product, not to design the product.

Mallik:I believe you have delivered some courses in India too, what is your experience of indian testers ?
James Bach: The 60 testers I had the pleasure of teaching were mostly younger than the ones I teach in the U.S. Once I convinced them that I wanted them to speak up and show me their thinking, I got a very positive and impressive response. I had come to India thinking that your culture is possibly not amenable to independent thinking, but I believe I was wrong about that. I came away with the sense that the testers I was teaching shared a culture of trying to please their clients. You can think independently, even though you wish to please your customers. Pradeep Soundararajan and Shrini Kulkarni are two Indian testers who are becoming well known in America with their original and incisive ideas. They are making a good showing on behalf of the Indian testing community, but Ihope that others also share their thoughts.

Mallik: Some books you would like to recommend to sharpen thinking in general, in order to be a better tester ?
James Bach:

· Introduction to General Systems Thinking, by Weinberg

· Lateral Thinking, by de Bono

· Tools for Critical Thinking, by Levy

· Godel, Escher, Bach, by Hofstaedter

Mallik: Amidst the sheer lack of good books of testing, can we expect some more good books from you ?
James Bach:I'm working on a book on Exploratory Testing.