Agile Testing with Lisa Crispin

We like small stories. If we keep stories to a size we can finish in two or three days, there is less likelihood of a story “blowing up” because we vastly under-estimated it. Doing lots of small stories every iteration helps us get into a steady rhythm. We can manage our work in process more efficiently and keep cranking stories through.

Some pieces of functionality are too big to fit into a small story, so we have to break them down. This is a hard skill to learn, but trust me, everything can be broken down into smaller chunks, somehow. This can get to be somewhat artificial and go against the principle that a story ought to deliver something of value to the business that we can release. However, we think the tradeoff is worthwhile. When we work on a big new piece of functionality, we simply hide the new stuff by means of properties until it’s ready for prime time. I guess we could branch the code too, but we prefer to work on the main trunk.

If you have some bit of functionality that doesn’t go end to end, how do you test it above the unit level? How can you show it to customers? This requires a bit of extra effort, but again, we’ve found it worthwhile. (My team has been chopping stories ever-smaller for six years now).

Here’s an example. Our application manages 401(k) plans (employer-sponsored retirement plans, to which employees and employers may contribute). Right now we are rewriting the functionality that allows a plan participant to “roll in” money from a 401(k) plan at a previous employer. We also needed to add functionality to allow users to roll in money that is not tax-deferred; this is called “Roth” money. As part of this rewrite we are rewriting the back-end processing.

When this is all finished, users will go to the UI, enter the information about the money they’re rolling in, and when they submit, instructions will be created that will allow us to receive the money and buy appropriate shares in mutual funds on behalf of the participant. One story read something like this: “As a participant, I want the system to be able to create instructions for Roth roll-ins”. Originally the story was to process the instructions, but we realized that was too big a story and cut it down.

There’s no UI yet, and we aren’t even processing the instructions, so how do we test this? The developer created a FitNesse fixture to accept information that users would enter in the UI, send these inputs to the production code, and the code in turn would create the correct instructions. Then we could use a “data fixture” (or we could use DbFit) to verify the data in the database.

I started out by just writing a FitNesse test to execute the fixture with my inputs and verifying the database with my own SQL queries. Then I made an automated regression test by setting up data about the plan and user in the database, operating the fixture to create the instructions, verifying the instructions, and then cleaning up the data. Here is the “meat” of the test. The basic data is set up earlier in the test. The “do” fixture specifies the roll-in data just as the user would in the UI, then sends it to the code which creates instructions in the database. The test then checks the data in the database. We can confirm this code works, even without the UI or ability to process the resulting instructions. And we can try lots of different test cases.

FitNesse Test for Partial Functionality

My teammate Nanda Lankalapalli and I are working on an article about how our team deals with having remote team members. Recently someone on Twitter pointed me to a blog post on Scott Hansleman’s “Embodied Social Proxy or Crazy Webcam Remote Cart Thing“. My fellow tester Lori Thayer suggested I blog about our own crazy webcam remote cart thing, so people can see there are alternative approaches.

I got the “dolly” idea from Maykel Suarez. He and my other teammates set one up for me when I was a remote member of his team. They got the virtual presence idea from Hanselman, but added the dolly idea to make it easily mobile. My “Donkey Dolly” was on a wireless network and could be wheeled even from building to building – it was way fun to wave at people as I wheeled by them, and enjoy the grass and trees outside!

Our “Virtual Nanda” or virtual telepresence device consists of a rolling laptop cart, a good laptop with plenty of memory and speed, a good webcam that can be panned around the room, a good microphone and good speakers. (We definitely need a catchier name for it; since Nanda lives in India, we were thinking along the lines of the Bollywood Dolly). Any team member working remotely who wants to use it can VNC to it, log in, make a video call to it on Skype, and control the audio and video. The mic is good enough that conversations around the room are audible. The speakers are good enough that the remote person can be heard around the room. Here’s a picture.

Virtual Nanda

Here’s another picture showing more of the cart. Instructions for how to use it are taped to the front.

Another View

If more than one person is working remotely and wants to use the Virtual Nanda, we can’t use Skype for video. We still use it for audio, and use Yahoo IM for the video. All the components are securely fastened to the cart so nothing will fall off when it’s rolled around to wherever it’s needed. Unfortunately using a wireless connection isn’t a viable option, because our only wireless requires being on the VPN and that’s too slow. So we have a long network cable. The cart has a power strip attached to it that in turn has a very long power cord plugged into it. The network cable and power cord are long enough to wheel anywhere in the team room, and we just unplug when we have to roll it to another room.

Nanda uses the telepresence every day for the standup meeting, and for all other meetings. If he needs to talk to anyone in the office or vice versa, they just walk over to our area and talk to him just as if he were in the room. Anyone working from home is also free to use it. When I work from home, I stay on the virtual dolly all day, my teammates position it so I can see several of them when I move the camera around, and I just holler if I need anything. I wear a good USB headset to screen out background noise on my end and hear them better.

Look for a longer article about this and other aspects of making teams with remote team members work smoothly and successfully!

I’ve submitted three proposals to Agile 2010 and would love your feedback. Please review them – you will need to create a free account on the submission site if you don’t already have one.

Workshop: Who Pays for All the Fun? Selling the Value of Testing in Agile Projects

Tutorial: The Whole Team Approach to Testing

Talk: How Low Can You Go: Doing the Defect Management Limbo

I have a thick skin, so don’t hold back. I know there will be lots of great sessions, there’s a high standard, and I want to make a useful contribution.

Ellen Gottesdiener (at least, I think it was Ellen – whoever it was, thank you!) recommended Anne Lamott’s book Bird by Bird: Some Instructions on Writing and Life to me. Though it is more about creative writing, and though I found the author to be a bit of a kook at times, I’m taking away a lot of advice from it.

Lamott highly recommends participating in a writing group. This was good affirmation about our writing-about-testing group. But she cautions about criticizing others’ work: “you don’t always have to chop with the sword of truth, you can point with it too.” Having been chopped down before, I appreciate this advice. We need criticism, but we also need civility.

She also talks about the joy of having a writing partner, and I can attest to the value of that! Janet Gregory is the best writing partner anyone could want, whether we are writing something together or helping each other with individual projects.

Here are some more tips from the book that stick in my head:

“Short assignments” – if you have an anxiety attack trying to start a project, write down as much as you can see through a one-inch picture frame. Tell a one-inch piece of your story. I think this applies well to our kind of writing too.

“Shitty first drafts” – All good writers write them. That’s how they end up with good second drafts and awesome third drafts. I put this to use already on my Agile 2010 proposals and so far I’ve got some shitty first drafts, yay!

Get over your perfectionism. (I think this is particularly difficult for us Type A testers).

Quiet your negative inner voices, and get out of the way of your subconscious. At first I thought this was not applicable to technical writing, but all writing comes from within us, doesn’t it? We figure problems out while we’re thinking about something else or zoned out in the shower. Who knows what might be locked up in my subconscious, if I could just quiet my brain down enough to hear it?

There’s a lot in the book about characters and dialog that I didn’t find all that relevant to my writing, but it was still interesting.

Lamott writes about keeping at least one index card and a pen with her at all times to jot down notes, ideas, observations. She wrote the book in 1994, so maybe now she uses an iPhone, I dunno. But, I know at times I’m out walking the dog or something and have an idea – like this morning I had an idea about my proposal while I as out walking – it would have been good to have a way to note it down so I didn’t forget.

Another interesting chapter was on jealousy – being jealous of other writers (especially of your friends) when they have a huge success and you don’t. I don’t think I feel jealous about others’ success, at least not in the field of writing (I am envious of my former neighbors who retired to Hawaii, but at least I get to visit them), but maybe I just don’t admit it to myself because I know it seems bad? I do get envious when other people get fabulous jobs in fabulous locations, but why? I have a fabulous job in a fabulous location!

I think my wonderful writing-about-testing community as well as the other agile and testing communities in which I participate will help me avoid wasting time on envy and take advantage of every resource that can  help me write well. I write because I have something to say that I think could help someone else. I’m grateful for the opportunity to pay forward all the help I’ve received over the years as I’ve learned better ways to develop and test software.

Chris McMahon has blogged about our Writing About Testing group. I’m so grateful to Chris for starting this group. We have a wonderful bunch of testers/writers. I really enjoy helping members who are new to writing get published for the first time. I also really appreciate the great help and advice I get about my own writing.

Now, if I can just find the time to write! Check out my News page to see why I’m so busy. (I’ve also been on vacation for nine days! Back to work soon, hopefully with lots of new energy and ideas after this nice rest!)