Michael Bolton has been teaching software testing on five continents for ten years. 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 in uncertain conditions and under extreme time pressure. He has been Program Chair for the Toronto Association of System and Software Quality, Conference Chair (in 2008) for the Conference of the Association for Software Testing, and is a co-founder of the Toronto Workshops on Software Testing.
Albert Gareev interviewed Michael while attending the Rapid Software Testing course in April, 2011.
Questions – Part 1
I saw that on the videos of James Bach and yours. And now I saw it live – the passionate Performance. You’re doing it way beyond a lecturing. You were Acting. And, in my observations, the presentations were much more perceivable, more striking. Within this context, my question is two-fold:
– do you have any background in performing or you consciously worked developing that skill?
Both. I had very early experience in public speaking in grade school. My major in university was English, and my minor was in theatre. I spent most of my time at university at the UC Playhouse, both on the actiing and technical side. And I was a stage manager for a theatre company that did school tours. You might be surprised at how producing and stage-managing a show prepares you for producing and stage-managing a software project.
– how much of live, passionate performance testers can / should do at work?
It’s pretty clear to me that people who live out their passion, and people who know act (in every sense of the words) go far. The key is to preserve the passion, but to keep down the drama.
In the beginning of the course you said: “we [authors of the Rapid Software Testing course] are not focusing on testing techniques, we help you to develop skills that allow you create testing techniques”. Can you provide a list of those skills?
I could make a long list and it would still be incomplete. Let’s start with critical thinking, systems thinking, modelling and simplification, logic, rapid learning, listening, note-taking, programming and tool-building, argumentation and rhetoric, sketching and diagramming… and then we’ll look at /next/ week’s curriculum. 🙂
Industrialization has been grown on the concept of division of labour. However, in jobs with high degree of creativity (as testing), that made more harm than good. I discovered for myself MIPping (“mention in passing”) as a powerful trick to workaround the labour division restrictions and “proxies”. Can you provide a reference to other tricks or techniques for that, or maybe ways to [quickly, easily] change stakeholders’ perception on a subject?
Quickly, easily? Only occasionally. Different things work for different people, and many ideas have very deep roots. I’ve found stories to be helpful sometimes, especially when the person hearing it can make the leap between the story and the real-life problem that you’re trying to solve. When I’m trying to explain a risk, for example, a story from my own history or a story from the newspaper about someone who has experienced a similar problem can be compelling. Some people find that easier to do with fiction, interestingly. I’ve met people who, given a real-life story, will reply, “That could never happen here,” but if you model an explanation with a fairy tale or a story from the classics or a TV show, they’ll make the connection. Some people connect better with the feeling the story gives them than the fact – if any – on which it’s based.
Visualizations can help, too. If you ever get a chance to attend Edward Tufte’s one-day class on presentations, go; it’s amazing. Also, look up Hans Rosling’s TED talks on www.ted.org, especially his first one.
Some people learn most quickly through experiential exercises or puzzles. If you can get to a place where you can simulate something with a game, powerful learning can come from that.
In “Rock-Paper-Scissors” you expanded the scope of testing activities way beyond the “traditional” assumption. If testers are those who need to communicate directly with customers, tech support, architects, project managers, product owners, programmers – what is left for business analysts, team managers, and other stakeholders who are primarily involved in the mentioned activities in a “traditional” way?
They’re all still there. I’m not suggesting that testers replace those people, but re-inforce them, to spot possible miscommunication or incompleteness, to look for inconsistencies between what individuals or groups are saying, to build bridges between people who otherwise might not encounter one another.