Interview with Michael Bolton (Part 3)

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 3

I have a question with regards to programmatic methods of checking – at unit level or integration level. When testers are assigned to help programmers developing such checks, they have to reduce or abandon product testing activities. How would you argue that code testing is not an equivalent to product testing?
 

Testing is about providing information.  That includes searching for information; investigating the product; exploring the product. Part of that investigation involves helping people find ways to allow the product itself to reveal certain kinds of information about itself more efficiently. So there’s a payoff associated with having programmers and testers collaborate in the effort to develop a more testable program.
 
One form of that payoff comes in this:  that whenever a tester finds a problem, she has to investigate and report it.  So it stands to reason that the fewer problems there are in the product to begin with, the less time the tester spends on bug investigation and reporting.  It takes a lot less time to investigate an area of the product that it does to investigate, discover a problem in it, figure out how to reproduce the problem, test around the problem to understand the it better, and write up a report.  I wrote a lot about that in 
“Why Is Testing Taking So Long?” and the subsequent post.
 
At the STAR East conference this year, Gojko Adzic gave a talk in which he suggested that people focus organize their work in terms of three things that he listed in priority:  1) Make sure the work gets done; 2) Teach other people how to do the work; 3) Do the work.  I liked this advice.  It suggests that if everyone is aware of what needs to be done, and everyone is trained and capable of doing it, then it becomes possible to distribute and share the work more efficiently and effectively.  When testers and programmers collaborate, that gives each speciality the opportunity to learn about what needs to get done.  The investment there can return a big payoff.  When lots of checking is being done at a low level, certain kinds of testing don’t have to be done at higher levels, bug reporting and investigation loads for those bugs, and more time is available for other kinds of testing.  The trick is in finding the balance, and that comes with lots of little experiments, and with experience.

 
You mentioned a few times that exploratory testing skills require personal, individual development, but in the same time exploratory testing approach is also about collaboration and communication. What advice you can give to test managers willing to implement rapid testing in their teams: where to start, how to organize, how to manage, and how to report?
 

The first thing to observe is that exploratory testing is going on all the time, so in a sense you’ve started already.  Where I’d start, for most managers, is to observe the work as it’s going on, and question the cost and value of each activity.  Are people producing a mountain of paperwork that no one ever reads or refers to?  Reduce that, and keep reducing it down the to point where you’re doing exactly as much as people need, no more, no less.  Are you writing out the steps of every test before trying to perform that test?  Why?  Do reasonably skilled people need that?  If no, don’t bother with it. If yes, consider whether training or conversation or more efficient forms of communication – diagrams or checklists, say – would enable them to do the job just as well.
 
For how to manage and how to report, look into the stuff that James and I have written on our blogs and in our articles.  We’re constantly working on new material as we develop it, help people other people to develop it.  Oh – and feel free to ask us about specifics.  I’m
michael@developsense.com; James is james@satisfice.com.  Other people – Jon Bach, Darren McMillan and Carsten Feilberg, are only a few examples – have provided some wonderful stories about how they handle things in their organizations.  Recording, reporting, and managing ET are high on our to-do lists.

 
You said, that the Rapid Software Testing course is continuously evolving and expanding. Can you tell what was the recent addition and what are you (or James Bach) currently working on?
 

We’re working on visualization of test information; reporting; testing in mobile environments.  All kinds of stuff – and just as with good testing or good management, we’re continuously adapting our priorities to new information as we get it.

 
The course annotation says that Rapid Testing is an approach to testing which is consistent with and a follow-on to many of the concepts and principles introduced in the book “Lessons Learned in Software Testing: a Context-Driven Approach” by Kaner, Bach, and Pettichord. Are there any other courses or movements aligned with the Context-Driven School of Testing, which you can recommend?
 

Rapid Testing reflects the values of context-driven testing, but there are some places where context sets a requirement for testing to be expensive and slow, at which point Rapid Testing become context-driving. The Association for Software Testing provides the Black Box Software Testing course, and runs CAST, the Conference for the Association for Software Testing.  Rob Sabourin’s work is very much aligned with the Context-Driven School.  Scott Barber is proudly context-driven, and teaches classes in performance testing.  In India, Pradeep Soundarajan has done some classes in Rapid Testing, although I’m sure it’s quite different from what we teach here (because of the context, and all that), but I’ve seen some exceptional test reports from his students.
 
I think of Rapid Software Testing as fundamentally agile without being big-A, Agile. In the same way, some people may have declined to align themselves with the Context-Driven School, but their work is aligned with the principles.  Any of Jerry Weinberg’s classes and workshops (like Problem Solving Leadership, PSL), or conferences (Amplifying Your Effectiveness, AYE) reflect context-driven, systems-oriented thinking.  Elisabeth Hendrickson does a lot of context-driven stuff in an Agile space. James Lyndsay does very good stuff on exploratory testing, and on biases and critical thinking errors.
 
Many of our colleagues offer consulting services and perform workshops at conferences and so forth; too many to list here.  I’m not aware of them offering commercial courses, but I’d like to be kept up to date.  In my observation, we’re all more interested in testing than in marketing.

 
What “every day advice” you can give to testers willing to keep sharpening their skills?
 

Oy.  That’s a big question.  I’ll settle for this: look, listen, and read; practice, speak, and write about testing and anything else that ignites your passion. Concentrate on thinking skills, but keep doing lots of practical stuff too.  Don’t be too focused on testing; the really great innovations will come from outside of the craft.

You might be interested in... The Dojo

Dojo Adverts-05

Tags: ,