Onsite – Offshore Model of Software Testing Projects (and How to Make It Work for You)

The Onsite-Offshore model is a very common working method for many IT teams across the industry, especially the QA teams. The way this works is, one/more (depending on the magnitude of the project) of the service provider’s QA team member works along with the client at their location.

The client location and the service company’s workplace can be geographically any place – across the globe or sometimes in the same city.

Onsite - Offshore Model of Software Testing (1)

When this is the working model, there are some expectations from the Onsite and Offshore resources respectively. Let us see what they are:

Responsibilities Of Onsite QA Associate/Coordinator

  • Knowledge transfer from the client to the team – Obtain the technical knowledge and share it with the team
  • Communicate timelines, progress, delays, etc back and forth from the team to the client and vice versa
  • Shares the FRD (functional requirements document) and works on making a Test plan
  • Review the Test scenarios/Test cases with the client team and provides a sign-off
  • Provides inputs on the Test data preparation phase
  • Provides Test execution guidelines.
  • Perform the Smoke and Sanity test on any deployed build and gives a go-ahead for the team to continue testing
  • Sometimes, participates in the test execution
  • Holds defect review meetings with the concerned development and support teams
  • Collects metrics
  • Supports UAT

Responsibilities Of An Offshore Team

  • The associates get the test plan and work on Test scenarios
  • After the Test scenarios are signed off, the team would work on documenting the Test cases
  • Prepare Test Data
  • Execute the tests
  • Report Defects
  • Prepare Test Reports
  • Provide inputs for Test Metrics collection
  • Participate in the defect review and other Project-Related meetings.

Advantages Of Onsite-Offshore Software Testing Model

  • If used right, this model can ensure that there is work going on every minute of the 24 hours on a project.
  • Direct client interaction helps in better communication and also improves the business relationship. You will have all the information about the systems and the client’s requirements easily available.
  • Cost-effective – Offshore teams cost less than setting up the entire QA team onsite.

However, some of the common complaints we hear in our software projects are:

  • Onsite resources say that Offshore resources don’t know what they are doing and are not available when they need them.
  • Offshore teams complain that they are not getting the right inputs they need.

To avoid this:

  • Remember that Onsite and Offshore are two sides of an equation. Nobody is more and nobody is less. Unless these two counterparts act in harmony, this model is going to be terribly dysfunctional.
  • Make sure you overlap at least an hour’s work time between you both.
  • Communicate often and communicate effectively.
  • Have a list of To-Do’s for one another and make sure you are working on the list and updating each other on the progress.
  • Be considerate of the time zone differences. If it helps, check-in for a few minutes before you even start to work with the Onsite coordinator (at a reasonable hour of the day) so you know what is expected of you.

For those of us, whose projects are based in one location, we hope this has explained how this model works.

For those of us who are already working under this model –Do share your experiences? How do you both interact and make sure you are in sync? Do you face any challenges? Do you think that this model is the least bit useful?

Please feel free to provide your feedback below.

This is a guest post by STH team member Swati Seela. You can also publish your guest post on this blog. See more details here.

Recommended Reading

14 thoughts on “Onsite – Offshore Model of Software Testing Projects (and How to Make It Work for You)”

  1. Good Post for Application Under Test Functioning Methods across the Continents….
    Off Shore Team can commit for major deliveries under test, on weekend to get the benefit of 2 days of buffer to work upon if it is likely to get delayed, useful for US based onsite Clients……using time difference to best use.

  2. Thanks for sharing.

    We work on a similar model. To avoid problems and communication gaps, we also have a weekly call with the onsite team.

  3. Thank you! for the post.

    We are following onsite/offshore testing model, so that we are getting proper requirement & changes ASAP. To avoid communication gap we are following daily mails and weekly calls.

  4. I am currently in the USA and have been working with an off shore team in India since 2006. It has been difficult at times, but at this point we definitely are working as one team. In the beginning of the relationship I had daily phone calls, in addition to numerous emails. Currently, we have monthly teleconferences, email, chat and the occasional phone call.

    What has worked for us is that we have gotten to know each other as individuals and not just a ‘resource’. Currently my off shore lead is on vacation getting married & I wish I was there to see it. Also, I have every confidence in my off shore team and so do the developers & business people I work with, which was a hugh hurdle at the beginning.

  5. We are also working on the same model illustrated above.

    It is going fine to work with onsite team..

    We are having a daily one hour call with onsite team and Todo’s for the day to discuss with them.

    This helps so much to work along with onsite and coop with them for a better deliverables.

  6. We are working on the same model. Few major challenges are :
    1) If the requirement is not clear sometimes it take more time to get it confirm from respected PO’s (Product Owner) which result into delay

    2) Sometime have product training from onsite, due to different time zone (US Vs India) we have to adjust the timing

    3)Sometimes if onsite coordinator is on leave/vacation/left its very difficult to get the information which again results into delay

  7. Thanks for sharing valuable information.
    I just want to know what is TEST METRICS actually as discussed in this topic with some specific example ?

  8. Hi Swathi , very nice explanation.
    Currently I am working on this model and can relate everything mentioned in this article so easily.
    Thanks. !!!!!


Leave a Comment