The first poster says ‘keep the requirements handy and keep them up to date’. That’s an agile antipattern. We talk to each other and work together to get the work done. We don’t spend out time documenting requirements and keeping them up to date.

Off shoring may appeal to the person looking only at numbers, but the true cost will be seen an increase in bugs, interruptions to the business by these bugs, more frequent releases to fix bugs, less time available to focus on new functionality, and a less than optimal agile team.

You’d very-likely need to on-shore at least one person in that team for a little while to teach them the app etc (which will increase the cost) and give them a bit of domain knowlege, so they understand the acceptance tests.

I’ve done something similar to that with a tester in another office. We define acceptance tests using a BDD style format (given, when, then) and he then automates those for us using a combination of Watir, Watircraft framework, Cucumber (it’s a web UI). This means our actual test code is written ruby, but that’s ok as it’s an easy langage to teach to QA folks, and it reads clear enough that our devs (working in asp/c#/.net) can still make sense of them if need be.

BUT the key to that success is that we’re leveredging the BDD work already done to create those acceptance test stories using the DSL and BDD format, which are used by both dev and QA during the development cycle.. So we’re not creating extra documentation etc.

That being said however, I’m doing this ‘nearshore’ working between our office in Seattle area, and a Bay Area office where we have a tester with some extra bandwidth, and who was eager to learn automation so it could also be applied to the products being produced in that office. So when he had questions, I was only a skype away to answer them, mostly in real-time. The process would have been slightly less effecient if we had time and potentiall language barries to deal with. We could potentially off-shore this later if needed, but in doing so I think you have to factor ‘communication costs.’ (mostly time delays) into the mix when calculating if this actually saves you anything in the long run.

Off shoring is the business demand and very cost effective profitable business for the organization.

Very true, testers are separated by thousands of miles and a multitude of time zones from your team as well as your users. But the collaboration that is required is not at all close to impossible, of course at initial stage expectation could not be matched immediately as of tasks perform at parent location.

Once you define the process, keep all the requirements handy and up-to-date and do constant and continual monitoring of execution, will help to achieve the desired goal.

Why can’t regression test be automated by offshore testers? These testers might not be expert in the application business domain but well versed in writing and maintaining the code/scripts to automate the tasks to do. Gradually with time and experience tester will know the application.

I work without having enough professional testing experts in the team so what could be the way? Nothing to worry much, make the team well versed with the defined process of testing process to follow and bring them to that level. Of course, there will be a senior tester/team member with required skill to bring other team member to the level of tasks execution.