Issue 30

On testing, scientific discoveries and revolutions - An interview with Michael Bolton

Alexandra Casapu
Software Tester
@Altom Consulting


Michael Bolton was in Cluj between 17-20 November as instructor for RST (Rapid Software Testing) and Critical Thinking courses.

Before he continued his journey, Altom team stopped him for an interview to find out what some of his perspectives are on software testing and education in software testing, the link between testing and the scientific discovery process, as well as his opinion about testing communities and their role in potential revolutions in testing.

[Ramona] What are the main themes covered by the RST course?

[Michael] Wow! There are a lot of them... The most important thing is, I think, finding what the center of testing is. We look at the skillset and the mindset of the individual tester. That's the big deal.

We talk a lot about heuristics, that is, fallible ways of solving a problem. We talk a lot about oracles, how to recognize a problem. We talk about coverage, how to look at a program from a bunch of different perspectives in order to give a good, thorough search from a bunch of different angles for a bunch of different problems that could matter to people.

Those are the most important things that come to mind, developing the skillset and the mindset of the tester.

How is the content of the course evolving? Is it still growing?

[Michael] It's terrible actually! We now have about 7 days of material for the 3-day course, and in fact if we really wanted to do it up proud, and we went through all of the exercises we've developed over the years on all the different topics we would love to cover, I really have no idea how long it would take... a couple of weeks? 3 weeks? 4 weeks?

The other thing that's been happening over the years is that we started to teach the Rapid Testing for Managers class, and just this year, James debuted, I think it's a 2 day Rapid Software for Programmers, or people who are coders. It's really cool! So a lot of the exercises in that class are oriented sort of to being tractable for using tools and using scripting, using machinery. That's hard to squeeze into the regular class. So meanwhile, there's a constant evolution to keep finding stuff in the world that we import into the course. The most pressing issue for the moment is to try to figure out how to put this tacit and explicit knowledge stuff to be more central to the material. It's in there implicitly, tacitly if you will. I'd like to have the time to talk more about that and to maybe do some exercises on how that stuff fits into testing. I'd like to do more reporting exercises as well, to give people a chance to try something and blow it. Then to take a couple of cracks at it, to get good at it. So, the material is always evolving, we're always discovering new stuff, visualization stuff. James started doing some work with R lately - a data munging kind of language which allows you to show stuff, and to chop up data in really interesting ways. I'm behind him on that, but hey!, testing changes, so the class changes, and that's a good thing.

So the material is always evolving, we're always discovering new stuff. James started doing some work with R lately - a data munging kind of language which allows you to show stuff, and to chop up data in really interesting ways.

Testing changes, so the class changes, and that's a good thing.

How would you describe a person who would benefit from the RST or the Critical Thinking course? Why are these courses valuable and for whom?

[Michael] We have long said that Rapid Testing fits for anybody and any level, and that is because we've designed the exercises kind of inspired by Jerry Weinberg's work. Both James and I were students of Jerry's in this sort of informal way, that people are students of Jerry. We went to a lot of his workshops, a lot of his classes, and learned a ton from him about the design of classwork. Jerry has long been a proponent of experiential workshops and one time he gave away one of his secrets, which of course he published in books and so on. The secret is that on a reasonable exercise, everybody will learn what they need to learn, regardless of what level they are at.

So some people in our exercises will learn very basic things, because they are at a very basic level. Other people, who are more advanced, will catch onto something or notice something, or maybe they'll recognize something in the more junior people, and will understand something about how to guide more junior people. Sometimes people have insights on how to observe. The cool thing about Jerry's approach is that people will learn what they will. That actually is kind of relaxing for us in that we have a set of things that we'd like people to learn and to tell people about, but at the same time we don't have to commit to that. As a consequence to that, people learn different stuff. We observe them doing that and that loads us up with other things that we could talk about, and gives us other insights into what people need to learn, what people pick up from exercises, what they get from the experience.

So, both of those classes, both the RST and the Critical Thinking class can work for anybody, at any level. We have a dual kind of thing happening: there are 24 people in the room sometimes, so we have to sit back and let people learn what they will because we can't teach 24 people all in the same way. We give people an opportunity to learn rather than trying to teach them too much when things are going well.

What advice would you give to someone who is doing testing and would like to find the passion in their job, but they're not quite there yet?

[Michael] This whole business of how you instill passion in people, I have a stock answer for that, which is: I don't think you have to. Testing after all is about curiosity and people are naturally curious. People often ask me: "How do you motivate testers?" My answer to that is you don't have to. Just stop demotivating them! That's a huge problem in our business. As soon as you take responsibility away from people, and essentially make them a medium for the work of other people, then they disengage, they lose interest. If you give people a mission to go out and discover something, people will go out and discover something on their own.

What's one of the latest books you read that you would recommend a tester?

[Michael] I'm in the middle of a book called "The organized mind" by David Levithan but I keep putting it down and I keep losing my place in it. I've been reading a bunch of books on probability and risk, and statistics lately, but that's just a stop on my own personal agenda. I haven't had one exactly like that, to make me go WOW! except for the year I spent reading Harry Collins books.

Every one of his books is money in the bank, and he's amazingly prolific as a writer, but also a wonderful diversity of stuff along his central theme which is the sociology of science.

I think a great thing for testers to read is a pair of books called "The Golem" - the golem is a figure in Jewish mythology, a big, lumbering, clumsy giant, and that's a metaphor that Harry Collins and Trevor Pinch and several of their colleagues contributed essays to in these 2 books.

One is called "The golem and what everyone needs to know about science" and the other one is "The golem at large - what everyone needs to know about technology". Both of those are really interesting books for testers, I believe, because they talk about the lumpy nature of discovery, the fact that discoveries don't happen the way we're told they happen.

They do little case studies and investigations of what really happened in scientific studies. For example the Michaelson-Moorley experiment, one of the most famous in the history of science, was never actually completed. But we don't hear that story from the traditional sources; it's just set up as this done deal. What this illustrates is the fact that science is messy, that it's confusing. Also that it takes time to make sense of whether something is good science or bad science, or if somebody is a good scientist or a bad scientist. Especially because when there is a revolutionary discovery the natural reaction from the community is "That can't be right! He's got to be incompetent!". Galileo was obviously a genius. Everybody thought he was crazy!

The only exception where people were blown away in the long history of this stuff was Einstein. He was exceptional in that way, except a lot of his stuff wasn't settled until the 1960s. It was only then, 60 years almost, after he had his miracle year that the last serious objection to be put to bed.

But the way Harry has described it in a number of places, we see science as a ship in a bottle, right? We see it as a done deal. He says we don't see the mess, we don't see the spilled glue, and we don't see the snapped mast, we don't see the stuff that didn't work, and the stuff that didn't fit and all that. We see the finished project. That's a really interesting thing, I think for the popular understanding of science. It goes against what we are told of this lonely genius someplace in a garret who had this wonderful idea and lo and behold they said, "Well, that's marvelous, what a great thing!". Science is really controversial and it's filled with the same kinds of arguments that testers have to face every day when there's doubt as to whether this is a serious problem or not, or whether there is a problem here at all.

With every project we like to think, "Okay, it's done and there you go!" But we could never really be sure of that, that's not something that's subject to certainty. Jerry Weinberg says that one bit is enough to torpedo the value of a program, just a single bit. And before it happens, we don't know what that bit is.

They're fantastic books! They are very enjoyable and engagingly written, and fun. And the epiphany per page rate is really high.

How do you see the role of the testing communities? Can they spark revolutions in software testing?

[Michael] I've been a participant in several communities. I started one in its way with the Toronto workshops in software testing, participated in the early days of one the Dutch Exploratory Workshops on Testing - DEWT - which was largely inspired by LEWT, James Lyndsay's London Exploratory Workshops on Testing. I've been to all three of those, and that I think is where the REVOLUTION starts!

It starts with a small group of people, like all revolutions. It starts with a small group of people getting together and talking about what they're interested in, sharing their experiences with each other, and trying stuff out with each other. I'm really privileged to be part of those things! I get invited to them every now and again, or when I am in some place that somebody spontaneously puts one together that's really terrific. It's wonderful, because that's how we're going to start putting the testers at the center of testing, by getting us all to share our experience, not for us to sit and have material recited at us. Asmuch as I love books, we're not gonna get it all from books. We're gonna get it from talking to each other, from learning from each other, from interacting with each other, from helping each other to solve each other's problems.

On a bigger scale, conferences are good in a way, because you meet a lot of people there. I like the small scale, when it starts with a bunch of people meeting and drinking coffee or beer. The most exciting of those maybe is the Weekend Testers in India, initiated by Ajay Balamurugadas. I saw Ajay give a talk about it. It was so exciting! He described the growth of this community. Over a 15 week period, every weekend they got together, first live and in person and then online, they developed a community of skilled testers in India. It started with 4 friends, and their mentor and then it spread to 4 more friends, and pretty soon people from Mumbay and Chenai were asking "Hey! could we get involved with this?!", because they were hearing about it through the grapevine.

That's how communities evolve, that's how revolutions start, that's how big changes happen. Big changes always start with little changes.




  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • Yardi
  • P3 group
  • Ing Hubs
  • Colors in projects


Alexandra Casapu wrote also