Training for Offshore Testing Teams (Part 1 of 4)

skinapi

链接请见：
http://www.logigear.com/newslett ... ing-teams-part1.asp

Introduction

When a US-based device maker outsourced their testing to India there was one thing they forgot: The new test team had never seen a device like theirs, had no idea how to use it, or why anyone would even buy it. The test effort failed. No surprise.

A Test Lead friend was getting only half the testing picture from status reports, frustrated with missing information, learning unpleasant surprises about what she thought was happening. She found out she have been lied to in order for a test team member to save face.

Training your offshore test team can stop or minimize these 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. That’s great, but that does not eliminate, or even reduce the need for training.

Perhaps most important to ensuring test project success as well as peace of mind, your offshore team will need additional training in working with the domestic teams, communication and meeting etiquette, work ethics, and in many cases conversational and technical English. This may not be a complete list of the soft skills your test team needs for project success. Offshore teams will vary widely in their experience level and their cultural background, so the training needs will also vary widely. In my experience, I’ve seen teams ranging from one completely composed of repatriated engineers who had lived and worked in the US, to many teams of “freshers”, the Indian nickname for a worker on their first job out of university.

The need for increased management oversight of offshore teams is widely known to be the biggest pain point for domestic staff. Whether it is too many late-night phone calls, not getting the work done on time or simply a greater need for hands-on project management, you can tackle all these issues with effective training. Use training to set and discuss expectations, layout processes and procedures and most importantly open doors for greater communication and visibility. Training should support your goal of micro-communication, but not micro-management. Training should also be used to identify what the team knows and what they don’t, which sets a roadmap for future training.

Unique Training Needs for Offshore Teams

Your offshore team may have been assembled for their technical skill alone. Just like your domestic team, they will need training in domain knowledge, testing/QA knowledge and methods and of course, your testing process (structure, expectations, communication and documentation). Those are the obvious subjects; there are several which are not as obvious but just as critical.

Trust-building is typically not a major training consideration for domestic teams. It is for offshore teams. Training gives you more confidence that work is getting executed the way you intended as well and gives the offshore team more confidence they are doing what you want! Training needs to setup channels for open and fluid communication.

Outsourced development has one reputation, outsourced testing another. In many countries testing is considered throw away work- only a vehicle to get the real development work. After one training session I conducted in India, the Engineering manager told me “I never knew testing was a real job. I put my worst staff on testing projects.” Your training will need to include topics on why you test and the value of testing. Also remember, developers learn how to develop code at university. There is no school teaching American-style software testing; the best you can usually hope for, without training, is requirements validation.

There is “tribal knowledge” among team members about every facet of the product and project from how and why rarely used features work, to well-known bugs, or where certain test files live on some server. Local testers learn from each other and other project team members through yelling over a cubical wall, conversations overheard or at team meetings, and coffee machine chats--in other words “learning by osmosis.” It took years of learning to build up this level of knowledge. You cannot rely on this method of knowledge transfer for your offshore team. For a while, training needs to be centered on in-class, instructor-led training backed up by computer-based training.

Domain knowledge has proved to be the critical element for outsourced project success. As an example, if you are making credit card processing software in China where McKinsey & Co. estimate that fewer than 1 percent of the country's population has a credit card (50% of which are inactive), how can you expect your test team to effectively test from a credit card user’s perspective? Similarly, if you are developing stock trading software in Russia, even if one of your testers says they have knowledge of stock trading in Russia, will that be applicable to US users or SEC compliance? Maybe not, but it’s better than nothing. Many companies today are looking to hire business graduates into technology groups who will have more customer focus. This may also help cut down on technical staff turnover but will increase your training in technical areas.

These are straightforward examples, the more complex your application and the more sophisticated your users, the greater your need to give significant training on your business domain and users to your new test team.

The type of testing that will be done by the offshore team directly impacts the training they will need. In most cases you have a higher level of programming skill in your offshore team than in the 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.

In Part 2 of this article series, Michael will discuss the following training areas:.

    * Process
    * Product and Domain Knowledge
    * Testing Techniques