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

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]

About Brian Marick
I consult mainly on Agile software development, with a special focus on how testing fits in.

Contact me here: marick@exampler.com.

 

Syndication

 

Agile Testing Directions
Introduction
Tests and examples
Technology-facing programmer support
Business-facing team support
Business-facing product critiques
Technology-facing product critiques
Testers on agile projects
Postscript

Permalink to this list

 

Working your way out of the automated GUI testing tarpit
  1. Three ways of writing the same test
  2. A test should deduce its setup path
  3. Convert the suite one failure at a time
  4. You should be able to get to any page in one step
  5. Extract fast tests about single pages
  6. Link checking without clicking on links
  7. Workflow tests remain GUI tests
Permalink to this list

 

Design-Driven Test-Driven Design
Creating a test
Making it (barely) run
Views and presenters appear
Hooking up the real GUI

 

Popular Articles
A roadmap for testing on an agile project: When consulting on testing in Agile projects, I like to call this plan "what I'm biased toward."

Tacit knowledge: Experts often have no theory of their work. They simply perform skillfully.

Process and personality: Every article on methodology implicitly begins "Let's talk about me."

 

Related Weblogs

Wayne Allen
James Bach
Laurent Bossavit
William Caputo
Mike Clark
Rachel Davies
Esther Derby
Michael Feathers
Developer Testing
Chad Fowler
Martin Fowler
Alan Francis
Elisabeth Hendrickson
Grig Gheorghiu
Andy Hunt
Ben Hyde
Ron Jeffries
Jonathan Kohl
Dave Liebreich
Jeff Patton
Bret Pettichord
Hiring Johanna Rothman
Managing Johanna Rothman
Kevin Rutherford
Christian Sepulveda
James Shore
Jeff Sutherland
Pragmatic Dave Thomas
Glenn Vanderburg
Greg Vaughn
Eugene Wallingford
Jim Weirich

 

Where to Find Me


Software Practice Advancement

 

Archives
All of 2006
All of 2005
All of 2004
All of 2003

 

Join!

Agile Alliance Logo