Brian Marick
marick@testing.com
www.testing.com
My position paper comes from an unusual position. I have been, since 1992, a testing consultant. A good chunk of my business has been to teach - and motivate - programmers to test. To the extent that I have been successful (not as often as I'd like), that's been due to the following techniques. I'll describe them in terms of my Developer Testing Techniques course, because that is where most programmers I work with first see me. It's the place where I make that critical first impression. I apply these ideas in much the same way in other consulting situations.
I think these techniques are relevant to this workshop. Programmer testing exists because it simplifies and speeds the whole project. The alternative is a heavier process that requires more total work and more documentation. Yet, to most programmers, programmer testing seems to make the process heavier and more unpleasant. It seems to require more work and take more time. Any process change will include elements that encounter such a reaction, and you must overcome that reaction to succeed. These techniques help.
I begin my course on developer testing by describing my experience as a developer. By nature, I'm an OK programmer. But my peers thought I was better than I actually am. The reason? I tested, so fewer bugs escaped me to be noticed by other programmers.
I tell my story because programmers value the approval of their peers. They are much less motivated by the approval of managers, or appeals to what's good for the company. I am careful to appeal to what my audience values, not to what other people think it should value.
As a consultant, I am automatically an outsider. As a tester talking to programmers, I am doubly an outsider. The story above helps to reposition me into the role I want: that of a programmer talking to programmers. I use stories to reinforce that role. These stories are always told from the point of view of a programmer; they are the kind of stories two programmers would tell each other over beers.
It is important that I am a consultant who also does work testing and programming. People are rightfully suspicious of consultants who can only talk in detail about systems they worked on 20 years ago.
The techniques I present can be applied in a cookbook fashion, at least at first. While I encourage the thoughtful application of fundamental ideas, I provide a rote fallback. This is important, because sometimes people don't want to think.
Of course, sometimes they do. The reasoning behind the rote techniques needs to be explained, so that people can move beyond rote practice. But I still do that in concrete terms. I justify testing techniques in terms of specific examples of bugs they catch, not by abstract discussions of (for example) program structure. I keep the discussion grounded in daily activity (in this case, dealing with bugs).
People are rightly worried that a new process will suck away time without yielding benefit. So I tell them to begin by spending no more time applying my techniques than they already spend on testing. (Almost all programmers do some testing, even if they don't call it that.) People appreciate a consultant who's sensitive to their fears and constraints.
While I present a variety of techniques, I'm careful to point out which they can profitably use tomorrow and which they should defer adopting until they're satisfied with the first ones. Again, presenting a plan for incremental adoption shows that I'm taking their needs into account.