Does Offshore Work

Simply – yes – if performed correctly. Where so many fail, is by misunderstanding some of the key factors that need to be in place. The simplest way is to treat it as a black box scenario, offshoring well specified work packages, with quantifiable and specified deliverables against known timescales. This reduced need for communication simplifies the process, but it is only as good as the inputs. If these can be well specified then the chance of a good delivery is excellent. A prime example of offshore capability being used in this manner would be the generation of test scripts. This is often seen as a tedious activity that bores the UK Test Analyst, being repetitive in nature. Providing an offshore capability with a requirement specification that has been statically tested, perhaps even with the test scenarios defined, should enable a good offshore team to produce a well defined suite of scripts. Confidence can be obtained by sampling scripts as they are being produced and example scripts can be provided by the client to define the standards to be followed. Having mentioned static testing, the passing of a single document to an offshore team for review against the 8 point check is simple and requires minimal communication. Neither the test scripting nor the static testing require anything more than e-mail to send information, so setting up links between the offshore destination and your own test environments is not required. If you are not currently utilising offshore then we would strongly recommend giving one of these a try and sampling the option.

Once confidence to this level has been achieved the next easiest element to place offshore is the test execution. This does involve setting up links to the offshore capability, but some software can be used to achieve this quite simply. Access to defect management tools needs to be arranged to ensure that defects are reported as they are found and not gathered for end of day reporting. Freeware is available such as Bugzilla to achieve this and only needs to be hosted. The data protection act comes into play here, but it should be remembered that personal data should be scrambled prior to testing anyway, if not using simulated data. At this point it is worth pointing out that we do not recommend that all of the test execution is performed offshore, as interfacing with developers, business analysts, environment managers and project managers is required, so some onsite presence is required. Again if this is new to your organisation, try just placing a small fraction of the work offshore and increase the volume as confidence grows.

As more onus is placed on the offshore capability, the increase in management and communication occurs. This should start moving the operation into that of a service and the management mechanisms should be introduced as defined in http://tcl-india.blogspot.com/2008/05/tcl-coms.html.

From a service perspective, it is critical that both the offshore and onshore sides of the operation need to understand each other, how they work, what their expectations are and how to get things done. Too many people trust in organisations that put people in place to manage an offshore setup that the client has no knowledge of or relationship with. This can work, but beware the teething troubles that can occur. A good mechanism is to have the head of offshore resource work onsite for a considerable period of time, at least 3 months if not 6, before moving into an offshore service model. Most importantly rely on a team that has successfully managed offshore engagements and work well as a unit spread across the two countries.

To summarise, start simple, build confidence, know your offshore lead and gradually move to an offshore model. If moving straight into offshore, get expert assistance.

TCL India would be happy to discuss how to run an offshore trial with you. Please contact either Mick or Grant for further information or to set up a meeting.