Agile Testing with Lisa Crispin

During a flurry of tweets and blog posts about whether or not ATDD is a good thing, I posted a blog on Stickyminds with my opinion. I’ve gotten some great comments, please add yours!

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!)

Last sprint we had a half-point story, which in our world should be about a day of coding and testing, to do some “simple” text content changes on a wizard in our web application. It’s been a year since we had updated this part of the application (it mainly gets used from late January to mid-March). While we were planning our sprint, we didn’t think too hard about how the wizard worked, and how many permutations it involves over the span of time that our end users are using it.

First Try

Our product owner asked me for screenshots of some of the pages, and had his mockups of the changes ready to go in a Word document before the start of the sprint. We wrote test cases on our wiki accordingly.

Second Try

One of the programmers started working on the story and realized the code had a lot of different cases that depended on dates and statuses of various items. He printed out some of the code and went over it with the product owner to get the appropriate text for each of the cases. The original mockups we had were no longer useful.

Third Try

When I started to test the updates, I kept getting confused. There were subtle differences between the different permutations, and several different target and deadline dates involved. I showed the new pages to the product owner, and he got confused himself, and kept making more changes to the text and even to the logic behind what text is displayed when. The programmer patiently updated the code over and over again, but I could tell he was losing the will to live.

I finally cut and pasted paper mockups myself for each possible condition with the text I thought was correct, went over it with the product owner who made his changes, and the programmer worked from the paper mockups. This did the trick, but by now, the half-point story had taken eight days instead of one.

What We Learned

In hindsight, we think that we should have started by researching all the different possible permutations before we started on the story, giving the PO a screen shot for each one, and having him give us paper mockups for each condition. This would certainly helped me test, as I tend to be more visual, rather than being able to mentally interpret what the code should produce.

When we showed this to more of the stakeholders, they asked if anyone besides the PO and us had reviewed the new text. We had been depending on the PO to do this, so we didn’t show it to anyone else until the coding was finished. Next time, we’ll ask the PO if other stakeholders have reviewed his changes.

Sometimes stuff just happens, but if we always remember to get a mockup for each change needed and each case, it might save us time in the future.

News

There’s a lot going on – I have new articles published and lots of tutorials, workshops and other events coming up. Please check out my News page for details.

Today I was lucky to hear part of the Thomas Jefferson Hour as I drove down to the ranch to work the donkeys. Thomas Jefferson, channeled by the actor and scholar Clay Jenkinson, quoted from his first inaugural address: “Every difference of opinion is not a difference of principle”. Jefferson believed that our elected officials should respond to moments of tension (and as he says, there was just as much rancor in political debates back in his day as now) with politeness, good humor and respectfulness. He recommended that our current elected officials, if they can’t find common ground, should adopt “artificial good humor” and assume the best about their opponents.

TJ and I might both have our head in the clouds, but I’m a big believer in civility. I’m not recommending that we all walk around on eggshells and worry about offending people. But I do think we need to all work hard to make sure that everyone on our software team feels safe to express opinions, and conversely, is willing to accept the team consensus or majority rule, and work to make whatever approach is taken successful.

This is something I want to take to heart for myself. Here’s an example. I’m trying to explain an issue to the programmer who is on production support this sprint. I’ve analyzed the problem and think I know how it should be fixed. He seems not to understand, gets impatient with me, throws up his hands and tells me I am mistaken. I could feel mad and hurt by this, or I can remember that being the production support monkey is frustrating and stressful. I’ve given him the information I wanted to convey, and I can leave him to process it. He’s smart and motivated to take care of our customers, so I know he will find a good solution. He shouldn’t be rude to me, but if I can avoid escalating the tension, we will have a good outcome.

Indeed, later the programmer comes over and apologizes, says now he understands what I was trying to say, and appreciates the research I did into the issue. We talk about the fix and how to test it.

I’m lucky to work on a team that, though there is lots of joshing and joking, is composed of people with a deep commitment to providing a quality product, and open minds willing to consider anyone’s ideas. I’ve been on teams that didn’t provide this atmosphere of respect and civility, and I must confess, I hightailed it away from those toxic environments.

The “agile” movement was built on principles and values. “Every difference of opinion is not a difference in principle”. Give your team time and space to agree on principles and values. Going forward from there, each team member will feel free to float their ideas and opinions, and have healthy discussions. That’s what makes a project successful.

News!

Janet Gregory and I have an article, and are interviewed in, this month’s Software Test and Performance Magazine, devoted to “Women of Influence in Software Testing”. Please check it out, it’s a great issue with lots of meaty articles.

I have a sidebar in Dawn Cannan’s terrific “Be the Worst” article in the inaugural issue of Agile Record.

Matt Davey wrote a wonderful thumbnail summary of our book in his review of it, we are grateful.

It’s that time of year for resolutions. One important agile principle (to me, at least) is the idea of continuosly improving. We are always looking for experiments to try, ways to work better. (There’s discussion on Twitter right now about the label ‘agile’ – maybe it’s time to drop it and just let it be the way we develop software! But that’s another post!)

Recently I wrote a Sticky Minds blog post about being nice. On New Year’s day, I read one of those newspaper articles you see every year that gives advice on sticking to resolutions. It suggested that rather than resolve to “being nicer”, set specific goals, such as, “I will compliment one of my co-workers each day on one of their accomplishments”. That seems smart.

So, instead of resolving to act nicer, I will resolve to notice and appreciate each day at least one of my teammates’ contributions. I also want to pair for some period of time with a coworker at least a couple of times a week. It would help me improve my skills, and I think it helps the team improve.

I have lots of other ways I’d like myself and my team to improve, watch this space. Meanwhile, I’m more interested in what other people are doing to improve how they work or behave. Please comment and share!

Agile Coaching, in my opinion, isn’t only for people who coach agile teams. If you’re in the software business, you’ll learn something valuable from this book. Start with the last chapter – “Growing You”. The only way to succeed in our industry is to continually learn and improve, and this chapter gives great suggestions how to do that.

This book is a model of concise, clear writing. It’s packed with information in the form of narrative, bullet points, graphics, photos, stories of real teams and projects, exercises, tips and examples. The authors have been walking their talk for a long time, so you can feel confident about following their advice. Their flair for language makes the book fun to read. It could be a quick read, except you’ll find yourself stopping to reflect on your own experiences, and thinking about how you could apply the technique you just read about on your own team. Each chapter includes hurdles you may face, and a checklist summarizing action items for you, the reader.

I particularly enjoyed the little vignettes with dialog from a typical team illustrating topics such as “Not Quite Done Yet” and “Getting Ready to Demo”. The authors have insight into all aspects of coding, testing, and managing software teams. You’ll find advice you might not expect in a software-related book, such as “Be kind to yourself”. The focus on people and teams will make you a better person and team member.