On the agile-testing group, there has been a little discussion about offshore testing. Herewith, some thoughts, cleaned up slightly from my comments there.

Handoffs Cause Delays: Long Handoffs Cause Long Delays

With offshore testing we are likely to make the serious inefficiency of dev-to-test handoffs worse.

Whenever there’s a handoff from dev to test, there are delays. We all “know” that defect prevention is better than defect fixing, and it turns out that the sooner a developer learns of a defect after typing it in, the less expensive it is to fix. So if I develop something on Monday, and only find out on Wednesday that it was incorrect, I’m slowed down. Better to have found out immediately after coding it, on Monday.

The off-shore approach will generally insert a delay of much longer than a couple of days in the find-and-fix cycle. This delay is costly in time to completion of the product, and also costly in terms of management insight into the product’s status.

Mitigating Actions

If I had, for some reason beyond my comprehension, to use off-site testing resources, I would try my best never to ship them a defect, since the news would be late and the impact on my project would be substantial, whenever there was a defect. I would do this using several techniques in some mix or other:

  1. Test-Driven Development tends to make my software more defect free than the post-hoc programmer testing I used to do;
  2. Pair programming reduces defects by putting two developers' minds on the problem;
  3. Smaller feature stories improve things by causing us to think in more detail about what has to be done, and by making the mistakes, and thus their impact, smaller;
  4. Closer communication with the requirements-givers improve things by increasing understanding, and by providing earlier looks at what has been done.
  5. Actual feature testing on our shore would, though redundant, reduce defects found on their shore, and would very likely speed up the entire project.

Those practices are all of high value anyway, and except for number five would be efficient as well. Local testing might speed things up, but would of course have excess cost in dollars (or rupees), if not in time. There’s a more advanced thing to do, if I could get the help of the Powers That Be:

Don't Follow: Lead!

Have the testers work in advance of the developers. Have them produce automated tests prior to the assignment of the features to the developers, so that on Monday, when a developer thinks she might be done with a feature, she can run the pre-existing tests to find out whether she really is.

There are, of course, “issues” with this idea. My experience is that they would be worth resolving.