For the first time in a long time, I am prepared to endorse a new trainer of the Rapid Software Testing class: Paul Holland.

Paul has been a tester and test manager at Alcatel/Lucent for something like 17 years. In recent years he has been using and teaching Rapid Software Testing methodology within Alcatel. His practical experience is fabulous.

But that’s not why I’m happy to have him working for me. There are a lot of experienced people in the world.

He is a pilot. He flew Sea King helicopters for the Canadian Navy. The thing about pilot training is that it is similar to good tester training. You have to practice, practice, practice. I’m a pilot, too. Most of my family flies airplanes. My approach to training is much influenced by that experience.

Still, that’s not really why I’m excited.

I’m excited because Paul enjoys an excellent reputation within the Context-Driven community as a facilitator of peer conferences. He’s irreverent. He’s an innovator. That’s important, because anyone who teaches my class must make it his own class, too. Paul has the right temperament for that.

Paul’s teaching style is a bit less aggressive than mine (as is Michael Bolton’s), if you like that sort of thing. He will teach through Satisfice, Inc., so if you want him to do a class at your site, contact me.

Bharani from India is a novice tester who appears to have a lot of energy. She recently emailed me this:

I am asked many questions by testers. This particular one reveals a lot about the questioner. For one thing, she thinks differently, because I have never been asked this. And it’s a question about discipline, so perhaps she’s a tester who is truly serious about developing herself.

My first answer is the same as the one my world famous writer of a father so often gives: write.

Write every day.

For me this takes the form of carrying my Moleskine notebook everywhere I go (now with a bandolier for my pens!). Whenever I find myself with a few moments, I make notes of my thoughts about testing and technical life. My notebooks serve as one source of great new ideas for my consulting and teaching.

But for testers, there are a few more practices to keep in mind…

Watch yourself think ever day.

While you are working, notice how you think. Notice where your ideas come from. Try to trace your thoughts. This is not easy. You have to practice to improve your skill of self-observation.

As a tester, you must become an artist of your thoughts, you must learn to see the structure and gain control of the structures by which you notice what no one else notices. These structures are not simply “intuition” or “common sense.” We can do better than that.

Question something about how you work every day.

Testers question things, of course. That’s what testing is. But too few testers questions how they work. Too few testers question why testing is the way it is.

For example: Why do we talk about tests “passing” and “failing”, instead of talking about whether there are problems? Do all bugs need to have steps to reproduce? How do we decide when to write a test down and what steps need to be written?

Explain testing every day.

The ability to explain testing is linked to nearly every other testing skill. Even if no one makes you explain your methodology, you can explain it to yourself. Do that. Practice doing it by voice and in writing. Don’t rest with buzzwords. Don’t tell yourself that you did “black box testing.” Break it down. Explain what you did specifically and explain why you did it.

I’m delighted that Rob Sabourin, creator of the Just-In-Time Testing class, will be with us during the Rapid Testing Intensive, in July. He’s coming as a student, but you know, we’re ALL students of the craft, so I’m going to put him to work. Big time. We will also have Ajay Balamurugadas onsite. He’s among the most famous of the Indian Context-Driven testers.

As I figured, most of the sign-ups have been for online participation. So far, we have six onsite students, plus my brother and I. I imagine we’ll get a couple more before all is settled, but still– a small group. It’ll be like a team of commandos.

If you want to work shoulder to shoulder with us, getting on-the-job test coaching during five long days, sign up soon. The early bird discount runs out in a few days.

As I was having dinner with Noah Höjeberg tonight, he said an interesting thing. “Some people think testing is mechanical, and that’s bad enough. But a lot of people seem to think the alternative to mechanical is magical.”

(Noah is the new test strategist at Scila AB, in Stockholm. Interesting guy. I’ve played a lot of testing dice with him, in the past. I meant to do the Art Show game with him, too, but we got so much into our conversation that I completely forgot.)

Mechanical and magical are false opposites. In Rapid Testing, we pursue another path: Heuristical. In other words, skilled testing, achieved through systematic study and the deliberate application of heuristics. This is neither a mechanical, algorithmic process, not is it magical, mystical. We can show it, talk about it, etc. And yet it cannot be automated.

I did not invent sympathetic testing. Anyone who says I claim to have invented it will have only read the title of this post, but nothing further. Now you know.

I may have been the first in my circle to recognize one specific benefit of sympathetic testing. But if so, that is a minor technical point. Because I know that my recognition came directly from a point of view championed by Cem Kaner. From where I stand, it came largely from him.

Okay, James, this is a bit confusing. Why are you talking about this, today?

Ajay Balamurugadas came to me today asking if I came up with the idea of “sympathetic testing.” This is an idea he’s found in Mike Kelly’s work, which derives partly from my work (on tours). It’s also in the section of Lessons Learned in Software Testing that I wrote (and which was edited by Cem Kaner and Bret Pettichord). He had already asked Cem Kaner, who said he got it from my brother [correction: Ajay tells me he saw Cem say that on a video]. But if so, I know exactly where Jon got it: from me, during a project we worked on around 1997. That’s where he was working for me on a court case where I had to do an analysis of “good enough” quality, using a method strongly influenced by Cem’s thinking about cognitive biases.

I’m talking about this today because the provenance of ideas can be confusing when people work closely together. Who cares who invented it, or named it? You might be surprised. Credit is important to people who live by their reputations in a world of ideas. Reputation is money, to put it bluntly. To achieve high income and control over your work as a tester, one way– and the only way I know, actually– is to build your public reputation. Moreover, a lot of our motivation is the respect of our peers. Therefore, this matters.

This isn’t really about “sympathetic testing”, then. Still, what IS sympathetic testing?

Sympathetic testing, as I think of it, is sometimes slightly confused with the closely related ideas of “happy path” or “positive testing.” Sympathetic testing means testing while affirming (rather than challenging) each assumption, resource, or service. But if that’s all it meant, then it would be the same as positive testing. For me, sympathetic testing means more. It means asking “what is wonderful about this product?” rather than “what is broken about this product?” I can do positive testing all day and still be focused on bugs. With sympathetic testing, I may find bugs, but that is not my focus or purpose– my main purpose is learning; building a rich model in my mind.

The insight I had, when working with my brother (way back before he was a recognized test expert in his own right) was that sympathetic testing made me better at unsympathetic testing. Searching happily prepares me to search aggressively.

Okay, then what’s really troubling you?

What bugs me is that Cem deserves more credit for sympathetic testing. But if he claims it himself, he probably thinks he will anger me, and if he gives me full credit, it would anger him: because Cem and I aren’t on speaking terms, at the moment. (I hope that’s temporary.)

I’m hereby offering him credit. Cem and I collaborated for roughly 16 years. We had probably hundreds of deep conversations about testing. Among those conversations, he lectured me on mental models and biases. We once had a fairly bitter argument about what a model is. He won that argument, thankfully, and I have been comfortable with the outcome ever since. He introduced me to Cognitive Science and pushed me deeper into Epistemology. It was that sensibility that led to me discovering a lot of things: among them the power of sympathetic testing. I’m certain that the first person I ran to with my discovery was Cem, but not only that, this is exactly the sort of thing that he was famous for encouraging: to look at things in a sympathetic way. I can’t remember the conversation itself or what he said. I bet he said something like “That’s just what I’ve been trying to tell you!”

Therefore, “sympathetic testing” is part of our joint work. Between about 1997 and 2007, it’s a good bet that I didn’t have a significant thought about testing which wasn’t also sifted and tested by Cem. We didn’t always agree, but we were extremely close. It’s for that reason that he put my name on his BBST class, even though I didn’t do any direct work on it. He was recognizing my influence on him. I’m doing that now.

I’m my own man. I have reinvented testing for myself (just as I recommend that others do). And yet a few people have deeply influenced me in that process. The three people who have had the most influence on my are my father, Jerry Weinberg, and Cem Kaner. I sometimes joke that I can sell out and offer baloney certifications to gullible testers, just like the ISTQB does– but only after those three men have died and I’m no longer seeking their respect.

[Postscript: Why did I title this piece "How I Invented Sympathetic Testing"? Because it was the best way I could think of to attract the attention of people who might be upset that I would make such a claim. Then maybe they would read this post, and feel a lot better.]

I’ve wrapped up my first visit to Switzerland!

I came to speak at the Swiss Testing Day, which attracted a lot of testers. 800 of them, I’m told. It was a very professional operation.

For me the highlight of the visit was trading puzzles and working through Socratic examinations with various Swiss testers, principally Ilari Aegerter. Ilari (which I discovered after saying his name wrong 100 times actually rhymes with Hillary) is a man with boundless energy to solve puzzles and meet the challenges of his peers. I spent two days plus several dinners quizzing him, pressing him, sparring with him, and accepting quizzing from him.

Today we worked in the ski and cheese town of Engleberg. After getting my need to learn about Swiss cheese out of the way (what we call Swiss cheese in the USA is really “Emmentaler”), we settled in the lobby of the Terrace Hotel with the majestic Alps hovering over us.

Ilari is serious about becoming a testing expert, as well as an expert testing coach. So, we spent all day combing through transcripts of his test coaching sessions, identifying and naming his coaching patterns. We’ll consult with Anne-Marie Charrett and Michael Bolton next, to see how our patterns square with them.

He’s relatively new to test coaching. We agreed he needs to work on his patience. Coaching is a lot like fishing. In a Socratic dialog, you have to set the hook in the student and patiently reel him in.

Otherwise, the transcripts looked good to me.

Yesterday I accepted a challenge from Ilari to describe a picture as completely as possible. It was a lot of fun, so I passed it on to Anne-Marie today, who used a mind-map strategy. Now we have a new testing challenge we can give to willing students. Ilari seems to have set himself the task of becoming Context-Driven testing’s best expert on observation skills and dynamics. He has a lot more reading to do (Metzger’s Laws of Seeing, for instance; and The Science of Describing), but he’s on his way.

Tonight we worked through key bits of a book about validity and reliability in qualitative research, and closed the the evening with several lateral thinking puzzles and two math puzzles.

We’re both kind of tired now. The good kind of tired.

This is my idea of fun.

I staggered out of the Cambridge Press bookstore a bit dazed, today, having gorged on 21 books. [Addendum: I mean by this that I browsed them, purchased them, and had them shipped home.] If you want to know what a Context-Driven tester reads, here it is:

• A First Course in Statistical Programming with R
• Wisdom: Its Nature, Origins, and Development
• Learning and Expanding with Activity Theory
• Sequential Analysis and Observational Methods for the Behavioral Sciences
• Observing Interaction: An Introduction to Sequential Analysis
• Human Error
• Combinatorics: A Problem Oriented Approach (Mathematical Association of America Textbooks)
• A Mathematician Comes of Age (Spectrum)
• The Golem at Large: What You Should Know about Technology (Canto)
• The Golem: What You Should Know about Science (Canto)
• A Practical Introduction to Denotational Semantics (Cambridge Computer Science Texts)
• Dialogic Inquiry: Towards a Socio-cultural Practice and Theory of Education (Learning in Doing: Social, Cognitive and Computational Perspectives)
• From Teams to Knots: Activity-Theoretical Studies of Collaboration and Learning at Work (Learning in Doing: Social, Cognitive and Computational Perspectives)
• Nuts and bolts for the social sciences
• How to Fold It: The Mathematics of Linkages, Origami and Polyhedra
• The Cambridge Handbook of Thinking and Reasoning (Cambridge Handbooks in Psychology)
• The Manuscript of Great Expectations: From the Townshend Collection, Wisbech (Cambridge Library Collection – Literary Studies)
• The Cognitive Basis of Science
• Satisficing and Maximizing: Moral Theorists on Practical Reason
• The Cambridge Handbook of Situated Cognition (Cambridge Handbooks in Psychology)
• Risk Communication: A Handbook for Communicating Environmental, Safety, and Health Risks

One of the challenges I have for the ISTQB proponents is “What do you read?” You see it’s a trap. If they tell me they read widely, deeply and liberally, I contrast that with the intellectual desert that is the ISTQB Syllabus and ask them why there is such a disconnect between their education and their professional claims. And if they read narrowly, well, there you go.

If you want to be an excellent tester, you need a good education. You didn’t get that in school (or if you’re in school, you’re not getting it), so you need to do something like what I do: scout for fabulous and offbeat books about all the matters of great testing– and testing touches EVERYTHING!

[addendum: If you are not familiar with my distaste for institutional education, before picking a fight with me, go see my book, Secrets of a Buccaneer-Scholar. I spent 26 years doing the research by which I assert that school, although not always destructive and occasionally helpful, is certainly not necessary if you want to live a successful intellectual life. Each day of my life is another data point about how wrong were the teachers who told me I would not be successful without submitting to "the game" of school they desired me to play.]

Most of the books on my list are self-explanatory. One in particular may seem strange: the manuscript of Great Expectations. I picked that one up because the photographic images of Dickens’ original manuscript is a beautiful example of how messy the creative process is. Imagine trying to put metrics on the process of writing that, with all its crossouts and insertions.Writing is exploratory. Just. Like. Testing.

Cem Kaner, who controls www.context-driven-testing.com, has announced an interesting change in his view of the Context-Driven School. He says he prefers to think of it in terms of the Context-Driven approach, not a school of thought. This is a significant change from his original view, which was that CDT is a different paradigm.

That means I’m the last of the founders of the Context-Driven School, as such, who remain true to the original vision. I will bear its torch along with any fellow travelers who wish to pursue a similar program.

Polarization? No. Paradigm!

One of the things that concerns Cem is the polarization of the craft. He doesn’t like it, anymore. I suppose he wants more listening to people who have different views about whether there are best practices or not. To me, that’s unwise. It empties the concept of much of its power. And frankly, it makes a mockery of what we have stood for. To me, that would be like a Newtonian physicist in the 1690′s wistfully wishing to “share ideas” with the Aristotelians. There’s no point. The Aristotelians were on a completely different path.

For me, Context-Driven thinking is delightfully about listening to people and talking to people about practices and dynamics of software testing. But this must happen within the humanist framework that we laid out in the seven principles of the Context-Driven school. That’s our world.

Polarization is beside the point. Polarization is a natural consequence of the fact that our world view is simply different. We are a different paradigm. Our paradigm cannot be explained or contained by any other testing paradigm, such as the Factory School, or the Analytical School. We must have the stomach to keep moving along with our program regardless of the huddled masses who Don’t Get It.

Why Is This Division Happening Now?

Cem’s change of position is happening partly because, after 16 years, he and I are no longer collaborators. Due to a simmering personal dispute (nothing to do with testing) that blew up last year, we no longer can stand to be in the same room with each other. Alas, I don’t think this will change. What that means, professionally, is that the conversations that we once had– the passionate arguments– which led to mutual accommodations and syntheses, no longer happen. This is too bad, because the Factory schoolers, who greatly outnumber us, will make good rhetoric out of any appearance of confusion between Cem and I about our visions of testing.

Meanwhile, I will say this about Cem: He’s a great man. His contributions to testing have been enormous. I disagree with him on some aspects of testing, but by and large he does great work. I’m sure if he weren’t so furious with me and I were able to talk to him without feeling an overpowering urge to kick holes in walls (I mean that literally), we would still be able to develop testing ideas together. However, I trust that whatever he does will be worth looking at. And I do have many other bright collaborators, so I’m going to be fine.

The Context-Driven School continues, because I, and those like me, are compelled to pursue excellence wherever it leads us, even if that means breaking with “conventional” software testing thinkers. I wish Cem luck as he consorts with those guys, but I fear his time will be, for the most part, wasted.