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 2
Large organizations tend to produce a vast amount of rules, regulations, and restrictions. For example: not allowed to install any software; can’t use unapproved memory sticks; should report problems only in a certain manner and to certain people. What kinds of impact these restrictions have on testing and on testers’ minds?
It depends on the tester. Some people deal with it really well. Other people lose their motivation to test, even if they’re able to retain their will to stick around. As a context-driven tester, I recognize that a restrictive environment presents an interesting set of challenges, and I have to respond both within and to that context. There are numerous ways of doing that. The first thing I have to recognize is that the policy is working for someone, so a good place to start is to find out who the policy is working for. Policies are set by people, so they can be changed by people, or over-ruled by people, or adapted by people, or ignored by people. Depending on the risk, the consequences, and the ethical issues involved, I might ignore a trivial restriction, begging forgiveness rather than asking permission. If people insist on unhelpful restrictions, I can test with both hands tied behind my back, but I’ll identify the cost to the client of keeping things that way, and the value of untying me.
All that said, it seems to me that many rules and regulations and restrictions are arbitrary. The arbitrary rules, in my personal experience and in observation of others, kill people’s initiative.
James Bach and you often say: “testers don’t break software”. And yet there are books titled like that, and even job requirements mentioning that. What is your comment on this contradiction?
I observe that people are often imprecise what they say and how they say it. People are also reluctant to deal with emotional responses to imperfection. Perhaps claiming that “testers break software” insulates people from the reality: Testers don’t break software. The software is broken when we get it. It’s our job to find out /where/, and /how/, and /when/, and /for whom/, /what/ is broken about it, so that the people who can fix it can make informed decisions about where and how and for whom – and when to fix what.
We’ve got quite a large room full of people who came to your course. What was even more interesting to find out – many of them did not have a technical background. Even more interesting than that – some of them don’t even work in testing, per se. With regards to this, my question is two-fold:
– how would you comment on importance of diversity in a testing team?
– how would you rate the importance of knowing what testing is for other IT professions – i.e. programming, business analysis, project management?
Diversity is incredibly important. It helps to reduce the risk of tunnel vision, and of tunneled skill. We need lots of different skills and temperaments and perspectives and models and communication styles on testing teams.
I think all lines of work need to be good ambassadors for themselves, to all other lines of work. To me, that starts with seeking a useful understanding of the tasks at hand and the people doing them. We can get that started by expressing an interest in what other people are doing. I guarantee you’ll find common ground and useful things to learn, if you look and listen carefully; people get up to all kinds of wonderful things, even when their jobs seem strange to us at first. If you’re interested in people, that increases the odds that they’ll be interested in you. I find that the better service I provide–the more I find out what my client wants, and the more I deliver of exactly that–the more they’re interested.
When people don’t understand any kind of work, they’re more likely to systematically undervalue or mismanage it. So one of my continuing responsibilities is to negotiate and explain and account for the work that I do.
What is the role of a ‘toolsmith’ in a testing team, when such role is needed, and what kinds of skills a toolsmith should have?
A toolsmith, in my view, should be a programmer with the speciality of crafting software that helps in testing tasks. That means that the programmer should have at least some of the tester’s mindset: an ability to think critically about software; systems thinking; an ability to create and understand and adapt to a wide variety of models of the software; lots of notions of coverage, lots of ideas about quality criteria; an investigative mindset. It also means that the programmer is necessarily a generalist, since there are so many different testing tasks that computers can help with. Creating interesting data sets; searching, sorting, parsing, filtering log files and other data; representing and visualizing data; developing automated oracles using alternative algorithms; developing statistical analysis tools; maybe collaborating with the production programmers to create testable interfaces. I’d reckon it’s at least as challenging and as interesting as production programming. Another important role for the toolsmith, I’d argue, is helping testers to learn programming, and to learn about programming. Apart from everything else, learning to program is a useful exercise in humility for testers.