Crispin, Lisa - Agile Testing - A Practical Guide for Testers and Agile Teams

Tester:“Great start, but we won’t know where to ship it to at that point. How about a more generic test like:

Verify the 5-day shipping cost displays as the default as soon as the user enters a shipping address.

Customer:“That works for me.”

Considering All of the Facets

Paul Rogers recounts a situation during an iteration planning meeting, where a performance issue came up for a story that appeared to be straightforward and quick.

During our iteration meeting, one of the stories we were discussing was for adding some new images to part of a web application. This discussion ensued.

Product Owner:“I’d like to also get in the story for additional images.”

Developer 1:“OK, who has ideas on how long it will take?”

Developer 2:“It’s fairly quick, maybe half a day.”

Developer 3:“But what about the database changes?”

Developer 2:“I included those in the estimate.”

Developer 1:“OK, let’s go with half a day.”

Me:“Hang on. We looked at some performance issues last iteration. If we add all those images, we will be taking a performance hit.

Developer 1:“OK, we should think about that some more. Maybe there are other ways of implementing it.

Developer 2:“Why don’t we do a quick spike, add the mock images, and run another performance test?”

It was really good that this discussion before even starting on a story gave us some ideas of what problems we may encounter.

Anyone who’s uncertain about either the impact of a story on the rest of the system or the difficulty of developing the functionality can, and should, raise an issue during iteration planning. It’s better to address uncertainty early on and then do more research or a spike to get more information.

Asking questions based on different viewpoints will help to clarify the story and allow the team to do a better job.

Writing Task Cards

When your team has a good understanding of a story, you can start writing and estimating task cards. Because agile development drives coding with tests, we write both testing and development task cards at the same time.

If you have done any pre-planning, you may have some task cards already written out. If not, write them during the iteration planning meeting. It doesn’t matter who writes the task cards, but everyone on the team should review them and get a chance to give their input. We recognize that tasks may be added as we begin coding, but recognizing most of the tasks and estimating them during the meeting gives the team a good sense of what is involved.

Lisa’s Story

When our team is ready to start writing task cards, programmers usually come up with the coding task cards. The testers write testing task cards at the same time.

I usually start with a card to write high-level test cases. I ask the programmers whether the story can be tested behind the GUI, and write testing task cards accordingly. This usually means a test card to “Write FitNesse test cases” and a developer task card to “Write FitNesse fixture,” unless the fixtures already exist. Sometimes all of the behind-GUI tests can be covered more easily in unit tests, so it is always good to ask whether this is the case.

We put anything the team needs to remember during the iteration on a task card. “Show UI to Anne” or “Send test files to Joe” go up on the story board along with all of the other tasks.

I estimate the testing task cards as I go, and ask the team for feedback on the cards and the estimates. Sometimes we divide into groups, and each group takes some stories and writes task cards for them. We always review all cards together, along with the estimated time. If development time is relatively low compared to testing time, or vice versa, that provokes a discussion. We reach a consensus as to whether we think all aspects of the story have been covered with task cards. If there are still some unknowns, we simply postpone writing the task cards until we have the information.

The testing and development cards all go on the story board in the “to do” column. Anyone on the team can sign up for any card. Some testing task cards move to the “work in progress” or “done” column before coding cards start to move, so that programmers have some tests to guide their coding. As coding task cards are moved to the “done” column, the cards for testing the “done” functionality are moved into “work in progress.”

—Lisa

Janet uses an approach similar to this, but the programmer’s coding card stays in the “To Test” column until the testing task has been completed. Both cards move at the same time to the “Done” column.

Three test cards for Story PA-5 (Figure 17-2), displaying the shipping cost for 5-day delivery based on weight and destination, that Lisa’s team might write are:

Write FitNesse tests for calculating 5-day ship cost based on weight and destination.

Write WebTest tests for displaying the 5-day ship cost.

Manually test displaying the 5-day delivery ship cost.

Some teams prefer to write testing tasks directly on the development task cards. It’s a simple solution, because the task is obviously not “done” until the testing is finished. You’re trying to avoid a “mini-waterfall” approach where testing is done last, and the programmer feels she is done because she “sent the story to QA.” See what approach works best for your team.

If the story heavily involves outside parties or shared resources, write task cards to make sure those tasks aren’t forgotten, and make the estimates generous enough to allow for dependencies and events beyond the team’s control. Our hypothetical team working on the shipping cost story has to work with the shipper’s cost calculation API.

Tester:“Does anyone know who we work with at BigExpressShipping to get specs on their API? What do we pass to them, just the weight and postal code? Do we already have access for testing this?”

Scrum Master:“Joe at BigExpressShipping is our contact, and he’s already sent this document specifying input and output format. They still need to authorize access from our test system, but that should be done in a couple of days.”

Tester:“Oh good, we need that information to write test cases. We’ll write a test card just to verify that we can access their API and get a shipping cost back. But how do we know the cost is really correct?”

Scrum Master:“Joe has provided us with some test cases for weight and postal code and expected cost, so we can send those inputs and check for the correct output. We also have this spreadsheet showing rates for some different postal codes.”

Tester:“We should allow lots of time for just making sure we’re accessing their API correctly. I’m going to put a high estimate on this card to verify using the API for testing. Maybe the developer card for the interface to the API should have a pretty conservative estimate, too.”

When writing programmer task cards, make sure that coding task estimates include time for writing unit tests and for all necessary testing by programmers. A card for “end-to-end” testing helps make sure that programmers working on different, independent tasks verify that all of the pieces work together. Testers should help make sure all necessary cards are written and that they have reasonable estimates. You don’t want second-guess estimates, but if the testing estimates are twice as high as the coding estimates, it might be worth talking about.