Software Quality Association of Denver

SQuAD Conference 2011 - Keynote Speaker

Michael Bolton

Michael Bolton has been teaching software testing on five continents for ten years. He is co-author (with James Bach) of Rapid Software Testing, a course and 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 for the Conference of the Association for Software Testing, and is a co-founder of the Toronto Workshops on Software Testing, and a testing columnist for Better Software Magazine

Testers: Get Out of the QA Business

The testing department is often misnamed "Quality Assurance", but testers don't assure quality. How can we, when we don't have control over the schedule, the budget, programmer staffing, product scope, the development model, customer relationships, contractual obligations, and so forth? Instead, our role is to provide ESP - not extra-sensory perception, but extra sensory perception. We're extra eyes, ears, fingertips, noses, and taste buds for the programmers and the managers; extensions of their senses. At our best, we're like extremely sensitive and well-calibrated instruments: microscopes, telescopes, super-sensitive microphones, vernier calipers, mass spectrometers, and bomb-sniffing detectors. We help the programmers and the managers to see and hear and otherwise sense things that, in the limited time available to them, and in the mindset that they need to do their work, they might not be able to sense on their own. The idea that we assure quality is misplaced. Those with the authority to change the code or to exercise control over the project assure quality, and it's our role to assist them.

In order to assist the programmers, we must learn to assure them that our principal goal is to help them look good - not to shame, or to blame, or to be evil. We're often the bearer of bad news. We must learn to recognize that, and deliver the bad news with compassion and humility. We must focus on exploring, discovering, investigating, and learning about the product, rather than on confirming things that we already know about it. We must report what we�ve learned about the product in a way that identifies its value and threats to that value.

In order to assist the managers, we must provide them with the information they need to make informed decisions, and then let them make those decisions. We must remain fully aware that product owners are making business decisions, not just technical ones. The product doesn't have hew to your standards of quality. We must demonstrate that the majority of problems that we find aren't exposed by mindless repetition of test cases, but by actions and observations that the test cases don't cover - that is, by sapient investigation of the product.

In order to assist the whole team, we must be a service to the project, not an obstacle. We're providers of information, not process enforcers. We don't "own" quality; we should assume that everyone else on the project is at least as concerned about quality as you are, but that each person has a different set of values that contribute to a perception of quality. As testers, our role is to think critically to help to prevent programmers and managers from being fooled and that that starts with not being fooled ourselves.

To be successful at quality assistance, we must learn to civersify your skills, our teams, and our tactics. We must invent testing for ourselves and our context, field-testing our approaches against our own experience, knowledge, and skills. We must study the skills of testing, particularly your critical thinking skills, but also work on systems thinking, scientific thinking, the social life of information, human-computer interaction, data representation, programming, math, measurement and we must practice those skills.