| This article was developed from concepts in the book Global Software Test Automation: Discussion of Software Testing for Executives. |
Introduction
The top 5 pitfalls encountered by organizations outsourcing/offshoring Software Testing are:
- Problematic communications
- Insufficient or mismatched skill sets at software test organization
- Management issues
- Vendor and infrastructure problems
- Offshoring risks
Following are 5 “best practice” recommendations to help avoid these pitfalls and successfully outsource your Test Automation to an offshore partner.
Best Practice Recommendations
There are ways that the pitfalls associated with outsourcing/offshoring Software Testing can be avoided or resolved. The following are 5 best practice suggestions of ways to avoid these pitfalls:
1. Build trust or use someone you can trust.
You need to work with a partner that you know has testing experience, an experienced staff, an understanding of current methodologies, and competent domain knowledge.
Building or gaining trust can be accomplished in many ways, including:
- Working with a test organization that you know or have used in the past.
- Looking for test organizations that come highly recommended by individuals whose opinions you trust.
- Using a small pilot project as a means of determining how dependable a test organization is. If you find you can rely on them with a small pilot project, you can start to build up trust and move forward with larger more critical work.
2. Train the test organization, or make sure they are fully competent to begin with.
It is rare to encounter an outsourced test organization that is “fully competent” as they are typically lacking in domain knowledge, and knowledge of your processes, reporting, communications and more. Of course, if they are already demonstrably fully competent for your application to begin with, that is a plus that will save a great deal of time. More typically, you will have to invest in training the offshore testing partner.
Your offshore team needs to be trained in all aspects of your test process, including communication methods, status reporting, test case management and defect tracking systems, the build process, how much time to spend analyzing bugs to what backup work to do in case of a bad build or downtime, why certain metrics are important, and what they mean, to reduce fear while instilling an understanding of measurement. Take the time required for this into account, as well as the training costs, when you compare options and make your project plan.
Training your offshore test team and setting realistic expectations can stop or minimize most problems before they cause mid-project headaches, stress, or even test project failure. But training an offshore team is different than training your domestic team. Your offshore test team is likely to be more technically skilled than your domestic test team, but that does not eliminate, or even reduce, the need for training.
You will have cross-cultural rough spots as well, so train the local team on ways to recognize and deal with them. Tackling these issues can be difficult and sensitive, but very worthwhile. Trust takes a long time to build, but it is quickly lost.
The domestic team must be aware of how their behavior will be interpreted by the offshore team. Many behaviors that are common to Americans such as making jokes, political comments, or openly criticizing management, can be viewed as disrespectful and inappropriate by your offshore test team. Training can make the domestic team more aware of their own behavior and how it is viewed by the offshore team, preventing friction and misunderstandings that can put the project at risk.
3. Get a methodology and/or tool to improve communications.
Adopt a methodology and tools that support the overall methodology to improve testing, defect tracking, automation, and communications management, focusing on excellent and correct methods, ease of distributed team communication, accessibility, and useful measures. The methodology needs to support a variety of test methods and styles, be clear to understand, adequately test your product, and give you useful information.
4. Choose carefully what work to send offshore and what to keep at home.
In most cases, your offshore team will have a higher level of programming skill than your domestic team. It makes sense to first send Test Automation offshore and keep user-focused scenario development and business process testing in your domestic office where you have more knowledge of the domain and the user. Have the home team focus on the users they should know well. Have the offshore team focus on technical-level testing and Test Automation that computer science graduates would be happier and more knowledgeable about.
5. Build a team with local leads as part of your team or outsource to a team with local test leads as part of your team to manage the outsourced test effort.
A local lead that is part of your team, who understands the culture and communication nuances of the offshore team, can lead the project, effectively communicate progress and metrics, and help to streamline the process. Having non-specialized staff deal with the mountain of potential offshoring issues is at best a difficult task, which will significantly slow down that person’s job duties and lead to many potential problems. Having a specialized local lead to manage the outsourced effort can ultimately save time, save money, and save many hassles.
Conclusion
To summarize the preceding in a simple list, the 5 suggested best practices for outsourcing/offshoring Software Testing are:
- Build trust or use someone you can trust.
- Train the test organization, or make sure they are fully competent to begin with.
- Get a methodology and/or tool to improve communications.
- Choose wisely which tasks to keep and which to send offshore to focus on what each team does best and increase the productivity and savings of the outsourced test team.
- Build a team with local leads as part of your team or outsource to a team with local test leads as part of your team to manage the outsourced test effort.
Rob Pirozzi
