Software Testing in Distributed Teams

Lisa Crispin, https://lisacrispin.com/

I started writing this article with the idea that I'd talk about technology and practices that help teams succeed with testing even when they're in multiple geographic locations. But as I wrote, two things happened. First, after so many years of working in teams that take a Whole-Team approach to testing, it's hard for me to separate testing from other aspects of software development. Secondly, everything always gets back to team and company culture.

The same things that make a co-located team able to deliver valuable software to the business frequently, while maintaining a sustainable pace (to paraphrase Elisabeth Hendrickson) also enable distributed teams to do the same thing. However, distributed teams will have to be even more disciplined and committed to making their software development process work.

So, as you read this article, you may find yourself thinking "But any team should do that", and you will be correct: a learning culture that encourages small experiments and continuous improvement while tolerating failure.

Distributed software development teams are here to stay. More and more companies are national or global. More and more employers are willing to hire good software professionals no matter where they live. Some businesses think they can save money by "off-shoring" their coding or testing teams many time zones away from where business stakeholders and customers reside. How do we get quality software in these situations?

Rapid Feedback

Even when all roles on a development team work in the same building, testing gets disconnected from other development activities. The ability to deliver valuable features in a timely manner, responding to changing business needs, depends on a short feedback loop.

If a regression failure is found within minutes of the code check-in that caused it, the fix is quick and easy. Showing customers the first pass through a new UI page design early means less time wasted on the wrong approach. Identifying missing requirements by doing exploratory testing on an early iteration of the software helps teams develop the right feature

How do distributed teams get faster feedback? Continuous integration (CI) is the foundation of timely feedback. Without it, your team will not be able to keep technical debt to a manageable level. Your team wouldn't dream of operating without source code control, and CI is just as necessary. Building up suites of automated tests that give fast warnings of regression failures takes months or even years, so get started now.

With the basics in place, your distributed team can focus on other aspects of feedback and collaboration. Driving development with business-facing tests is a proven way to delight our customers. Testers need to be involved in eliciting examples of desired behavior from customers as they plan new user stories. They need to participate in planning and design meetings. Customers need to be actively involved, reviewing new features as they are incrementally developed, making decisions as developers discover new information.

When the customer and developer teams are spread geographically, technology makes these activities possible. Today we have many options for video chat and conferencing, instant messaging, backchannel chat rooms and tele-presence devices. More about those in a bit.

These practices and technologies won't work, however, unless teams have the discipline to use them constantly. My distributed team makes a conscious effort every day to collaborate using all these lines of communication to keep every team member, regardless of location, actively involved. That involvement extends to our customers, too.

Building the Distributed Team Culture

I'm not sure any distributed team can succeed over the long term without being together in one location from time to time. "Face time" is so important to building trust. Our team members congregate in one location every six weeks or so. Getting to know each other helps us communicate better and faster. Having fun together socializing and playing a few rounds of table tennis means that we enjoy working together remotely more.

Experiment with practices and techniques to keep testing an integral part of your distributed team's development process. Use video for all meetings, even daily standup and status meetings, so that team members in different locations can see each other. There's a visual component to communication that is indispensable.

Make sure all team members, including testers, have an equal voice, and feel safe asking for help. Encourage whole-team responsibility for quality and testing, so that people in any role take on testing tasks when needed.

All team members, regardless of location, need adequate training, and time to learn. This is especially critical in an "offshore" situation. If your company hired a team in another country or continent to do testing, bring them to the rest of the team to learn the business domain, the software, the practices they'll need to know. Alternatively, send team members out to train them. Remote training may be adequate later on, but that face-to-face contact is crucial to building good relationships and communication.

More practices and techniques

If the business values getting the right software features at the right time, there are practices which help distributed teams achieve that goal. Try these to see which work for your distributed team.

Pairing

Remote pairing is a great way to promote constant communication among multiple offices and to keep people working from home "in the loop".

I often remote pair with a developer to specify test scenarios, do exploratory testing, or write automated test scripts. We use screen-sharing software that allows either person to control the mouse and keyboard. Video chat is best, but if bandwidth is a problem, audio will do. Make sure everyone has good quality headphones and microphone, and camera if possible.

Pairing is a challenge for those who have never tried it. Support it culturally by having the team decide a schedule. For example, they may decide to pair all day, or pair during a few hours when the time zones of the pair coincide. Pairs can be decided during a daily standup for that day, or for the following day, depending on the timing. On my team, there's always a plan for who will come in early the next day to pair with someone from an earlier time zone.

Chat and instant messaging

When the rest of your team is in the same room, it's easy to ask a question or show something to customers or other team members. When you're not in the same room, everyone on the team should commit to keeping an eye on a team chat flow and jump in to help when needed. In my experience, a central chat stream works best, and if needed, people can agree to move their conversation to another chat stream, or start their own text chat or video session. It's critical that someone in a remote office who needs help or feedback gets it as quickly as if the team was co-located.

Tele-presence devices

It's critical that all team members hear the same conversations, and that they're up to date on the latest changes and decisions. If most of the team is in one place with just one or a few remote people, a tele-presence device in the main office that remote colleagues can control is a huge benefit. This can be as simple as a rolling cart with a laptop, a good camera that can be controlled remotely, and a good omni-directional microphone.

Enhancing communication

Written communication and documentation may not be as effective as audio and visual, but are still important. Wikis promote collaboration, and work well for teams with widely diverse time zones. My teams have had productive design discussions on the wiki, with each person color-coding their comments. Photos of whiteboard drawings, screenshots and other graphics can be easily included.

It's much easier to follow the conversations on a wiki page than a long email thread. Written communication is a good back-up to verbal discussions, especially where not everyone on the team shares the same first language.

Mind mapping, story mapping and impact mapping are all great techniques to help plan testing for a user story, epic or theme. They enhance conversations, help generate more ideas, keep the team focused on the best way to achieve business value, and provide artifacts for future reference. A variety of online tools provide real-time collaboration for these types of activities.

As I mentioned earlier, acceptance test-driven development (ATDD) / Specification by Example (SBE) are in getting a shared understanding of business needs. The resulting tests, which must continue to pass in every CI build, provide "living documentation" that should be accessible to everyone, including business stakeholders.

Visibility

Coordinating work is especially tricky on a distributed team. Over-committing to an unrealistic amount of work is deadly for any team, and it's even easier to fall into that trap on a distributed team.

Find ways to keep work visible. Limit your work in process, so that everyone can focus on finishing one feature at a time. Each location can maintain a physical task board, keeping them consistent by posting photos of them on a wiki. Or, you can take advantage of one of the many virtual task board and project management tools, which also can help promote realistic planning.

Continuous integration is a great framework for visibility, too. Broken builds can send out emails. Color-coded CI results can be displayed on each team member's monitor. Some globally distributed teams have CI results prominently displayed in a common work or break area.

Making a problem visible is a great way to start solving it. Distributed teams can find creative ways to use Big Visible Charts, even if they're virtual.

Let the team drive

I've mentioned a lot of ways distributed teams can work effectively, which includes planning and executing all the testing activities needed to deliver the right software features at the right time. In my experience, some "core" practices such as CI and using Big Visible Charts are essential for any team. Getting everyone on the team together in one physical location frequently enough is key for making distributed teams successful. However, each situation is different, and only your team can find the best way to build a healthy team culture where everyone can do their best work.

Use frequent retrospectives to identify the biggest problem in your way, and try small experiments to chip away at that problem. The additional effort to coordinate everyone on a distributed team can feel painful. But you can take some disadvantages, such as time zone differences, and turn them into benefits. For example, when my team in Denver had a thorny issue at the end of our day, we could pass it on to our coworker in India, and he often had it solved by the time we came to work the next morning.

Managers need to support distributed teams as they find the best ways to work. It's absolutely essential to let the team manage its own workload, and encourage them to budget plenty of time for learning and experimenting. An early investment will pay off in a "jelled" team who can meet future challenges quickly, and deliver valuable software to the business consistently over the long haul.

---

Software Testing Articles and Resources

Distributed Software Team Communications: Tripping Over Words

XP Testing Without XP: Taking Advantage of Agile Testing Practices

Choosing and Managing the Ideal Test Team

Software Testing Magazine

---

Click here to view the complete list of archived articles

This article was originally published in the Spring 2013 issue of Methods & Tools