Agile Testing: A Practical Guide for Testers and Agile Teams

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.”