Blog

Quality of testing always matters. Interview with Michael Bolton. Part I

Michael Bolton is known to be a real Software Testing classic. One fact tells everything – he has over 20 years of experience in the computer industry testing, developing, managing, and writing about software. Michael delivered a lot of workshops, tutorials, and conference presentations on Rapid Software Testing and other aspects of testing methodology on ALL FIVE CONTINENTS.
4 September 2014
Interviews
The article by a1qa
a1qa

Michael Bolton is known to be a real Software Testing classic.

One fact tells everything – he has over 20 years of experience in the computer industry testing, developing, managing, and writing about software. Michael delivered a lot of workshops, tutorials, and conference presentations on Rapid Software Testing and other aspects of testing methodology on ALL FIVE CONTINENTS.

He is known to be a regular columnist in Better Software Magazine (formerly Software Testing and Quality Engineering) since 2005. He was an invited participant at the 2003, and 2005-2009 Workshops on Teaching Software Testing in Melbourne, Florida (hosted by Cem Kaner, James Bach, and Scott Barber) and a founding member (with Fiona Charles) of the annual Toronto Workshops on Software Testing. He is also the Program Chair for TASSQ, the Toronto Association of System and Software Quality.

We are happy to announce that today Michael is a honorable guest in our blog and we start to discuss the specifics of quality and testability.

a1qa: Having over 20 years of experience in computer testing industry, developing, managing, and writing about software, what is “quality” for you? Can a product/system be estimated as having 100% level of quality?

My notion of quality comes from Jerry Weinberg: “quality is value to some person(s)” (Quality Software Management, Vol. 1: Systems Thinking; also available as two e-books, “How Software is Built” and “Why Software Gets in Trouble”). James Bach and I have added “who matters” to make explicit some of the things that Jerry presents in the book. When you think of quality as “value to some person who matters”, it should be absolutely clear that evaluating the quality of something starts with a decision about whose values matter.

Quality is always relative to some person. A product can have terrible problems in it, and yet still satisfy some people all of the time and most people most of the time. The idea of quantifying quality at all seems quite silly to me; what would it mean to have a 77% level of quality for a product? What would it mean to have a 100% level of quality? Until you can establish that, and until you can establish a scale that applies to widely differing people with widely differing sets of values, the number isn’t going to tell you anything meaningful. Numbers won’t do the trick there; you need a qualitative description.

What you can do, as a professional working in software testing outsourcing, is to identify important problems in the product that threaten its value such that the product owner (who is ultimately the person who makes decisions about quality on a project) might be unwilling to ship it. But that’s not usually a question of numbers to any serious degree. Instead, it’s a collection of qualitative criteria framed in terms of stories. Both testing and reporting problems are built on the idea of composing, editing, narrating, and justifying stories about our products. Sometimes the stories can be illustrated by numbers, but most of the time stories are about problems that would cause loss or harm or annoyance, loss of value, to somebody who matters. (See “Braiding the Stories (Test Reporting Part 2)”

a1qa: “Testability” is it just a trendy word or the product attribute that simplifies testers` task?

Testability is not just a trendy word. Indeed, it’s one of the quality criteria that I referred to above. In addition to reporting on problems with the product (we call those bugs), the tester must also report on issues — anything that threatens the value of the testing work; anything that makes testing harder or slower. A product that is not very testable will give more time and more opportunity for the bugs to survive below our levels of awareness. There are other dimensions of testability too: figuring out how we know a problem when we see one, and identifying aspects of the tester, or the project, or our notion of quality. There’s more on that here.

In the next post we continue the discussion with Michael and touch upon Rapid testing and test automation.

More Posts

10 March 2020,
by a1qa
6 min read
Dedicated team model in QA: all you should know about it
Check on everything you should know about when to apply, how to run and pay for a dedicated team in QA.
Interviews
QA consulting
Quality assurance
30 September 2019,
by a1qa
4 min read
“Every team member is responsible for software quality”: interview with Head of QA at worldwide media resource
We continue talking about unsurpassed software quality. Consider how to make QA more efficient using shift-left and continuous testing.
Interviews
8 December 2017,
by a1qa
4 min read
a1qa: one-stop shop for first-rate QA services
Dmitry Tishchenko, Head of a1qa Marketing and Pre-Sales Department, answers the questions of The Technology Headlines. 
Interviews
Quality assurance
17 August 2017,
by a1qa
4 min read
From requirements specification to complex business analysis: interview with a1qa head of BA
Check how we at a1qa converge business knowledge with IT skills to deliver maximum value. 
Interviews
QA consulting
1 August 2017,
by a1qa
4 min read
Interview with head of a1qa test automation center of excellence
Dmitry Bogatko on how to manage the in-house Center of Excellence delivering value to the company's projects. 
Interviews
Test automation
19 August 2016,
by a1qa
4 min read
Interview with Adam Knight: Big Data exploratory testing
It is not so much to say that I find exploratory testing necessary. Rather I would say that I found it in my experience to be the most effective approach available to me in testing the business intelligence systems that I have.
Big data testing
Interviews
5 August 2016,
by a1qa
5 min read
Interview with Adam Knight: how much of a Sisyphean task is in software testing?
I’m a great believer in automation. I don’t believe that an agile approach to development is possible without some level of test automation. The use of such approaches does, however, need to be combined with an appreciation of the information that the automation provides you with.
Interviews
Test automation
20 July 2016,
by a1qa
4 min read
Good testing is about asking right questions: Intereview with Thanh Huynh
Software testing is not just to confirm things, it’s a process to explore, exercise the system to discover potential problems. You can achieve that by asking good questions to the system under test, yourself, your customers, your product owner, your manager, your colleagues, etc.
Interviews
20 June 2016,
by a1qa
5 min read
Interview with Lisa Crispin: whole-team approach to quality
To succeed with delivering valuable software over the long term, the whole team must take responsibility for quality, planning and executing testing activities. Our mindset has to shift from finding bugs after coding to preventing bugs from occurring in the first place.
Agile
Interviews

Get in touch

Please fill in the required field.
Email address seems invalid.
Please fill in the required field.
We use cookies on our website to improve its functionality and to enhance your user experience. We also use cookies for analytics. If you continue to browse this website, we will assume you agree that we can place cookies on your device. For more details, please read our Privacy and Cookies Policy.