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, 17 Mar 2005

Design-Driven Test-Driven Design (Part 1)

At the Canadian Agile Network workshop earlier this week, Jeff Patton had what we think could be a great idea:

  • The conceptual connection between Interaction Design and programming can be the Presenter class (from Model View Presenter).

  • The performative connection can be Fit DoFixture scripts.

To illustrate, I'm going to walk through a user experience (UX) design from the beginning, through workflow design, into a Fit representation of a workflow, finishing off with test-driven design using Fit and JUnit. This recapitulates and extends what Jeff and I did during an action-packed 26 hours in Calgary.

We pretended we were constructing a medical records system for my wife (something close to her heart right now). We went through Jeff's normal UX process. He was the UX designer; I filled in for Dawn and the other users.

First, we talked about system goals, together with measurements. There were two goals:

  1. Make tracking of cases easier without increasing clinician work, measured by clinician time spent on writing medical records.

  2. Reduce the time to respond to medical records requests, measured by the time it takes the records manager to collect complete patient records.

We talked about where the software would be used, its usage context. One place is pretty typical: a reception office where secretaries meet clients. The other isn't: the patient ward. Since this is a ward for large animals, it's rather noisy, messy in spots, and has limited computer access.

We developed personae representing four kinds of users. Dawn is a representative clinician (teaching professor), Jamie is a representative caregiver (who can be either a clinician or a medical student), Hazel is a secretary who handles the creation of records and things to do with money, and Bill is a record keeper who tries to respond to data requests in the face of caregivers who are, in his view, insufficiently appreciative of order.

These personae would be turned into big pictures on the wall of the project bullpen. Acting as Big Visible Charts, they'd constantly remind the team of who they were building the system for. When the team had underconstrained decisions to make about the user experience (which will always happen), the posters would help them make decisions the users would like. In the absence of a reminder, people tend to make decisions that they themselves would like. Trust me when I say that veterinarians are different from programmers.

I then brainstormed a list of tasks that the different kinds of users have. I wrote them on cards. Jeff asked me to arrange the cards so that tasks done by similar people at similar times are close to each other (an affinity diagram). You can see from the picture that we picked only a small subset of the tasks that would be supported by a real medical records system.

Each cluster of cards can represent a "place" in the software that people visit to do a set of related tasks. In the jargon, such places are interaction contexts. From the set of places, you can create a navigation map that shows how people get from place to place and a wireframe diagram of a place's visual appearance.

Jeff's wireframe is patterned after a typical email client. The top pane contains a list of cases (like a list of email senders & subjects). Click on a case, and the bottom pane fills up with information about it. The bottom pane has tabs because there are three kinds of information caregivers will want to look at. Sometimes they'll be filling in that morning's SOAPs (subjective [observations], objective [observations], assessment, and plan), sometimes making notes throughout the day about observations made or orders given or orders filled, sometimes digging into a case's history.

I then wrote an example of how a caregiver would use that interaction context. The tricky thing was to write it so that it supported navigation and key tasks while remaining resistant to changes in the wireframe. The script below will be easier to follow, probably, if you substitute "pane" for "context". I used bolding to highlight changes in contexts and italics to draw attention to what happens after a user action.

com.testingthought.humble.fixtures.dofixtures.InteractionDesign

At the beginning of the day, the caregiver navigates to the the SOAP context and fills in today's SOAP.


the starting context is inpatient
choose patient Betsy with owner Rankin
now the patient detail context names Betsy

navigate to the SOAP context
now the patient detail context shows yesterday's SOAP record
choose to enter a new record
now both the SOAP context and SOAP entry context are visible
(The SOAP entry context lets you enter today's SOAP while still viewing yesterday's. On a Mac, for example, the entry panel might slide out from the side of the main window.)

record that the animal is BAR
record that its temperature is 99.5
indicate that the SOAP is finished
now the SOAP entry context becomes invisible
note that the patient detail context shows today's SOAP record

That's both an natural-language description that a veterinarian can follow (I just checked) and a DoFixture script that a programmer can implement. The next installment will talk about how.

## Posted at 19:33 in category /fit [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