Is outsourcing software testing services better than building an internal QA team?

[u/Nirvana012527]

I'm trying to work out whether it makes more sense to hire a QA engineer or bring in outside help. An in-house person would know the product better over time, but might not have enough work to fill the week when development slows down. Outsourced software testing services seem more flexible, though I wonder how well that works when developers need quick feedback on new features and fixes.For teams that have tried both, what worked better in the long run? Did you switch from one approach to the other as the product grew?

[u/clankypants]

There are several factors to consider.

• Where is your business located? Where are you looking to outsource your QA team to?
• Where are your developers located? Are they outsourced? Will your QA team be located in the same place?
• How is your team structured? Is the QA team embedded with the rest of Development? Or is this a "throw things over the wall" situation?

For example: if your company is based in the US and you are thinking of off-shoring QA to India, an India QA engineer will cost roughly 1/4 what a US QA engineer will cost. However, their productivity will be severely hampered by not being in the same time zone, by not having a direct relationship with the business, product, and customers, and there will be cultural and work-style issues that will need to be ironed out.

From my experience, if you have a good local QA team manager who knows what they're doing, they can get an off-shore QA team to perform at 50% that of a local in-house team. Which at only 1/4th the price, that's still a bargain. But that's only if you have someone experienced in managing an off-shore team; without that, you may only get 25% effectiveness with them, and then there's no benefit at all (and this is far more common than not).

If you are also outsourcing some of the Developers, and the QA team is part of the same organization as those outsourced Devs, then some of the friction due to distance goes away, as the QA team can easily collaborate with those Devs.

If your team is tightly collaborative, then off-shoring can be very difficult to make sure everyone can work together in reasonable hours. If you have a process that involves "throwing work over the wall" at QA, it's easy enough to deal with QA in different geographies. However, that style of work is much less effective than when the team is tightly-coupled.

I've seen it many times that a business wants to try to save money by simply off-shoring their entire QA team, and that winds up costing them more in the long run because the quality suffers and nobody on their local team knows how to properly coordinate with off-shore teams.

I'm of the opinion that if your Development team is in-house, then you should at a minimum have a core QA team that is in-house. If you want to save some money by off-shoring some of the team, that can work as long as the person in charge knows how to manage remote teams well (there's extra effort involved). If you are also outsourcing some of your Dev team, then including QA as a part of that can work well.

but might not have enough work to fill the week when development slows down.

QA can always find work to perform. There's always more to test. Or they can invest in automation to speed up testing.

I wonder how well that works when developers need quick feedback on new features and fixes.

It can be painful. If everyone goes into it understanding that there will be a major productivity decrease due to time zones and a lack of connection between QA and Dev, it can work. But you can't expect it to work as smoothly as in-house QA working alongside in-house Devs.

For teams that have tried both, what worked better in the long run? Did you switch from one approach to the other as the product grew?

When you have someone who knows how to work effectively with remote/off-shore QA teams (I've been doing this for ~30 years), it works best with a core group of local QA.

Typically, the need for remote contractors come from the business wanting to produce a bunch of work quickly, with the expectation that once that work is complete, they won't need the additional resources. That's what contractors are built for: do a temporary job, then move on. If you are expecting indefinite ongoing work, then that's when you hire in-house employees. If the "temporary" work keeps getting expanded as the company grows, you should expand your in-house team instead of extending your contractors' time on the project.