Agile Testing: A Practical Guide for Testers and Agile Teams

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.