Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick

191.8

⇒

167.2

⇒

186.2

183.6

184.0

183.2

184.6

Thu, 19 Apr 2007

New blog

Tumultuous change hereabouts. After a mere 23 years, I've stopped using emacs for writing code (having switched from it to TextMate for Ruby). And after a mere four years, I've switched my blogging tool from blosxom to Wordpress. Yes, there are comments. They may even work.

You may thank Kevin Lawrence for finally shaming me into making the weblog switch, and American Airlines for getting my wife to London twelve hours late (so far), which gave me the time to write an incredibly long first entry (my SPA 2007 keynote).

The new blog's address is http://www.exampler.com/blog. Things like the blogroll and look'n'feel customization won't happen soon (since it appears my wife is on the plane and the plane is in the air).

This is the another step in my multi-decade switch from testing.com to exampler.com. "Exampling", though not a verb, is a better description of what I do now. It includes testing, but has a larger scope.

## Posted at 15:00 in category /blog [permalink] [top]

Tue, 27 Mar 2007

An open letter on open letters

I'm in England, jetlagged. Some person from the States just called my cell phone / alarm clock with a wrong number at 3:00 a.m. local time, and I can't get back to sleep. I am therefore going to do something I will regret in the clear light of morning.

The Agile Alliance recently published its position on certification. I wrote it. I was told last evening, and I believe it, that people have been interpreting it to have the message "you better get certified if you want a job in Agile." I have long maintained, as a matter of both principle and practice, that a misunderstood message is the fault of its sender. But Jeez Louise, the letter is pretty explicit:

... We also believe that employers should not require certification of employees.

... there are many skilled practitioners who are not certified. Excluding them from consideration would be a poor business decision.

The last few years have smacked me in the face with that kind of thing over and over. People are so apt to jump to conclusions, to assume that any unknown motive must be a bad one, to focus on pointing out weakness to the exclusion of helping shore up strengths. Trying to accomplish something positive is just too damn much frustration not to get paid for it. I say it's spinach, and I say to hell with it.

## Posted at 20:29 in category /junk [permalink] [top]

Mon, 19 Mar 2007

PNSQC Call for Papers

The Pacific Northwest Software Quality Conference is one of my favorite conferences. I think it usually runs about 200 people, so it's small enough to meet people. As a regional conference always in the same place (Portland, OR, USA), there's a continuity of attendees that allows some papers to be less introductory than in other conferences.

They tell me:

Once again we are closing in upon the deadline for submitting abstracts for the Pacific Northwest Software Quality Conference. This year is our 25th anniversary and our conference theme is "25 Years of Quality - Building for a Better Future." We would especially like to hear from people (like you) who have submitted papers in the past.

This year we have a new submission process revolving around the Conference Management Tool from Microsoft. You can submit via https://msrcmt.research.microsoft.com/PNSQC2007/Default.aspx

The deadline for submissions is March 31, 2007 for our conference on October 8-10.

## Posted at 10:42 in category /conferences [permalink] [top]

Sun, 11 Mar 2007

Jeremy Stell-Smith

I need a picture of Jeremy Stell-Smith to use as decoration for my SPA 2007 talk. (It's background for a story about an epiphany I had while pair programming with him.) I no longer have his email address. If you do, could you forward this request to him? Thanks.

## Posted at 09:12 in category /conferences [permalink] [top]

Vivid examples

"In the first part of the experiment, subjects read about a court case involving drunk driving. The defendant had run a stop sign while driving home from a party and collided with a garbage truck. No blood alcohol test had been done, and there was only circumstantial evidence to go on. The defendant was arguing that he was not drunk.

After reading a description of the case and the defendant, subjects were divided into two groups and given eighteen individual pieces of evidence to read: nine written by the prosecution about why the defendant was guilty, and nine written by the defense about why the defendant was innocent. Subjects in the first group were given prosecution evidence written in a pallid style and defense evidence written in a vivid style, while subjects in the second group were given the reverse.

For example, here is a pallid and vivid version of the same piece of prosecution evidence:

• On his way out the door, Sanders [the defendant] staggers against a serving table, knocking a bowl to the floor.

• On his way out the door, Sanders staggered against a serving table, knocking a bowl of guacamole dip to the floor and splattering guacamole on the white shag carpet.

And here's a pallid and vivid pair for the defense:

• The owner of the garbage truck admitted under cross-examination that his garbage truck is difficult to see at night because it is grey in color.

• The owner of the garbage truck admitted under cross-examination that his garbage truck is difficult to see at night because it is grey in color. The owner said his trucks are grey "because it hides the dirt," and he said, "What do you want, I should paint them pink?"

After all of this, the subjects were asked about the defendant's drunkenness level, his guilt, and what verdict the jury should reach.

The results were interesting. The vivid vs. pallid arguments had no significant effect on the subject's judgment immediately after reading them, but when they were asked again about the case 48 hours later -- they were asked to make their judgments as though they "were deciding the case now for the first time" -- they were more swayed by the vivid arguments. Subjects who read vivid defense arguments and pallid prosecution arguments were much more likely to judge the defendant innocent, and subjects who read the vivid prosecution arguments and pallid defense arguments were much more likely to judge him guilty.

The moral here is that people will be persuaded more by a vivid, personal story than they will by bland statistics and facts, possibly solely due to the fact that they remember vivid arguments better."

—Bruce Schneier, "The Psychology of Security"

This all seems to have some connection with tests-as-examples. It is probably useful for an example to be memorable. We want it to come to someone's mind at the moment it's relevant, not be something that has to be looked up.

That implication may clash with my usual advice to strip a test down so that each word that appears in it is essential to its purpose. (So, for example, the only tests that would mention a user's username and password would be tests about logging in.) It is the added detail in the stories above that make them memorable.

It may also clash with my advice to keep tests simple, at least at first. Complex, even humorous, soap opera tests (reg. required) like the following are more memorable partly because of the complexity.

"A customer named Marick hires a car for a three-day business trip. (This, by the way, gives him enough rental points to reach Preferred status.) Midway through the rental, he extends it for another week. Several days later, he calls to report the car has been stolen. He insists that the Preferred benefit of on-site replacement applies, even though he was not Preferred at the start of the rental. A new car is delivered to him. Two days after that, he calls to report that the "stolen" car has been found. It turns out he'd mis-remembered where he'd parked it. He wants one of the cars picked up and the appropriate transaction closed. Oh, and one other thing: the way he discovered the mislaid car was by backing into it with its replacement, so they're both damaged..."

It does support my habit of using real people (or personas of same) as test data. The above was partly inspired by my perennial inability to remember the make, model, or color of my rental car when I walk out of the hotel in the morning. My various veterinary clinic examples feature clinicians based either on real people or stereotypes (the impatient, judgmental surgeon).

(I should note the danger of using real people - by focusing always on a limited subset of the potential users, you become even more likely to overlook examples relevant to people outside that subset.)

In any case, I bring up Schneier's quote because this kind of thing will be important if tests ever take their place as a communication and discover tool, in addition to a bug-finding tool.

## Posted at 09:11 in category /examples [permalink] [top]

Fri, 23 Feb 2007

Need product directors for London workshop

I'll be in London at the end of March. While I'm there, I'd like to have a little workshop for Scrum product owners, XP Customers, and product directors. These are the people who:

• take work estimates from teams and decide what stories (backlog items, chunks of work) should be tackled in the next sprint or iteration, and

• make that decision based on the business value of the stories.

I believe those people have the hardest job on Agile projects. They are also the most likely to be isolated: programmers talk with programmers, testers talk with testers, but these people often have no peers to talk to.

The dates will be on the 29th and 30th of March (total time one and a half days). There'll be some fee to cover expenses (not exceeding £50). We'll select people on the basis of one-page statements of the problem they had and solved.

People who are programmers, testers, and project managers can also come, but product directors will have precedence.

I'm sending this note to gauge interest and decide whether to book the room (at the Royal Statistical Society, 12 Errol Street, close to the Barbican centre). Please forward it on to likely candidates.

I'll decide on March 2, based on how many product director types send me mail saying they're interested.

Questions to me: marick@exampler.com.

The format.

• Volunteers describe their experience, most often the way they solved a problem. The presentation is informal (no Powerpoint). Attendees help them by asking clarifying questions.

• After the story has been told, there is a moderated discussion that concentrates on the solution: what drawbacks might it have? where is it applicable? what have other people done in similar situations?

• There is no time limit on presentations or discussion. The moderator will let it go on as long as there's energy around the topic. (That means that not everyone will get to present.)

Depending on interest, we may also have lightning talks or breakout sessions.

This format is a variant of the one used in the Los Altos Workshop on Software Testing.

## Posted at 08:39 in category /agile [permalink] [top]

Thu, 22 Feb 2007

Can business-facing tests make everyone happy?

Fit has some problems:

• Tables turn out to be the exactly right language for only a restricted set of problems. Other problems can be squeezed into that format, but awkwardly. For those people who get new ideas while explaining things in writing, the awkwardness gets in the way of those ideas.

• Everyone hates editing HTML. That's true even if you're editing it with Word or Open Office. I don't think either one of them is all that great about handling tables, and HTML tables are noticeably more painful than native document format tables.

• Programmers don't like using Fit because they have to leave their programming environment. It's also arguably harder to write support code for Fit than for JUnit (though I'm not convinced).

Maybe I'm groping toward a solution.

Here is a Fit table that talks about a data conversion that's driven by a configuration file:

That looks reasonably attractive. You'd be appalled if you knew how much time I spent on it.

Here is the same test in a different format:

That's an OmniGraffle file. I think it required less fiddling to create. Updating seems to be easier. I think it would be more useful as documentation than the previous test would.

What I've done behind the scenes is extend my existing Graffle parser to handle files like this. I still use the Fit engine behind the scenes, as you can see from the output:

Not so nice to read, but how many product directors really look at test output?

Now the question is: how could this use JUnit as the test execution engine instead of Fit?

Then the question after that is whether I could use a less obscure app than OmniGraffle to generate the tests. Anything that puts out XML should be roughly the same difficulty.

## Posted at 14:49 in category /fit [permalink] [top]

Tue, 20 Feb 2007

Pictures of team rooms, walls, etc.

Here are three sites that use pictures to show what Agile artifacts and physical environments look like.

Bill Wake
Rachel Davies
William Pietri

## Posted at 07:20 in category /agile [permalink] [top]

Sun, 18 Feb 2007

Two interviews

Two interviews with me recently went online. The first, at On Ruby, is about Ruby, amazingly enough. Also about Everyday Scripting with Ruby. The second is from Dr. Dobb's and is mainly about testing in Agile projects. A lot of overlap with this blog.

## Posted at 14:05 in category /misc [permalink] [top]

Recover forward

While I'm talking about metaphors...

A very long time ago, I learned to fence. What you see above is a lunge. A lunge moves you from a defensive posture to an attacking one—you're trying to stab the other person. But notice that the figure is balanced. Its center of gravity is between its feet, and it could remain in that position without tipping either forward or back.

If its opponent counters the attack and launches a counterattack, it could recover backward by pushing off the front leg, snapping the back arm up, and reassuming the original en garde position:

But suppose the opponent retreats away from the attack. Then our lunging figure can recover forward: keeping the center of gravity as is, pull the back leg in and curl the back arm. Now it's ready to keep pressing the attack: it can lunge again or move forward in a more guarded way.

The important thing here is that—despite the failure of the original attack—the manner in which it moved forward allows it to keep moving forward.

Software teams often seem to be unable to recover forward. If they make a wrong decision, they land off balance:

The can scramble awkwardly backward (svn revert), leaving them worse off than before:

Or they can bull forward along a path they would not have chosen, had they known then what they know now, jabbing repeatedly and getting more and more off balance:

What they're unable to do is make use of where they are to take what now appears to be the best path:

For those of us who are merely mortal, it seems the best way to be able to recover forward is to practice the right stance. Get yourself into lots of situations where you end up going down the wrong path. Instead of reverting backward to a known stable state of code, add and rearrange code to move forward.

A good way to get yourself into those situations is by only writing the code that's needed for the small feature you're working on right now. Then some later small feature will make you recover forward—and learn about how your stance is imbalanced.

Some people believe you can recover forward from pretty much anything. (Ron Jeffries' Extreme Programming Adventures in C# demonstrates recovering forward from a design that doesn't support undo to one that does.) Others don't. I don't know what my opinion is, but I believe most people could recover forward a lot more than they think they can, if they practice.

The trick is persuading them to practice.

Credits: I learned to move forward instead of revert from Zhon Johansen. The first photo is from Dr. Stephan Dann and is licensed under the Creative Commons Attribution-ShareAlike 2.0 license. The second photo is from http://www.tcnj.edu/~fencing/glossary.htm; there's no copyright notice, but it looks to be from an old fencing book.

## Posted at 14:05 in category /agile [permalink] [top]