Michael Bolton, my brother Jon, and I have produced a new version of our Exploratory Testing Dynamics document. We unveiled it last week at STPCON.

This document describes the elements of exploratory testing as we currently understand them. This new version has not yet been reviewed by Cem Kaner or any of our colleagues who normally have opinions on this, but I don’t anticipate that it will be revised much when they do. It should be fairly stable, for now.

ET cannot be summed up fairly as “unstructured playing around” and if you look at this document you will see why. If nothing else, count the elements in it. Crikey.

The document consists of four lists:

1. Evolving Work Products

Exploratory testing is an approach that emphasizes evolution. We start with something and make it better and better. Often testers can be overly focused on finding bugs, but look at all the things that get better. For instance, you can run your automated regression tests a thousand times and the tests don’t learn and neither do the button pushing testers. But you learn a lot by sapiently retesting– you evolve. One of the products of ET is a better tester.

Some evolution also happens in highly scripted testing, but in ET it’s a primary goal. It’s the point.

2. Skills and Tactics

What does an exploratory tester do? Well, feast your eyes on the Skills and Tactics list. Each of those items are things that seem to us to be reasonably independent, teachable, and observable. Some of them are also skills that a highly scripted tester would need, but they work a little differently for explorers. For instance, the skills of reading and analyzing documents means doing that to prepare for or aid exploration of the product, rather than to prepare detailed instructions for scripted test execution.

3. ET Polarities

The Polarities list is unique to ET. An exploratory tester must manage his own mental process, and that process is about developing ideas and using those ideas to search the product for trouble. We’ve found over years of experience doing this that a tester loses steam if he spends too long in one train or type of thought. So, what can he do?

One answer is alternation. We alternate among complementary activities. Two activities are complementary if performing one of them rejuvenates the other. A great example is reading about a product and directly interacting with it.

4. Test Strategy

The Heuristic Test Strategy model is a set of guideword heuristics that we publish as part of the Rapid Software Testing class. In addition to the general ideas of exploration, evolution, and alternation, the guidewords represent the specific subject matter of testing– the conditions we need to succeed, the things we look at, the things we look for, and the specific test techniques we use to produce tests.

With these lists, I can systematically evaluate a tester and identify strengths and weaknesses. We in the Context-Driven School of testing need models like this, because we focus on skills, rather than techniques and tools. This document allows us to focus our efforts and develop specific exercises for tester training.

An open letter to James Whittaker:

You wrote: “I had an amicable hallway conversation with James Bach. His blogger angst at my use of the title ‘Exploratory Testing’ didn’t spill over to a face-to-face discussion. Frankly, I am not surprised. I’ve never claimed the term as my own, I simply took it and made it work in the hands of real testers on real software under real ship pressure. Consultants can coin all the terms they want, but when us practitioners add meat to their pie, why cry foul? Is it not a better reaction to feel happy that there are people actually doing something with the idea?”

None of that is true.

I would not describe our conversation as amicable. Perhaps you thought it was amicable because we didn’t talk about anything important, and during that moment, I didn’t raise my voice. Or punch you.

My criticism of you is not “blogger angst”, it’s my opinion based on studying for 20 years something you’ve hardly studied at all. Every substantive conversation we’ve had has consisted of you denying whatever I happen to say, without offering evidence and in most cases without offering an argument. You have a zeal for dismissing my work that is truly extraordinary– you once even denied, again without evidence, that I knew how to run a file compare tool. Wow.

Now you say you made ET work? Well, first, you don’t know what ET is. Second, you’re an academic. You stayed in school and studied formal methods (that no one uses) while I was cutting my teeth in Silicon Valley. I have taught and demonstrated ET all over the world. I’m not alone, but work with a community of like-minded testers and thinkers, comparing notes with them, and deepening our understanding of exploratory learning applied to testing. You have not been a part of that.

I don’t think you’re adding meat, I think you’re serving thin gruel.

ET does work. My community repeatedly shows that it does. We will patiently continue to teach and develop it.

Subtlety hasn’t worked with you. So I’m saying this publicly: You’re a good speaker, but as a practitioner, if your prose is any indication, you don’t know much about what you are doing. If you applied yourself, you could become a good tester. But I’ve seen no evidence of that, yet.

When Cem Kaner introduced the term “exploratory testing” in the mid-80’s, everyone ignored it. When I picked up the term and ran with it, I was mostly ignored. But slowly, it spread through the little community that would become the Context-Driven School. I began talking about it in 1990, and created the first ET class in 1996. It wasn’t until 1999 that Cem and I looked around and noticed that people who were not part of our school had begun to speak and write about it, too.

When we looked at what some of those people were saying, yikes! There was a lot of misunderstanding out there. So, we just kept plugging along and running our peer conferences and hoping that the good would outweigh the bad. I still think that will happen in the long run.

But sometimes it’s hard to stomach how the idea gets twisted. Case in point: James Whittaker, an academic who has not been part of the ET leadership group, and also has little or no experience on an industrial software project as a tester or test manager, has published a book called Exploratory Software Testing.

Whatever Whittaker means when he talks about exploratory testing is NOT what those of us mean who’ve been working on nurturing and developing ET for the last 20 years. As far as I can tell, he has not made more than a shallow study of it. I will probably not write a detailed review (though his publisher asked me to look at it before it was published), because I get too angry when I talk about it, and I would rather not be angry. But Adam Goucher has published his review here.

Another guy who shows up at the conferences, B.J. Rollison, also gets ET wrong. He’s done what he calls “empirical research” into ET, at Microsoft. Since he, again, has not engaged the community that first developed the concept and practices of ET, it’s not altogether surprising that his “research” is based on a poor understanding of ET (for instance, he insists that it’s a technique, not an approach. This is similar to confusing the institution of democracy with the mechanics of voting), and apparently were carried out with untrained subjects, since Rollison himself is not trained in what I recognize as exploratory testing skills.

Experimental research into ET can be done, but of course any such work is in the realm of social science, not computer science, because ET is a social and psychological phenomenon. (see the book Exploring Science, for an example of what such research looks like).

Now even within the group of us who’ve been sharing notes, debating, and discovering the roots of professional exploratory thinking in the fields of epistemology and cognitive psychology and the philosophy and study of scientific practice, there are strong differences of opinion. There are people I disagree with (or who just dislike me) whom I still recognize as thoughtful leaders in the realm of exploratory testing (James Lyndsay and Elisabeth Hendrickson are two examples). Perhaps Whittaker and Rollison will become rivals who make interesting discoveries and contributions, at some point. Time will tell. Right now, in my opinion, they are just skating on the surface of this subject.

I told James Whittaker that I don’t use the term “manual testing” and that I prefer the term “sapient testing” because it’s more to the point. This is evident in the first definition of the word “manual” in the Oxford English Dictionary: ” 1. a. Of work, an action, a skill, etc.: of or relating to the hand or hands; done or performed with the hands; involving physical rather than mental exertion. Freq. in manual labour.“ Sapient, on the other hand, means “wise.”

Whittaker laughed and said “Bach, you are always making words up.” And then told me that in his opinion manual testing did not evoke the concept of unskilled manual labor. Now, other than establishing that James Whittaker doesn’t have an online account to the O.E.D. (definition of “sweeeeet!” is “an online O.E.D. account.”), or perhaps doesn’t consider dictionaries to be useful sources of information about what words mean, I see something else in his reaction: I blew his mind. What I said doesn’t intersect with anything in his education.

To understand me, Whittaker will have to use his sapience, rather than responding manually (i.e. with his hands).

In other words, I notice that some of my rivals in the testing industry don’t merely disagree with me, they apparently don’t comprehend what I’m saying. Example: after some ten hours of solid debate with me, over several sittings, Stuart Reid (who is working on a software testing standard of all preposterous things), told a colleague of mine that he believed I don’t truly mean the things I said in those debates, but merely said them to “be provocative.” Huh. That’s some serious cognitive dissonance you got going, Stu, when the only way you can process what I’m saying is to declare, essentially, that it was all just a dream.

Of course, I don’t think this is an intelligence problem. I think this is a lack-of-effort-to-use-intelligence problem. It’s not convenient for certain consultants to tear up their out-of-date books and classes and respond to the challenge of, um, the last 30 years of development of the craft. So they continue to teach and preach ideas from the seventies (or create testing standards based on them, because they believe not enough people appreciate testing disco).

Anyway, in the Context-Driven community’s latest attempt to explain the ins and outs and vital subtleties of testing, Michael Bolton has come up with a promising tack. Maybe this will help. He’s drawing a distinction between testing and checking.

Brace yourselves for insight. A lot of what people call testing is actually mere checking. But even checking requires testing intelligence to design and do well. This gives more specifics to my concept of sapient testing. Here are Michael’s seminal posts on the subject:

1. http://www.developsense.com/2009/08/testing-vs-checking.html
2. http://www.developsense.com/2009/09/transpection-and-three-elements-of.html
3. http://www.developsense.com/2009/09/pass-vs-fail-vs-is-there-problem-here.html
4. http://www.developsense.com/2009/09/elements-of-testing-and-checking.html

When Michael first made the distinction between testing and checking, I was annoyed. Truly. It blew my mind in that bad way. I thought he was manufacturing a distinction that we didn’t need. I decided to ignore it. Then he called me and asked “So what do you think of my checking vs. testing article?” I had to say I didn’t like it at all. We argued…

…and he convinced me that it was a good idea. Thank you dialectical learning! Debate has saved me again!

I now agree that it’s a practical distinction that can be used as a lens to focus on the quality of a test process. I do have to get used to the words, though. I now see a difference between automated testing and automated checking, for instance: automated testing means testing supported by tools; automated checking means specific operations, observations, and verifications that are carried out entirely with tools. Automated testing may INCLUDE automated checking as one component, however automated checking does NOT include testing.

Making this distinction is exactly like distinguishing between a programmer and a compiler. We do not speak of a compiler “writing a program” in assembly language when it compiles C++ code. We do not think that we can fire the programmers because the compiler provides “automated programming.” The same thing goes for testing. Or… does that blow your mind?

Context-driven testing is apparently very difficult to understand. I wouldn’t have thought that it’s a difficult concept, except for the last decade I’ve watched hundreds of people in terrible confusion. Testers outside of the United States have an especially hard time with it, for some reason that escapes me.

I do have some working theory of the misunderstanding. I think it has a lot to do with how so many people are looking for first-order formulaic answers to every problem. Context-driven thinking rejects that. We say you can’t do quality work unless you develop skill. There’s no secret phrase or recipe book that will grant you skill. You must develop skill by struggling with testing problems.

India has a lot of testers, but so very few have shown publicly that they can think outside the “best practices” and Factory School kiddie pool. But, I’m happy to say, Parimala Shankaraiah is one of them. I’m adding her to my blogroll. Her blog is called Curious Tester. (It’s nice to be able to honor a female tester for a change.)

Bear in mind I have no idea if she thinks of herself as context-driven. She hasn’t mentioned it directly. I believe she is, based on how she writes.

Several things strike me about Pari. One is her sheer enthusiasm. Her love of testing is infectious. Another is the breadth of her imagination. In one post she related the book The Secret to her experience as a tester. That was impressive analogizing! Almost acrobatic. She believes in peer conferences and she opposes certification, too. Those are important indicators of a context-driven sensibility.

I have often said that I expect the Indian testing industry to wake up someday (at least a few thousand of them) and realize that they can do a lot better than writing dimwitted scripted test cases. Pari is hopefully just the beginning of the Indian testing renaissance.

When my publisher decided to release my Secrets book for “free” as an ebook, I thought it meant FREE. I just found it meant free-for-a-little-while-and-then-gone. Apparently it has some sort of DRM expiration date on it.

[Update: One of my tester friends found that he could defeat the expiration mechanism by playing with the system date, but that's not very practical, I guess.]

They didn’t mention this to me when they told me about the promotion. I suppose they thought “Well OBVIOUSLY it’s only free for a period of time… we’re in the publishing business!” But it wasn’t obvious to me or I would have told you when I announced it.

Anyway, you can still download the book until the 24th of July, and you can read it for some period of time after that before it goes POOF. Not bad, considering that it didn’t cost you anything except the annoyance of downloading it, but still…

Naturally, I hope everyone goes out and buys the hardcover with real money. That way I’ll be encouraged to write more books. Otherwise, it’s an expensive hobby.

Side note: It’s interesting how glitchy the process is, too. Several people found that the special Adobe reader software complained and moaned and wouldn’t install on their systems. QUALITY IS DEAD!

Secrets of a Buccaneer-Scholar is now available in electronic form. You can get it from Simon & Schuster, or less expensively on the Kindle from Amazon.com.

The book is about learning. It’s about alternatives to schooling and certification. But it also describes how I became a tester, and why I progressed as a tester.

The hardcover version, which will be quite nice and small enough to smack people with and not do permanent damage, will be available in September.

The CAST testing conference is happening in Colorado Springs, July 13-16. I mention this for two reasons:

1. I will be teaching a testing tutorial there. I also will be wandering around with my various testing games and challenges hoping to do them with anyone who wants to see what I mean by “testing skills.”

2. CAST is the only conference that is organized in the true spirit of the Context-Driven School of Testing. It’s kind of our home conference. If you find my thoughts interesting, or those of Cem Kaner, Michael Bolton, Ben Simo, etc. Then you’ll want to be there, if you can.

This comes from an ISTQB advertisement they spammed me with, today:

“To ensure the quality of any software system, testers and QA professionals must thoroughly test the product. But how do you know that these tests are effective? If your team is conducting ad hoc, informal tests with little guidance or planning, the quality of the end product can be severely jeopardized—negatively affecting your bottom line.”

I don’t like to say things like this, nor am I comfortable supporting people who do. It’s not that it’s untrue– it is not necessarily untrue. But it is the kind of statement that fans the flames of a certain sort of Factory School bigotry in our industry. “Oh, you can’t trust testing unless it is pre-planned, pre-packaged, pre-approved, formalized, etc.”

Notice they say nothing about skill. It’s all about methodology, here, not skill. This kind of setup suggests that the next statement will be about the importance of factory-like test methodology. But that’s not what happens.

“The best way to be certain that you are providing customers with quality software is to make sure your team of testers is certified.”

Friends, I’m aware of no one in the industry– not even my worst enemies, not even Rex Black or Stuart Reid– who would publicly assert this or defend it. In fact, in debates against those of us who think certification is consumer fraud, the most typical move is for certificationists to say that certification isn’t even about skill, but rather about basic knowledge. “It’s a start” they say. “It’s a foundation.” (I reply that it’s a bad start and a bad foundation. Much worse than what it tries to replace.)

But then they allow this sort of advertising to go out! Completely undercutting their innocent-sounding plea! And they wonder why I complain that they don’t have the best interests of the testing craft at heart.

Notice that the “ad hoc and unplanned” stuff doesn’t even logically connect to certification. In fact, wouldn’t a highly skilled tester be far more likely to succeed with an ad hoc testing regime? When Roger Federer plays ad hoc tennis, I bet he still wins.

I think the reasons they start talking about methodology and end up talking about certification is A) their potential customers don’t understand the difference between skill and method, B) method is more concrete than skill, thus easier to evoke, and C) they know that what they say doesn’t have to be true or even logical, as long as it evokes horror and promises hope.

Oh, but there’s more…

“By taking the Software Tester Certification course and earning an internationally recognized certification in software testing, your team will gain the expertise needed to handle your greatest testing challenges; earn credibility and recognition as competent quality assurance professionals; and provide greater value to your organization.”

It’s internationally recognized? By whom? Some people who don’t study testing and some people who study testing and financially benefit from certification. Okay, but it is also internationally ridiculed by serious testers of many nations who wish to raise themselves to a level of skill that can’t be obtained in just a couple of days of training.

I recently encountered Dot Graham, now semi-retired, who told me that it hurts her feelings when people like me suggest that certificationists are only in it for the money. Dot is a sweet person. I don’t want to hurt her feelings. But I point her to advertising like this and I challenge her to explain it in any other terms. If not greed, then what, Dot? Stupidity? Pride?

Dot doesn’t want to argue with me about this. Of course she doesn’t. Rex Black doesn’t want to argue, either. Naturally. What answer could there be? Lois Koslowski once told me that “big dogs” don’t need to debate (in fairness, Lois Koslowski claims not to be a tester. I agree that she showed no testing competence or knowledge in the conversation we had. I just mention her because she did claim to be in charge of the ASTQB organization. Yikes!) This is capitalism in its ugly form– harvesting the ignorance and fear of others. Debate has no place here.

Is there no one in that self-declared professional community who reviews the advertising and stands up for professional temperance and humility?

A salesman from G2 Test Labs just called me. He said he was from India. He wanted to know if my testing company needed to partner with an offshore lab like his. I’m writing this now, while the memory of the conversation is fresh.

After he made his brief brief opening monologue I asked him “I’m a testing company. Why are you calling me?”

“Maybe you want to have an offshore arm.” He said.

“Well that depends on the skills of your testers. How do you train your testers?” I asked.

“Oh… we don’t do any training. But our testers are certified by other organizations.”

“Which organizations certify your testers?”

“Uh… I will have to check on that and get back to you.”

“Yes, that’s important information. Are ALL your testers certified?”

“Probably… most of them are.”

“Sounds like you don’t know.”

“…”

“Hey, this will make a funny post. Check my blog in about an hour. Goodbye!”

Now, in fairness, the salesman sounded like he was about 22 years old. Perhaps they sent him to call me as part of some hazing ritual.

[Oh, I just remembered, in his opening statement, he mentioned that his company was ISO-9001 certified, too. Wow. That takes me back to 1992, when I was fighting ISO-9001 certification. That certification program turned out not to amount to anything, either.]

Matt Heusser wrote an interesting post about “boutique testers.” I like the idea of boutique testers (boutique intellectuals of all kinds, actually, which is why I wrote my new book.) And I am an example of one. The testing I’ve done in recent years has been mostly on court cases or part of coaching testers, though. I want to do more ordinary testing. I need that in order to keep up my practice.

I live on an island, making travel expensive and annoying. But I have a great Internet connection.

There are important challenges to being a remote tester, though. The main technical problem, in my experience, is acquiring and configuring the product to test. Getting up to speed fast benefits from being onsite. The main social problem is trust. Hiring a remote tester, especially one who’s supposed to be high powered, is a little like hiring a therapist. In my experience, developers feel more sensitive about a well-paid, high status outsider poking at their work, than they do about an internal tester who probably will disappear in a few weeks.

Then there’s communication. Despite all the tools for modern communication, we haven’t yet developed a culture of remote interaction that lets us use those tools effectively. Even though I’m always on Skype, and people can see I’m on Skype, they still ask permission to call me on Skype! And I also feel nervous about calling other people on Skype. They might be annoyed with me. I do use GoToMeeting, and that helps a lot. Michael Bolton and I have been collaboratively writing, recently, using it. We like it.

Finally, there is one big logistical problem: availability. You can call me up and have me test for you. But, being a fully independent consultant, my time is chopped up. I have a week here and a few days there, usually. This is the main reason I go in for short-term consulting and coaching. Unless a rich client comes along and induces me to clear my schedule, I can’t afford to have only that one client.

Still, with the price of travel so high, I think this is the direction we need to go: each of us developing ourselves into unique thinkers with strong brands, and then remotely connecting (interesting oxymoron, eh?) with our clients.

Phone: 360-440-1435
Email: james@satisfice.com
Skype: satisfice

I’ve released a new video, which is a whimsical look at a serious subject: explaining exploratory testing.

In the video, my brother and I independently test an “Easy Button” for 10 minutes. Neither of us had seen the other’s test session. Then I edited the 20 minutes of total testing down to a 4 minute highlight reel and added subtitles.

The subtitles are important. One of the core skills of excellent testing is being able to reflect upon, describe, explain, and defend your work. The rhetoric of testing is a big part of Rapid Testing methodology.

So, everything we did, we can explain. If someone stops me when I’m testing, I can give a report on the spot, in oral or written form, and I can put specific technical terminology to it. In my experience, most testers are not able to do that, and there’s one major reason– they don’t practice. It does take practice, friends. While you were enjoying your Sunday, my brother and I were challenging each other to a testing duel.

You might quibble with me about the specific terminology that I used in the video. Indeed, there is a great deal of leeway. One single test activity might simultaneously be a function test, a happy path test, a scenario test, a claims test, and a state-transition test! There’s no clean orthogonality to be found. And as you already know if you read my blog, I reject any “official” lexicon of testing. But I’m not just throwing these terms around, I can explain each one, and say what is and is not an example of it.

What about the Easy Button?

Our principal finding is that the Easy Button is extremely durable. I’m surprised at the high quality of the fit and finish. Also it feels solid (I discovered why when I disassembled it and found apparently lead weights inside. Plus, the button surface is amazingly resilient to repeated hard blows with a rock hammer).

But I’m also surprised that it claims not to be a “toy.” Of course it’s a toy. Of course little kids will play with it.

If I were seriously consulting about testing it, I would probably suggest that its physical qualities were more important to validate than its functional qualities. There appears to be little risk associated with its functionality. On the other hand, there appears to be little risk with its physical qualities either.

I would suggest that it’s far more important to test the web version of the “Easy Button” than the physical version. I would move on to that.

(Since this pertains to both self-education AND technical work, I’m posting this on both of my blogs)

Randy Ingermanson has an interesting approach to writing fiction. It’s called the Snowflake Method. It looks interesting, but I won’t be following it in my work.

First, Don’t Follow
I only use my own methods. That is to say I’m happy to use anyone else’s ideas, but only if they become mine, first. I can learn from other people, but I don’t follow anyone. See the difference? The only way I can responsibly follow someone as a thinker is if they are supervising my work. For instance, when Captain Ben taught me to sail, I used his methods because he was right there to correct me. Also it was his boat, and he answered my questions and let me experiment with alternative ideas to see why they were inferior. As he trained me, his methods became my methods. I began to do them based on my sense of their logic– which means I also came to understand under what circumstances I might need to change them. That’s the difference between learning and numb indoctrination.

When Jerry Weinberg taught me the Fieldstone Method of writing, I formed my own interpretation of it, and now it’s the James Bach version of Weinberg’s Fieldstone Method. And when I teach Rapid Software Testing, my methodology ideally becomes personal to each student, morphing to their own preferences and patterns, or else they should not be using it.

“Composting” Good?
In describing the Snowflake Method, Ingermanson discusses something that he says every writer does: composting. That’s where you actually dream up the story. He writes that

“It’s an informal process and every writer does it differently. I’m going to assume that you know how to compost your story ideas and that you have already got a novel well-composted in your mind and that you’re ready to sit down and start writing that novel.He says how you do that is a personal creative matter.”

Okay. Interesting that he says nothing about how to do that, though, since for me that’s almost all that writing is. But now, the actual Snowflake Method, he says, kicks in after composting is done with. It’s a way of progressive outlining of the book so that you can write it in an organized way.

Wait, did he say that happens after composting?

AFTER composting? Seriously?

This is a problem for me, because I’m nearly always doing that thing he calls composting. For me, writing is an exploratory activity. I’m constructing my ideas before I write them down and also as I’m writing them down. I’ve written many articles and two books that way. I have not yet written much fiction, but I have a hard time believing my method will be or should be different for fiction.

“Seat of the Pants” Bad?
Here Ingermanson makes a tiresome rhetorical move: He contrasts his approach with the “seat of the pants” method. He believes his method is better. I agree that it’s probably better for him, because it’s his own personal method. But on what basis can he say that his method is better than the alternatives for anyone else? Besides, it sounds like “composting” is just “seat of the pants” that happens to be Ingermanson-approved.

This is typical best practices rhetoric, and the pattern generally goes as follows:

1. I conceive my method as figure and everything else as ground. I won’t talk about how my method blends into and is supported by any other methods or skills or talents or preferences. I won’t talk about how it may go horribly wrong. The method is an island.

2. Since I like my method better than the other not-the-method thing I once did, [cite anecdotal and cherry-picked evidence here], it is probably better.

3. Since I taught someone else to use my method and they said they like my method better than whatever unexamined way of working they once had, [did they actually use my method? Well, they said they did, but I didn't actually watch them do it], it is even more probably better.

There are a few problems with this pattern of reasoning. One is that it is not necessarily a comparison of one method to another. It’s more likely a comparison of a state of confusion to a state of decision. Decision usually does win over confusion. The people who are out looking for a method may not already have a sound understanding of the methods they already use. So they leap on any method offered as if it were a life buoy. This of course is no indication that the method itself is better than any other method, but merely that people hate feeling confused and incompetent.

Another problem is that even when it is a comparison of methods, it’s generally a comparison between an ineffable method and one that sounds good when explained. Things that are ineffable, no matter how useful, get a bad reputation. That’s why you’ve met at least one person in your life who has claimed that you need to “learn to breathe” or “remember to breathe.” In fact, you already have a method of breathing, and unless your eyes have just gone so fuzzy that you can’t read this at all, you are probably breathing pretty well right this moment. An effective way to present a method of breathing could be to say “If you are having problem X, one solution might be to try a special kind of breathing called Y. Let’s try it now so you can see what I mean…” This way offers the practice without implicitly or explicitly denying other ways of working.

Yet another problem is that all methods rest on a certain way of organizing the world. If you don’t accept that foundation, then the method won’t satisfy you. Ingermanson seems to find it easy to segment heavy creative work from the light creative work. Hence composting is good, but seat-of-the-pants writing is bad. Since I don’t accept that distinction, to use the Snowflake Method as presented would force me to become alienated from my creative process. I would not be in direct touch with my own mind, but all thoughts would be mediated through the controlling outline of the Snowflake. Ick!

A Rhetoric for Pushing Back
It’s not “seat of the pants”, I say. It’s not merely “ad hoc.”

It’s thoughtful and responsible, rather than mindless and robotic. It’s exploratory, rather than pre-scripted. It’s agile rather than rigid. It’s constructive and generative, rather than a mere conditioned response.

Want more? Try breaking the method down into sub-parts. In exploratory work, I might cite such tasks as:

• overproduce ideas and abandon them (think “brainstorming”)
• recover previously abandoned ideas (think “boneyard”)
• pursue lines of inquiry
• conduct thought experiments
• alternate my tactics for better progress
• dynamically manage my focus (from very focused to de-focused)
• charter my own work in light of my mission as I understand it
• view my work from different perspectives
• produce results, then reproduce them differently based on what I learned (cyclic learning)
• construct a new and better version of myself as I work

Seat of the pants? That sounds like a put-down. Why don’t they call it dynamic control and development? Because that doesn’t sound like a put-down.

Reclaim Your Personal Method
As Adam Savage says, “I reject your reality, and substitute my own.” Yes, indeedy.

You don’t have to accept someone else’s intermediating artifice between you and your thoughts. Whether that’s a book outline, or a test plan document, TPI, or some method of artificial breathing you can say no. You can say “that would be irresponsible, because I must remain attached to the source of my own methods of working. I can’t drive a car safely from the BACK SEAT!”

Having said all that, I found Randy’s Snowflake Method interesting and I think I will try it. I will meld it with my exploratory style of working, of course, and claim it for my own.

Pradeep Soundararajan got threatened with lawyers when he criticized Testing Experience magazine for being under the thumb of the ISTQB (for those who don’t yet know, the ISTQB are the guys who want to prevent you from getting work as a tester unless you first pass their silly test. They also plagiarized my definition of exploratory testing, while subtly changing that definition to alter part of its fundamental meaning).

The editor of that magazine could have said “Look, we believe in the ISTQB. That’s just how it is.” Instead he hinted that he would sue Pradeep if he blogged his criticism. Pradeep blogged anyway.

A couple of authors of testing textbooks have threatened to sue me, in the past. I don’t know what they think they were accomplishing by that. I just turned around and blogged about them. It’s not illegal to criticize bad work and the people who do it.

The ISTQB is not part of any community of software testers. They are a business that ignores the rest of the testing world while pursuing their own agenda to line their pockets and promote themselves with misleading advertisements. That’s my opinion, which I have reached through a variety of experiences and investigations as part of being in this craft. One of those experiences is the time that the ISTQB approached me to run their American operation. They spent 30 minutes telling me how great it would be to take advantage of the American market for certification, before they realized I thought it was a terrible idea. After that, I guess they decided that I’m not qualified to have an opinion, since they’ve never paid attention to me since.

I once read Rex Black’s own advertising (promoting ISTQB certification) as part of a keynote speech at the CAST conference– his exact words, mind you– and after reading it I explained why I thought it was misleading. Rex then demanded the return of the money he paid to sponsor the conference.

You might think, yeah, well, of course he should get his money back, until you remember that this was a conference dedicated to free investigation of testing ideas, and not a get-out-of-criticism-if-you-pay-a-fee show. CAST is a free speech zone.

I hope that testers will recognize these opportunists for what they are and begin to fight back. I’m glad that Pradeep is doing just that.

I’m well known for promoting philosophy. By philosopher, I mean someone skilled in the exploration, analysis and clarification of meaningful ideas and the processes by which we arrive at those ideas. Since software is made of ideas, that sounds like testing to me. So, if you want to be an excellent all-around tester, I think you need to think like a philosopher.

(Of course, I have critics who dispute this, but there’s a funny thing– in order to form a coherent argument against my point of view you would have to do philosophy, and that very process would tend to undermine your credibility. Kinda like beating someone to death to prove that pacificism is best!

If you really believe you don’t need philosophy to be a tester, a more effective move would be to refuse to argue. Just use coercion and manipulation to get your way. This is what most of the certificationists choose to do. The harsh light of reason and open debate is a kind of acid to them.)

Promoting the practice of philosophy in daily work is a somewhat lonely job, because our schools manage to turn it into drab and awful subject. I persist for only one reason: I have a drive to be an excellent tester, and I want to help other testers be excellent, too. Otherwise, I would have given up long ago.

Enter Tawney Gowan. Tawney is a somewhat hyperactive young woman from Montreal who attended my STAR East tutorial called “How to Teach Yourself Testing.” She’s been a tester for a few years, but she recently went back to school to study the history ideas. After the class, she came up to me and complained that my citation of Thomas Kuhn’s theory of paradigms in scientific revolutions was out of date. I was tickled that she had an opinion on that, since so few testers have read anything about it.

After a few minutes of hearing her rant, I thought I would buy myself some time. So I asked, “Can you put together a reading list of the things you think I need to stufy?”

She replied, “I already have.”

I just think this is cool. It’s the kind of service I need from a colleague. I hope that Tawney stays in testing and starts a blog.

Here’s to testers who are fearless learners!