Interview with Michael Bolton [2nd Interview] @MichaelBolton
This interview was published in our January 2014 Edition.
Michael Bolton
Organization: DevelopSense
Current Role/Designation: Consulting Software Tester; Testing Teacher
Location: Toronto, Canada
Michael Bolton is a consulting software tester and testing teacher who helps people to solve testing problems that they didn’t realize they could solve. He is the co-author (with senior author James Bach) of Rapid Software Testing, a course that presents a methodology and mindset for testing software expertly and credibly in uncertain conditions and under extreme time pressure. Michael has 25 years of experience testing, developing, managing, and writing about software. Currently, he leads DevelopSense, a Toronto-based consultancy. Prior to that, he was with Quarterdeck Corporation for eight years, during which he managed the company’s flagship products and directed project and testing teams both in-house and around the world.
* Interviewed by Jay Philips
1. Tell us about your journey to becoming a software tester. How did it start and how this has been so far? Was it planned or by accident?
Life is the outcome of exploratory processes. In my life I’ve been an actor, dishwasher, barista, book-keeper, bartender, waiter, restaurant manager, lighting designer, theatre stage manager, stagehand, dresser (working in theatre wardrobe), data entry clerk, computer hardware and software reviewer, technical trainer, database programmer, technical support rep, tester, sales support rep, support manager, test coordinator, test manager, program manager, maintenance programmer, development manager, testing consultant, technical writer, course designer, documentation writer, technical trainer, magazine columnist, technical trainer, consulting software tester, co-author of Rapid Software Testing. And husband, and parent.
2. When did you realize your passion was software testing?
Somewhere in there, as I dimly recall.
As I said above, life is an exploratory process. My natural curiosity and my desire to understand things involved testing. My development work involved testing; my support work involved testing. In 1994, I took my first position called “tester”, at Quarterdeck. I worked with a group of very smart and very passionate people—both testers and programmers. The job was challenging and fun from the start— lots of new learning every day. In 1996, I met Cem Kaner, who was inspiring and helped introduce me to the wider testing community. In 1999 or so, Ross Collard asked me to help him teach his course. In 2001, I attended my first software testing conference, where I met Kent Beck, Elisabeth Hendrickson, Brian Lawrence, John Musa, and most importantly James Bach. In 2003, James and I began collaborating more closely. So the passion started early, and continued to grow over time.
3. Do you regret being associated with software testing today? Given a chance would you move from testing to any other field in IT?
I have no regrets that are strong enough to move away from testing. If I had strong regrets, I’d do it.
4. You co-authored the Rapid Software Testing course. What made you want to create this course?
I didn’t. The course was already up and running when James asked me to work with him. At the time, he felt he was in a kind of drought with respect to creating exercises for the class. I added some perspective and built on some of his existing exercises, and I had a couple of notions of my own. I was pretty good at taking ideas that James was skeptical about or had abandoned completely, and I’d play with them until he figured out how to polish them into really interesting testing problems. The dice game started that way. The pattern program did too. Sometimes we would take the same exercise and teach it in quite different ways, compare notes, and come up with something that was better than either of our approaches. It really has been a remarkably productive collaboration.
5. Do you see more people taking the Rapid Software Testing course over the Rapid Software Testing for Managers? Why or why not?
More people take Rapid Software Testing, presumably because fewer people are managers. There’s another problem though: in general, managers seem to be the people least likely to attend classes. Maybe that’s because they went through terrible testing classes earlier in their careers. Now that we’re talking about RSTM more explicitly, more people are interested; and people who took the RST class years ago are moving into more senior positions.
6. You co-founded the Toronto Workshop on Software Testing. Can you briefly tell us about some of the challenges you had creating the workshop?
With respect to creating the workshop, I can describe the challenges very briefly, because there weren’t any, really. Fiona Charles and I decided that we wanted to get a bunch of people together to talk about testing for a couple of days, loosely based on the LAWST peer conference model that I was familiar with thanks to Cem Kaner and his communities. We picked the weekend, found a room, and invited a bunch of our colleagues to show up. Fiona has mostly taken the lead in content ownership, especially in recent years, and I’ve taken the lead on logistics (though I missed the workshop entirely this year). To make it even easier on me, for several of the workshops, Autodesk has generously donated space for the conversations, and since everybody who participates is eager to contribute, it’s been very low-stress.
7. Are you planning on creating any more workshops, communities or meetups? If so, where?
I have no immediate plans for creating anything new. I spent the better part of last year as program chair for the EuroSTAR conference, so that kept me busy along with my training and consulting work. I’m delighted to see that there are plenty of people creating workshops and communities and meet ups all over the world, and I’m happy to help people with hints and suggestions at least. If I’m in the neighbourhood at the time, I’m usually happy to accept invitations, too.
8. We know about your opinion on ISTQB. What is your opinion about other certification exams such as Tools certification or Project Management certification?
Certification is really about the delegation of trust and respect. If you trust and respect the organization that is promoting the certification, and their methods, and the form of scrutiny that they undertake, then it’s reasonable to have some level of trust for the people that they certify. But let me suggest this: some of the worst (and worst-tested) software you’ve ever used has undergone more scrutiny than certain “certified” testers have.
I like the Agile Alliance’s position paper on certification (http://www.agilealliance.org/news/agile-certification-a-position-statement/) The core of it is that “employers should have confidence only in certifications that are skill-based and difficult to achieve”. I also generally agree that “employers should not require certification of employees,” but I can also see contexts in which it’s reasonable for an employer to require certain kinds of difficult-to-achieve, skill-based certification.
I’ve heard a story about a certain network engineering certification. They give the candidate a broken router to fix, and they watch closely as the candidate fixes it. The examiners make their evaluations based on what they observe. Whether the candidate succeeds or fails in fixing the router isn’t a big deal. They focus on how the candidate behaves. If the candidate gets lucky and fixes the router without demonstrating thoughtfulness and skill, the candidate doesn’t get the certification. On the other hand, a candidate who is thoughtful and skillful will get the certification even if they might have been unable to fix the router in the time available. To use our parlance, this certification tests the candidate instead of checking him or her. Now, that’s a kind of certification that I could support. I hope that the story is true.
9. What will you suggest to people who want to join IT industry as software testers?
For a tester at any stage, it’s critically important to learn, learn, learn. By all means immerse yourself in the technologies and tools that are all around you. Ask questions and practice using the tools. Technical skills are important, but lots of people in the software business have those. I would urge new testers to study and practice the skills that are sometimes in shorter supply: critical thinking, systems thinking, scientific thinking, test framing, argumentation, storytelling, mathematics, statistics, interviewing… Yes, that’s a lot. Pick something and dive in. When you have to come up for air, take a breath and dive back in—or pick something else for a while and come back later, if you like.
Lots of testing books have stuff on equivalence classes and boundary conditions and test cases. Very few have material on how to avoid getting fooled (Perfect Software And Other Illusions About Testing by Jerry Weinberg and Lessons Learned in Software Testing by Kaner, Bach, and Pettichord are my favourite exceptions; there are a few others). What’s more important, I think, is to read books from outside of testing, strictly speaking, and bring those ideas in. Here are only three examples: How Doctors Think (Groopman); Thinking Fast and Slow (Kahneman), and The Black Swan (Taleb). There are tons of others, from all kinds of different domains. One more: How to Use Your Eyes (Elkins), which is about the visual appreciation of everything from art to X-rays to culverts underneath roadways.
10. According to you, what is lacking in today’s commercialized software testing industry, especially in test management?
Oh, heavens, there’s so much. Today, for me, it’s the understanding that testing is about investigating a product, and that test cases are a narrowly focused and weak way to do that. Tomorrow, I’ll be despairing about the emphasis on the formal and explicit over the informal and the tacit. The next day, I’ll be concerned about the oversimplification of our models of human and technological systems alike, and the risk of being misled by over-reliance on oversimplified models.
11. What has been your biggest challenge in software testing? How did you overcome it?
People, but especially people in middle management positions, seem to have profound misconceptions about what testing is, and about what testing can and cannot do. Testing does not assure quality; testing helps us to discover things about the product so that the people responsible for quality—designers, programmers, managers—can assure quality. Only a fraction of testing is about checking to confirm that the product works; the bigger picture is that testing is about investigation and experimentation and discovery and learning, to help our clients understand whether the product they’ve got is the product they want. Testers are not judges or jurors or executioners or cops; testers are more like investigative reporters or skilled lab researchers. People—especially people who do not understand testing and who do not observe the work—seem all too eager to make testing prematurely or unnecessarily formal and explicit. They pay far too little attention, in my view, to the informal and to tacit knowledge and skill. Technical skills are important, but technical skills are useless—even harmful sometimes—unless they are built on a solid base of critical thinking, skepticism, and focus on risk. Conveying all that stuff to the wider testing and development community is my biggest challenge, and my colleagues and I are still working on overcoming it. It’s a pretty hard problem, not least because the misconceptions seem to be rooted into the software business like a thicket of bamboo; new silly ideas about testing keep springing up despite all our efforts to weed and dig them out.
12. What qualities will you look for in a candidate when you want to recruit someone for software testing job?
Engagement. Curiosity. Skepticism—professional uncertainty. The capacity to write and speak clearly, concisely, and precisely. The capacity to learn rapidly. An ability to see both obvious and subtle relationships between things. An ability to see things from a number of different angles—something that usually gives rise to a sense of humour. Bravery to stand up to possibly intimidating technologies and possibly intimidating people. Compassion for programmers and managers, whose jobs are far more difficult than many testers seem to think.
13. Assume you had all the powers in the world, what would you have changed in the world, especially in software testing domain?
I really don’t like questions like this very much. What would you do if you could turn dogs into diamonds? Or dirt bikes? But I must admit, I’d really like people to be more careful about saying what they mean, and meaning what they say. We get into terrible problems and disagreements when people express themselves carelessly. Or dishonestly—but I think carelessness is far more common.
14. Name few people you would like to thank, people who helped you directly or indirectly in your career as a software testing professional.
There are so many people that have helped me that it would take too many pages in the magazine for efficient downloads. Every time I refer to someone else in my work, I’m doing that implicitly. Here, let me explicitly thank James Bach, Cem Kaner, Jerry Weinberg, Ross Collard, Fiona Charles. But you’ve inspired me to resolve to thank more people more explicitly. And I’d like to thank you for honouring me with an interview request.
15. One last question – Do you read Testing Circus Magazine? If yes, what is your feedback to improve this magazine?
I don’t read the magazine much. Of what I’ve seen, it’s amazing that it’s produced on its scale, but for me, the scale is an impediment to reading it more closely. I observe a pretty relaxed hand on the editorial and design tiller. I was lucky enough to write for a magazine that took review and editing pretty seriously, on both technical and copy-editing matters. That takes a good deal of effort, which in turn would probably mean fewer articles each month, but it would also mean more polished and more thoughtful work; less quantity, perhaps, but higher quality.
Blog/Site: http://www.developsense.com
Twitter ID: @michaelbolton
Leave a comment