Top Ten Risks When Leading an Offshore Test Team (Part 1)

Michael Hackett, VP of Business Operations, LogiGear Corporation

Today many test team leaders must continue to successfully ensure the quality of their applications under test (AUT) while dealing with the increased challenge of having some or even all of their team members located offshore. This article, part 1 of a two-part discussion, will take a look at the unique risks faced by a test lead when dealing with offshore teams, and how those risks can be mitigated.

No matter the mix of domestic and offshore testers, there are certain risks which every testing team face. These include:

• Testers are not skilled enough to write good test cases and find bugs
• Testers don’t have the technical or business understanding to effectively analyze anomalies.
• Testers do not write good bug reports
• Inadequate training and ramp-up time for team members.

When any of these problems exist, the test team is likely to be ineffective, no matter where team members are located.

The test lead who must deal with offshore teams faces a number of additional challenges, which have their roots in the geographic, temporal, cultural, and other differences between domestic and offshore teams. In working with many organizations involved with offshore testing, as well as our own experiences, we’ve identified the top ten issues. The first five are presented in this article, and the next 5 will appear in our December issue.

1) Offshore work is not measurable or quantifiable, leading to lack of confidence in the offshore effort:
Testing is inherently difficult to measure, and this problem is exacerbated when the testing team is offshore. Having an easily accessible, centralized repository for your test cases and test results is critical, and you must be able to easily and quickly view reports to see and measure numbers of test cases created, what test cases have been run, their results, how many bugs have been found, etc.

2) Lack of visibility into day-to-day work:
Quite simply, it is difficult to track what offshore teams are doing, especially offshore testing teams. The days of the ‘walk around manager’ are over. In our experience, the best way to maintain visibility into the work of offshore teams is to have every team member submit brief status reports every day indicating

• what they worked on that day,
• what they are planning to work on tomorrow,
• and whether or not they are facing any hindering issues (e.g. not being able to access a server in the US, etc.)

This allows you to redirect any test effort which has lost focus or is not correctly prioritized, as well as to address issues the team is facing in a timely manner.

3) Lack of a competent lead/point-of-contact:
While you want to maintain visibility into what every team member is doing, you must have a single person on the offshore team who is responsible for their effort. It is nearly impossible for an onshore lead to effectively micromanage an offshore team, and without a single point of accountability at your offshore team, you have a recipe for almost certain disaster. Simply put, if you don’t have a good lead for the offshore team, get one as soon as you can! The offshore test lead should have excellent communication skills as well as an in-depth understanding of your AUT and perhaps be the main troubleshooter when inevitable problems arise. This person should be a test lead who is actively involved in the testing effort, not a business person/account manager who handles contract issues.

4) Lack of plans for downtime:
Remote teams, especially those located in developing countries, can experience any number of problems which can lead to hours or days of lost productivity. Examples of these problems can include power outages, network connectivity problems, viruses, excessively long build downloads, build installation problems, “bad builds”, blocking bugs which require help from team members who are sleeping/offline, and the list goes on. Of course the best way to deal with these bugs is to proactively prevent them from happening, but there will always be contingencies that you didn’t plan for.

Always have a backup or contingency plan for the team to continue working when the primary tasks cannot be completed, with activities such as:

• updating test cases
• documenting exploratory tests
• updating test plans
• regressing old bugs
• automating more test cases
• brainstorming new test cases
• developing new test data sets

5) Offshore teams lose access to onshore servers and applications:
Any number of problems can prevent your offshore team from accessing machines located onshore, such as your defect tracking, test case management, software configuration management/ build server, and other systems. Problems can include bandwidth issues or complete loss of connectivity, regularly-scheduled backups which take the system offline, and security policies that prevent offshore teams from accessing the network.

Some teams have dealt with this risk by replicating various databases to live in both locations. No matter what solution you use, one of the most important things to make clear to your offshore team is to “keep working” even if a system is down. For example, bugs can be sent via email if the defect tracking system is unavailable. As long as the team has access to a testable application, there is something useful they can be doing, such as exploratory testing.

In part two of this article, we will take a look at another five risks facing test leads when working with offshore teams.

LogiGear's RSS feed