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

—Lisa

Work through as many examples as you need until the team understands enough different aspects of the system. Try a different format if it’s not working. For example, if pictures drawn on the whiteboard aren’t sufficient to understand the story, try spreadsheets or some other format that’s familiar to the business experts.

Distributed Teams

As we’ve noted in other chapters, having team members in different locations and different time zones means you have to work harder at communication. Phones, email, and instant messaging form the basics of communication, but better collaboration tools are developed all the time.

Chapter 9, “Toolkit for Business-Facing Tests that Support the Team,” talks about some tools that can help distributed teams

Lisa’s Story

One of the programmers on our team, who is also a manager, moved to India. Nanda works late into the evening there, so he’s available for the Denver team in the mornings. He has a cell phone with a local Denver phone number, so it’s easy to talk to him by phone as well as by instant message and email. We schedule meetings where we discuss stories, such as estimating meetings, brainstorming sessions, and iteration planning, early in the morning so he can participate. Although the team can’t be as productive as we were when we were co-located, we’re still able to benefit from Nanda’s domain expertise and deep knowledge of the software.

If Nanda hires more team members in India, we may have to address more complex issues, such as coordinating integration and builds. We may consider more sophisticated technical solutions to communication problems.

—Lisa

You will need to experiment to see what works for your distributed team. Use retrospectives to evaluate whether collaboration and communication need improving, and brainstorm ways to improve. You, as a tester, may have a lot of experience in helping with process improvement projects. Just think about improving communication as one of those continual improvement needs.

A Remote Tester’s Story

Sometimes, the testers are the remote team members. Erika Boyer of iLevel by Weyerhaeuser lives on the East Coast and works with a team in Denver. She’s a tester by profession, but on her team all tasks are up for grabs. She might write fixtures to automate a FitNesse test or pair with a programmer to write production code. Being able to get in touch with people when she needs them is an issue. If she doesn’t get a response when she instant-messages a coworker, she phones; every work area in the Denver office has a phone. It’s not foolproof, because everyone could be in the break room at a going-away party and forgot to tell her. Teams in different locations have to make a special effort to keep each other informed.

Because Erika starts working a few hours before the team’s daily stand-up, she needs work she can do alone during that time. She works with any team members who come in early in Denver and converses with other programmers late in the day about work she’ll do the next morning.

Erika is able to see the team’s tasks using a tool on their intranet that shows each task, its status, and its percentage complete. With a few extra accommodations, the team (which has other remote members) is able to keep up good communication.

Even from a distance, Erika has been able to transfer testing skills to the programmers but has found they think differently than testers. Her team uses these varying perspectives to their advantage by rotating all types of tasks among all of the team members.

Successful teams keep remote members “in the loop” and share skills and expertise. Distributed teams face extra challenges in successfully completing testing activities, but some minor adjustments, thoughtfulness on the part of all team members, and good communication tools help ensure that remote testers can be productive.

We all need to be able to communicate well with each other for our projects to succeed. When teams are in diverse geographic locations, they might have to work twice as hard to stay in constant touch.

Regression Tests

Unless you’re on a team that’s just starting its automation efforts, you have automated regression tests covering stories from previous iterations. Hopefully, these are running as part of a continual build process, or at least part of a daily build process. If they aren’t, ask your team to make implementing this critical infrastructure a priority, and brainstorm with them how this might be done. Plan time in the next iteration to start a build process.

Keep the Build “Green”

Programmers should run all automated unit tests before checking in new code. However, unit tests may fail in the continual build, either because someone forgot to run them before check-in, or because of a difference in runtime environment or IDE. We have unit tests for a reason, so whenever one fails, the team’s highest priority (apart from a showstopper production issue) should be to fix it and get the build working again.

Teams take different approaches to make sure their build stays “green.” Lisa’s team has a build process that emails results after every build. If the build fails, the person who checked in the failure usually fixes it right away. If it’s not clear why the build failed, team members will get together to investigate. Their ScrumMaster has a stuffed toy that she puts on the desk of the person who “broke the build,” as a visual reminder that it has to be fixed right away.

Some teams use a traffic light, ambient orb, GUI build monitoring tool, or other electronic visual way to show the build status. When the lights turn red, it’s time to stop new development and fix the build. Another technique is to have a screen pop up in everyone’s IDE showing that the build has failed, and the popup won’t go away until you click “Ok, I’ll fix the build.” Have some fun with it, but keeping the build running is serious business.

In extreme cases, you may have to temporarily comment out a failing test until it can be diagnosed, but this is a dangerous practice, especially for a novice team. Everyone on the team should stop what they’re doing if necessary until the build works again.

Keep the Build Quick

The build needs to provide immediate feedback, so keep it short. If the build takes longer than the average frequency of code check-ins, builds start to stack up, and testers can’t get the code they need to test. The XP guideline for build time is ten minutes [Fowler, 2006]. Lisa’s team tries to keep the build less than eight minutes, because they check in so often.

Tests that take too long, such as tests that update the database, functional tests above the unit level, or GUI test scripts, should run in a separate build process. If the team is limited in hardware, they might have to run the “full” build with the full suite of tests at night and the “ongoing” build that has only unit tests continually during working hours. Having a separate, continual “full” build with all of the regression test suites is worth the investment. Lisa’s team gets feedback every 90 minutes from their “full” build, and this has proven invaluable in heading off regression issues. This secondary suite of tests does not stop a programmer from checking in their code.

Building a Regression Suite

During the iteration, you’re automating new tests. As soon as these pass, add them to the regression suite, as appropriate. You may not need every edge case or permutation included in the regression suite, and you want to keep the regression suites fast enough to provide timely feedback. As each story is completed, tests that confirm its functionality should be included in the regression suite and be part of the regular build cycle.