To connect our Tribal Qonf Speakers and Audience better, we interviewed our speakers over a few important questions. The conversations we had were just amazing.
In this edition, we are publishing the Interview we did with Michael Bolton. Michael answered many interesting questions and we are sure you will enjoy the read.
Tell us a little bit about what inspired you to become a tester?
Michael: Testing is interesting and fun! I’ve done a lot of things in my career — tech support, programmer, documentor, program manager — and they were interesting and fun too. All of those roles benefit from a tester’s mindset.
What or who has been the greatest influence in your professional life?
Michael: I’ve been inspired by a number of people along the way — most importantly, Cem Kaner, James Bach, and Jerry Weinberg.
How are you practising your skills during COVID-19?
Michael: James and I have been adapting our RST classes to present them all online. That has involved writing software for exercises and discovering ideas as we go. I’ve been doing a lot of online coaching and support work over the net, and a fair deal of writing, too.
The crisis, although horrifying, has been fascinating; we don’t usually get the opportunity to see science being done in real-time. The story changes from day to day; from bad news to good news and back, over and over. That’s to be expected; science is a lot messier and more uncertain and more controversial than most people think. But it’s also the best way we know to learn about things in the long run.
What are the resources you recommend to people to learn more about management?
Michael: If you’re going to manage people, you’ll need to become a skilled observer, and you’ll need to learn to observe yourself, too. That’s hard to do, so it’s a good idea to find someone whose style you admire, who’s willing to observe you, and who’ll give you feedback and perspective.
Management is mostly about people, so it’s a good idea to study people and the way they work, individually and in groups. Most of the time, it seems to me that managers don’t listen and learn enough from the people doing the work; they’re some of your greatest resources. Management is also about clearing obstacles so that people can get things done, so I’d say it’s a good idea to study problem-solving skills, too — and to study the way things have gone wrong.
Once again, Jerry Weinberg’s stuff is wonderful: Becoming a Technical Leader, and the Quality Software Management series. Robert Austin’s book, Measuring and Managing Performance in Organizations is also terrific.
Other than that, most management books I’ve seen seem pretty weak to me.
How do you learn and develop diverse skills like a rap on the talk, showcasing magic tricks in the workshop you offer?
Michael: My first career was in theatre. I was an actor when I was a kid; I worked mostly on the technical when I was in university, and I was a stage manager after that. Throughout my time at university, I had a part-time job at a comedy club — not as a performer, but I hung around comedians.
Performance of any kind is like testing, too. One way to do well is to choose easy stuff to do. The magic tricks I do in classes are like that; they don’t take any skill at all, really. The harder stuff depends on rewriting and redoing and revising — and getting feedback from thoughtful people. And most of them on study and practice; to the degree, any kind of skilled performance looks easy, natural and good, it’s usually because of conscious, deliberate practice.
You can’t be great at everything, but you can be good at lots of things. The trick is to get comfortable with things not going well at first. It’s okay to mess up. It’s normal. It’s confusing and annoying, and frustrating, but it’s okay because that stuff goes away over time as we learn.
Little by little, we learn from our bugs. We tend to find more or them when we’re diligent about looking for them, and when we get other people to help us learn. Being aware of the bugs is the first step towards fixing them.
We are aware that you are conducting RSTE classes online. How is it different from the BBST course?
Michael: The RSTE class focuses on Rapid Software Testing, which is a methodology developed by James Bach and me. RSTE is taught live by its authors, and it’s being updated continuously. There’s the direct interaction between the participants and the instructor that happens in real-time. We not only accept questions and discussion; we require them. The RSTE class is shorter than BBST, at 18 total hours of direct instruction time. That reflects a bias in RST: we aspire to the fastest, least expensive testing that still completely fulfills the testing mission.
BBST is a class of Cem Kaner’s design. He credits James as a co-author (or at least he used to; I’m not sure if that’s still the case). The content is delivered by video lectures. My understanding is that BBST represents a four-week commitment, at between 10 and 12 hours per week. That gives more time for long exercises and a broader overview of the testing landscape. In the design of the class, Cem placed a lot of emphasis on testers working with each other, in groups of four, asynchronously. The facilitators work with the groups on steering the exercises towards Cem’s intended learning outcomes.
There aren’t many testing classes that we recommend other than our own, but BBST is one of them.
Testers don’t seem to track where their time is spent. How do you suggest one should track their time spent across activities so that they can justify their time on projects?
Michael: What do we want? What do our clients want? They want to know about the status of the product, which we determine by performing tests and examining the product. Do we feel like we’re being productive? Does everyone agree that we are? If so, don’t worry about tracking time at all. If we’re concerned that we might not be as productive as someone might like, then we start looking at where we’re spending time.
The first principle of accounting for your time as a tester is to think in terms of inquiry, not control. Note the time that we spend on designing and performing tests, and note the time that we spend on things that interrupt that activity (like bug investigation and reporting), that support it (like setup and follow-up work), and that might undermine it (like wrestling with inconsistent environments or waiting for resources that never arrive). This doesn’t have to be very precise, as long as it’s reasonably accurate. Make it visible and legible — that is, readable and understandable. (There are examples here: Where does all that time go and here Breaking the test case addiction part 8) Then ask “Is everyone okay with this?” If they are, then don’t worry. If they’re not happy, or if they’re unsure, go deeper, probing to understand and illustrate more and more specifically where time is going.