Observations from Test Leadership Camp, part 1: Best Practices

Test Leadership Camp was held the Thursday after CAST in Madison, Wisconsin.  These are my own thoughts based on notes, recollections and tweets made during the day.  I'll be writing up thoughts and recollections from this in several posts.  This is the first.

Overall, I found the discussions and the ideas exchanged engaging and informative.  The drawback was it was impossible to be in all of them at once.  The first discussion I was in (with a floating group of participants involved) was around concepts of "Context Driven Testing." Right out the gate in the conversation was "There are good practices in context, but there are no best practices."  The short-hand version most folks use turns into "No Best Practices."

No "Best Practices"

What does this mean?  James Bach, Cem Kaner, Brett Pettichord and others have written on the topic at length.  Let us consider where the ideas behind CDT came from.  Generally, and this is my perception, they were a reaction to a mix of bad practices, untenable approaches to testing with much overhead and little to no value and, as more than one person describes it "Snake Oil."

A cornerstone of the "Snake Oil" approach is to rely on "best practices."  In testing, these tend to be something that worked well, by some measure, in some project at some point, somewhere in the past - either the company's or the individual's.

A heated part of the conversation was around what was meant by rejecting "best practices" in testing.  We settled on a phrase from Paul Holland - rejecting "best practices" means we "do not blindly follow process" models.  Simply because something, a practice, a technique, whatever, worked on a project once before, attempting to apply the same on another should be considered carefully before adopting or repeating the practice, even if it is for the same company, the same team and on the same software product. 

This actually is more than reasonable.  In my own experience, talking with test managers - the line managers supervising testers - they "get it" fairly quickly, if they are open to discussion.  If they are so tied up with other aspects of "Administeria" they are likely to reject any idea that does not originate from upper management.  This tends to be found in companies with several layers of management.

For smaller organizations, I find this tends to be less of a problem.  It may still be present, but there are fewer layers of pointy-haired bosses to deal with.

The challenge, as I see it and from experience, is getting the point of Context Driven Testing beyond the line manager and into upper levels of management.  The first stumbling block is the idea of "no best practices".

Here's what I mean.

Best Practices and Management

The idea of "no Best Practices" for managers with backgrounds other than technology is that it seems counter-intuitive.  They come from backgrounds where "Accepted Practices" are considered normal.  Anyone ever work under a big boss, a manager of managers, who was an accountant?  The idea of "Generally Accepted Accounting Practices" is ... pretty normal.  The concept of "Best Practices" seems a continuation of that.

Other times, people like to sound smart.  They want to be among the "cool kids" so will adopt their terms, buzzwords, and sometimes, bad habits.  If they use the "best practice" thing, and we walk in and tell them they are wrong, and all the stuff they've been talking about doesn't is smoke and mirrors - how well does that work?  Consider the Jesuits who went to Japan in the late 1500's.  How well did THAT work?

Even if they KNOW it is smoke and mirrors, they are unlikely to admit it to their own employees, particularly when they work several removes away from them.  They may admit it grudgingly to consultants, but there is little certainty that ONE person coming in contradicting the many others will make a dent.

One observation that came to me some time ago.  If you can't have a conversation with your boss's boss on something you are passionate about, or even on something you like and maybe they like as well, how are you going to get them to consider alternatives to what they have been told is a real thing?

Note - if you are working for a small company, like fewer than 50 people, and you can't discuss the differences between types of coffee with a CxO/President type, and you are both getting coffee from the pot in the break room, do you really want to work there?  (Don't ask how I learned that heuristic.)

Consider this - The CEO - the nemesis of many tech folks, is a human being.  They are remarkably similar to you in many ways.  They have their strengths and weaknesses and foibles and fears and... yeah,  Same thing with the CIO or any other CxO type person - or VPs or Directors of Whatever.  If you can't have a conversation on something you have in common, like coffee or tea or beer or music or something how do you intend to talk with them about this idea of "best practices"? 

The question is, can we reasonably and logically make a case, without causing offense, that refutes the notion of a simple solution that is "tried and true" without considering other options?  The challenge is to present the path that explains the fallacy of embracing practices simply because they worked, by some measure, in some other context, when other practices and techniques may prove of greater worth.