Apart from the advantages of a night-time QA cycle to complement my daytime development teams, having a much more inexpensive QA team offshore allows me to have the QA team achieve something that's practically impossible for most companies that employ dedicated QA in North America: expand the test suites to allow complete test coverage every night. What that means, in a nutshell, is that every time the QA team kicks in offshore (in my case the teams are almost always in Vietnam), they execute every test in their test plans against the then-current checked-in code from the previous 24 hours. The advantage to that is simple: by running every test every night, anything that breaks the product is quickly identified and isolated, then fixed.
Since one of the biggest issues with testing complex products is effect of relatively minor changes in code on the larger system (integration testing), this is a huge benefit. Before I started being able to run complete test coverage every night offshore, I would have to depend on my onshore QA team to test each developer's code in isolation, and only be able to do integration testing and system testing on occasion (usually once a week or every two weeks), which means issues take a long time to find and even longer to trace back to their cause. This inevitably pushes timeframes for delivery of product later and later, as issues are always found in system testing.
The change began about ten years ago when I had a relatively large QA team offshore (compared to my smaller team onshore). Because they were pretty junior and inexperienced when we started with them, the QA director had the offshore team doing routine testing, and writing test cases for the test suite. He didn't push them too much, as he didn't know what they were capable of, and relied on them for run-of-the-mill testing. Well, turns out the team offshore got bored doing the boring work and so they started automating the test cases as a little side project when there was time. Over the space of a few months, that added up to almost an entire test suite being automated, which they were executing on the code every night. When we started to notice the quick turnaround on code issues that affected other modules, we asked what was going on and found, to our surprise, what they had accomplished. Needless to say, this was a wonderful advance for us as we knew our code base was getting a thorough testing every night, and any issues would be reported quickly. As the test suite expanded, the test automation kept pace, and we had a very thorough testing process in place offshore, managed by my experts onshore, that rivaled anything I've seen in any other company. All at a fraction of the cost of a normal test automation effort, and all done at night to maximize our development process time schedules.
Since then, moving to other companies, I've employed the offshore QA test in the same manner. They have their normal testing tasks to do for us, but in their spare time they would automate. A few years ago I got to the point where I would set up a small sub-team offshore just to handle the test suite automation, working with the rest of the offshore QA team to migrate manual testing to automated testing. For the low cost of the resources, we saved literally hundreds of thousands of dollars in onshore development and testing efforts, as well as managed to pare down our time-to-market dramatically for new features.
While test automation in and of itself is not a panacea for all that ails a software project, it does help provide metrics for software quality and ensure rigorous testing is possible for code changes. Less stuff broken means higher quality product. Catching breaks faster means faster fixes, means better process, means better products. And it all comes down to having the best product possible. That's why I love my offshore QA teams!