I consult mainly on Agile software development, with a special focus on how testing fits in. Contact me here: marick@exampler.com
Now, chastened by our modern knowledge of the limitations of knowledge, of reason, of ourselves, we know that those bright certainties are not as certain or as real as we once thought. But we’ve spent our time mourning, in depression and cynicism and irony, and we’ve all been taught that, if truth is a slippery and uncertain thing, lies are very real.
Mark Bernstein, from his series on NeoVictorian Computing, specifically part 3, Age of Heroes.
When I was first courting Dawn, she taught me two surgeons’ mottos: 
Get in, get done, get out
Minimize time, trash, and trauma
(”Trash”, here, is foreign material introduced into the body.)
I’ve been fond of repeating these, but I now realize the first one is bad advice for programmers. It should be:
Get in, get done, improve, get out
You see, while a surgeon is in there fixing one problem, she might also fix another one she discovers, but there’s not really any practice like refactoring. Maybe there ought to be, since your body is a gross kludge, but there isn’t.
The un-amended version of the motto puts too much weight on time and will almost certainly lead to a slow decay of the code.
The second motto, then, should be something like:
Minimize time and trauma,
but don’t forget to pick up any trash lying around
Not nearly so catchy.
A transcript of an OOPSLA talk: Table of contents
Update 1, update 2, update 3: Added links to some useful reviews.
AGILE 2008 CONFERENCE in Toronto, August 4-8, 2008
Anyone who is involved in, or wants to learn more about, agile development is invited to participate in this exciting conference!
Agile2008 conference is run as a program of Agile Alliance. We are scaling up the conference for an ever-increasing and diverse agile community. After the sell-out of Agile2007 we are expanding to a larger venue which can hold an audience of 1600+ attendees!
To facilitate this growth, Agile 2008 has adopted the metaphor of a music festival that provides multiple stages to attract audiences with common interests. The stages within our program are designed and organized by experts (acting as stage producers) who are truly passionate about their particular areas.
“We can’t stop the conversation at ‘I just did that and I’m a user.’”
The “no user would do that” retort is the bane of testers. Ben talks well about moving the conversation past that. But a step further: any project I’d want to work on is a learning project, one that wants to be less wrong than yesterday, one that likes finding out about mistakes. Get past this particular conversation: fine. Maybe testers could even train programmers to swallow that particular reflexive retort. But the defensiveness about having partial understanding will still leak out other places.
Now, I once sat down with Elisabeth Hendrickson while she tested an app of mine. I’d built it with TDD to the max: business-facing tests all the way down to unit tests. It took her about ten minutes to find a high-priority bug. I immediately slipped right into the defensive programmer stance. It took me a few minutes to snap out of it. But if we worked together for longer, I’d like to think I’d get past that.
I aspire to be like Mark “capabilities” Miller, a programmer I once worked with. When someone found a bug in his code, he’d write a long email about it, praising the person, attributing all sorts of cleverness to her, and explaining how he’d come to make that mistake.
“People often recommend that you treat a bug as a story. […] I think this approach is incorrect. We’ve found a better way to handle [bugs].”
I want to disagree with Bret, but I haven’t come up with a counterexample that convinces even me.
“What happened here was the gradual habituation of the people, little by little, to being governed by surprise; to receiving decisions deliberated in secret; to believing that the situation was so complicated that the government had to act on information which the people could not understand, or so dangerous that, even if the people could not understand it, it could not be released because of national security….
“And one day, too late, your principles, if you were ever sensible of them, all rush in upon you….The world you live in — your nation, your people — is not the world you were born in at all. The forms are all there, all untouched, all reassuring, the houses, the shops, the jobs, the mealtimes, the visits, the concerts, the cinema, the holidays. But the spirit, which you never noticed because you made the lifelong mistake of identifying it with the forms, is changed.”
Here are some links I will point to when people ask me about test design. Add more in the comments and I’ll promote them to the main posting.
Mnemonics
Michael Bolton on:
SF DePOT (Structure, Function, Data, Platform, Operations, and Time) here and here
CRUSSPIC STMPL (capability, reliability, usability, security, scalability, performance, installability, compatibility, supportability, testability, maintainability, portability, and localizability)
HICCUPPS (History, Image, Comparable Products, Claims, Users’ expectations, the Product itself, Purpose, Statutes)
See also various of Bolton’s articles.
Adam Goucher on SLIME (Security, Languages, requIrements, Measurement, Existing)
Jonathan Kohl on MUTII (Market, Users, Tasks, Information, Implementation).
Michael Kelly on test reporting with FCC CUTS VIDS (Feature tour, Complexity tour, Claims tour, Configuration tour, User tour, Testability tour, Scenario tour, Variability tour, Interoperability tour, Data tour, Structure tour)
Ben Simo on testing failure handling with FAILURE (Functional, Appropriate, Impact, Log, UI, Recovery, Emotions)
Scott Barber on designing model workloads for performance testing with FIBLOTS (Frequent, Intensive, Business Critical, Legal, Obvious, Technically Risky, Stakeholder Mandated). (He has others that are outside the scope of this posting.)
Other reminders
Mind maps
Bob Warfield on Using mindmaps to explore user interaction and create QA test plans
Eric somebody on Using mind maps to explore user interaction
Online course materials
Black box software testing materials from James Bach, Cem Kaner, Michael Bolton, and others.
Books
A Practitioner’s Guide to Test Design, by Lee Copeland
Lessons Learned in Software Testing, by Cem Kaner, James Bach, and Bret Pettichord.
Things that ought to be in books
Videos
Cem Kaner has various Black Box Software Testing videos.
Thanks to Michael Bolton, Adam Goucher, Matthew Heusser, Jonathan Kohl, and Chris McMahon for links.
A transcript of an OOPSLA talk: Table of contents
Here is the table of contents for a set of postings that, together, are a transcript of an OOPSLA talk on Bruno Latour and Actor-Network Theory (ANT). I will add links as I post new entries.
Testing as an example: I use Actor-Network theory as a way to get ideas while consulting. Here’s one example.
ANT and the building of the social: ANT is about tracing how “actors” (people and things) in a story push on each other. Stable patterns of interaction produce social objects like neighborhoods.
Anthrax and standups: ANT analyses often give uncommon weight to inanimate objects. How that gave me an idea to make standups less dull.
The divide: Early Agile, especially XP, had an ANTian delight in the interplay between the social and tools. That’s being lost. Someone should do something about it.
A transcript of an OOPSLA talk: Table of contents
Shift gears now to the daily standup. There’s a ritual: someone says what she did yesterday, what she plans to do today, and what impediments she sees in the team’s path. Good standups are crisp and motivating. A lot of standups are bad. They have the enervating effect of an hour-plus weekly status meeting, only spread out over a week.
Why is this? And what can be done about it?
To answer, I’ll start with the story of the anthrax bacillus from Latour’s The Pasteurization of France. At one point, there was a disease called “anthrax.” People understood the properties of this disease: they knew what symptoms it had, they knew that people could contract the disease from warm corpses but not from cold or rotten ones, and they knew that some “accursed” fields gave anthrax to any animal that grazed there.
Pasteur wanted to replace anthrax-the-disease with anthrax-a-bacillus. He undertook a fairly systematic programme:
Early on, he could induce the symptoms of anthrax by extracting icky stuff from a sick animal, diluting it fantastically, and then injecting a tiny bit of the dilute solution into a new animal. However: so? No one sneaks around at night injecting cows in fields.
So the next step is to induce anthrax by a more natural means. They tried feeding the animals hay laced with anthrax, but that didn’t give them the disease. However, a feed more representative of real life—feed containing prickly nettles—did. So there’s a realistic way animals can get the disease that’s directly traceable to the idea of injection.
What about the slaughterhouse workers and the safe corpses? Well, it turns out that anthrax forms spores to ride out harsh environments: like the cold, nasty environment of a dead animal. That’s a plausible explanation for what renderers know. One more bit of anthrax-the-disease can be explained in terms of anthrax-the-bacillus.
There’s even a reason for accursed fields. Suppose someone buries an animal dead of anthrax. You’ve basically buried a whole pile of spores. In dirt. That contains earthworms. One of the things that earthworms do is turn dirt over, moving dirt from down below to the surface. As a side-effect, they steadily replenish the surface with spores. Result: an accursed field, perhaps accursed well after the last person’s forgotten anything was buried there.
And, finally, you can do more with the bacillus than you can with the disease. In particular, you can make a vaccine.
At some point, anthrax-the-disease can be understood in terms of anthrax-the-bacillus. Roles switch: now if you want to say something about the disease, you have to be prepared to trace that statement back to the bacillus.
In the jargon, the bacillus has become an obligatory point of passage.
One of the things we’ve done in Agile is to make the frequent creation of running, tested, potentially shippable software into an obligatory point of passage. Teams that don’t produce potentially shippable software at the end of each iteration are likely in trouble. Moreover, team members ought to be able to trace what they’re doing to the goals of the release; if not, they ought to be prepared to question what they’re doing.
In order to understand and pace the work of the release, it’s convenient to break it down into smaller pieces, individual stories. The stories are also individual points of passage, just littler ones.
Dull standups often make no reference to visible stories. Either people don’t have a wall with stories on it, they don’t do the standup in front of that wall, or they don’t gesture at the wall while speaking. In ANTian terms, they’re demonstrating that the stories aren’t really obligatory points of passage. What to do about that?
Another trick of ANT’s is not to bother making a distinction between humans and other kinds of actors. So, when Kent Beck writes, in the introduction to Smalltalk Best-Practice Patterns, “If you’re programming along, and all of a sudden your program gets balky, makes things hard for you, it’s talking,” an ANT analysis wouldn’t report that with a side-comment like “Of course, programs don’t really get balky.” Lots of programmers talk as if code can push back, so why not take them at their word and see what comes of that?
A while back, I was thinking along these lines when I realized that if the stories are so important to the project, they ought to be the ones speaking in the standup. I imagined a story card saying, “Brian’s going to keep working on me today, but he’s having trouble. He could use the help of someone who knows Hibernate.”
Now, I never had the nerve to actually suggest that team members ought to hold the story cards like little mouths, open and close them, and pretend it was the stories talking, but while I was preparing for this talk, I had another thought. Yes, the stories can’t talk, but there’s no reason not to structure the standup around them. Instead of going around the people, you can step through all the stories in play. For each, someone can say what happened to that story yesterday, what’s to be done on it today, and whether there are any risks to its completion.
I plan to recommend that clients give this a try. At least, it will cut out conversational deadeners like “I paired with Dawn and Karl, so I did the same thing they did” and “I can’t remember what I did.” [I’m also pleased that two people said they’d try it on their teams when they got home.]
So, there: another example of using a weirdo theory from sociologist to give myself ideas.
Story board from arbdesign.dk, woman with fish from Willem Velthoven.
From November 30 through December 2, I’ll be at the free Simple Design and Test Conference in Pennsylvania. I’m going to try to spend some time this month thinking of something fun and enlightening and experiential to do. Here’s the official blurb:
After the great response from the last year’s, first Simple Design and Testing Conference [SDTConf] in WestChester, PA, we are planning to organize another conference this year.
Dates: Nov 30th - Dec 2nd
Venue: Penn State University York, PA.
Target Audience: Developers, Designers, Architects, DBAs and Testers
Conference fee: Free.SDTConf is focused on providing Agile practitioners a platform to meet face-to-face and discuss/demonstrate simple design & testing principles/approaches. The conference will use Open Spaces to structure conversation, improve understanding, facilitate brainstorming and help innovate.
This conference is not just limited to discussions; we are also planning an exclusive track for hands-on-sessions. This session will give practitioners a platform to work on some of key design and testing issues.
Online registrations [http://www.sdtconf.com/reg.htm] are open now. If you plan to attend this conference, please register ASAP, as we have only 115 seats left.
We are also looking for sponsors, who can sponsor in kind. Ex: Conference T-Shirts, Food, Stationary, etc
Please feel free to forward this announcement to anyone interested.
Look forward to see you there.
Naresh Jain
http://agilefaqs.com
http://agileIndia.org
http://www.sdtconf.com
