196: Rapid Software Testing with Michael Bolton • Test Guild

Do you want to discover how to perform the fastest, least expensive testing you can while still completely fulfilling the mission of testing? In this episode Michael Bolton, the world-renowned software tester, teacher, and co-author of Rapid Software Testing shares a testing mindset that will forever change the way you think about testing.

About Michael Bolton

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. In 2006, he became co-author (with James Bach) of Rapid Software Testing (RST), a methodology and mindset for testing software expertly and credibly in uncertain conditions and under extreme time pressure. Since then, he has flown over a million miles to teach RST in 35 countries on six continents. Michael has 25 years of experience testing, developing, managing, and writing about software. For the last 18 years, he has led DevelopSense, a Toronto-based testing, and development 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.

Quotes & Insights from this Test Talk

Rapid Software Testing (RST) is three things. It’s skill set and it’s a mindset and it’s a class that James Bach my colleague and I developed. James started teaching the course in various forms in the 1990s and then settled on rapid software testing towards the beginning of the century. I started teaching the class in 2004 became a co-author of it in 2006 and it’s about doing the fastest least expensive testing we can do while still completely fulfilling the mission of testing. Which is to answer this question. Are clients, managers, developers people who are running the project running the business. Have a question that they would like us to answer and that question is are there problems that threaten the on-time successful completion of the project. That’s it. Everything else they want to know everything else they want us to do is in service of answering that question
We focus in Rapid Software Testing on trouble, on finding trouble, on exploring risk, on finding bugs that threaten the value of the product, on finding issues that threaten the value of the testing, or of the project, or of the business.
It’s important for testers to be able to express what they’re there for quickly and accurately and to the point.
There’s no manual testing! It’s like being afraid of werewolves. Manual testing doesn’t exist in exactly the same way that manual research doesn’t exist. And nobody talks about an academic at a university being engaged in manual research or automated research. Nobody talks about that matter about a programmer doing manual programming or automated programming even though programmers use compilers and IDEs and other kinds of sophisticated tools. Nobody talks about manual medicine right doctors don’t do manual doctoring and automated doctoring. So why do we talk about that and testing? Testers used tools testers, need to tools, testers engage with the product and the people around. It’s really confusing to me in fact why we’ve ever had such a thing as manual testing and automated testing.
But the other thing that you would look at if you were looking very closely, is you would look for the FDA guidance on the role of exploratory work leading up to the pivotal phase the pivotal phase is what we would usually refer to as formal testing. The process of creating a demonstration for an FDA audit that people do to show the essential operation of the product the FDA. What the FDA wants is accountability but accountability isn’t the same thing as accounting.
Most people don’t keep track of how much time they’re spending on various aspects of the work. They say well testing took this long. But how much of that time was actual testing, actual investigation of the product? Off that, how much time was setting up the product preparing to test? How much time was spent on compliance rather than on investigation? How much time was spent by the testers on investigating and reporting bugs that were there, perhaps, because the developers were being rushed? Because the developers were not taking an appropriate level of time in order to review and check their own work. But the answer generally to all this is more excessive structure, more excessive documentation which displaces the time we actually have to do our work.

Resources

Connect with Michael Bolton

May I Ask You For a Favor?

Thanks again for listening to the show. If it has helped you in any way, shape or form, please share it using the social media buttons you see on the page.

Additionally, reviews for the podcast on iTunes are extremely helpful and greatly appreciated! They do matter in the rankings of the show and I read each and every one of them.

Test Talks is sponsored by the fantastic folks at Sauce Labs. Try it for free today!