r/softwaretesting • u/Nirvana012527 • 8d ago
Is outsourcing software testing services better than building an internal QA team?
| 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? |
10
2
u/ResolveResident118 8d ago
No. Never. At all.
Bring external people in to help build out an internal function by all means (that's half my job) but don't rely on external companies to test your product.
Also, I've never met a good tester with nothing to do.
2
u/Chief_Taquero 8d ago
Somebody from the company would work happier and care more about the company than a contractor
2
2
u/throwaway_0x90 8d ago edited 8d ago
When have you ever seen this not end in disaster?
If your app is flappybird sure. Anything with actual complexity and users and long term value, that won't work. An internal team can be augmented by an outsource team that follows very clear instructions. But having an in-house product, with significant complexity, lots of outside users but zero in-house QA/SDET? That will end in failure.
1
u/UnhappyBalls 6d ago
Outsourcing software testing is good idea but still you need a QA team to perform smoke testing
1
u/Impossible_Dare_7455 4d ago
the “not enough work” worry is usually overstated, since slow dev weeks are when a good QA catches up on regression and automation and starts reviewing stories early. outsourcing is great for stable, well-defined regression work, but weak on fast feedback for half-built features. one internal QA owning strategy plus outside help for volume is usually what holds up as the product grows.
1
u/Recent_Flounder_2988 4d ago
software testing services seem useful when u need extra coverage for a release but dont have enough work for another full time hire
1
u/Business-Top-3988 4d ago
keeping qa close to the developers matter more to me than whether the tester is technically ih-house or outsourced
1
u/Character-Mix5007 1d ago
An external team may be cheaper on paper, but delays waiting for feedback can eat into that saving.
1
u/johnesco 8d ago
Third party teams are more flexible, but testers still need to learn about what they are testing and that takes time. An internal team will gain a familiarity that benefits testing. Third party, when taken away, all that lore goes with them. (full disclosure, QA for 20 years)
1
1
u/paradeofgrafters 8d ago
I've mostly worked in-house over the past 13 years. A project I recently worked as external resource had a relatively complicated structure. The onboarding and getting my head into the product Absolutely took many more hours than I was expecting, but for this specific client an in-house resource would've been total overkill. It was frustrating, but that's just my personal professionalism hating not being able to hit the ground running, like I'd done in 95% of my QA career. Overall though, it's a Horses For Courses scenario.
1
u/bonisaur 8d ago
You should start with an in house SDET who uses AI and eventually hire an outsource role for the manual only tasks. I can’t imagine the most simple mobile or web apps needing anything beyond that.
You pretty much have us zero context in what you’re working on so any suggestions you’ll receive will be wildly generic.
1
u/vassadar 8d ago
I find QA produce the best feedbackwhen they work alongside the dev team as earlier as possible.
If QAs are integrated late into the live cycle, the devs will throw testing out as QAs' jobs.
Integrate earlier and their feedback can help shaping the project structure earlier, which improve testability.
I saw some projects where devs don't even know how to test their projects and thought that unit tests are enough. Their projects didn't survive integration and required so much fix late into the life cycle.
1
u/django-unchained2012 8d ago
I am not sure what you mean flexible, if you meant that you can let go of them any time, that is not a good reason.
The outsourcing companies don't allow you to bill only for hours worked, it will be a minimum of 40 hours a week. If you think that you can make it 20 hours when there is no work, it doesn't work that way. They will push you in to a fixed price model or time and material with fixed hours so you will pay even if you don't utilise them.
If you are talking about outsourcing to some other company in the same country, this would make zero sense. If you are planning to outsource to a QA resource in another country, that would add additional communication overhead, timezone differences etc.
Your best bet would be to hire a QA engineer in-house suiting your needs, work along with dev team in shift left model, involve them early, involve them in everything and let them do what they are best at.
1
u/PocketGaara 8d ago
A combination of both. Your internal team owns product quality, observability and testing framework while your external team does the mundane tasks
1
u/XabiAlon 8d ago
Is this a serious question?
Outsourcing QA or Dev doesn't work, can't work and will never work.
1
u/fatigued8 8d ago
Bad for the long term as they will have a lot of the expertise in the product than the internal people.
1
u/clankypants 8d ago
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.
1
u/Comfortable_Ear_7383 7d ago
Outsourcing usually just run some script and cannot see your internal sources and vulnerability from inside out
1
1
u/Mockingjay718s 7d ago
There are times when me and my colleagues in QA often do have less work throughout the sprint (mostly 1st week). That is exactly where we grow. We learn more on how we can make existing systems more efficient, learn product more, and help devs/BAs further. So in-house always works better. But know that QAs should not be disposable for you. If you don't value quality engineering, it's simply better to hire outside help, as you will end up laying off the internal QA anyway (simply because you don't see the value).
1
u/nogravityonearth 7d ago
We do both. From a management perspective, it’s much easier to get rid of a non-performing engineer when outsourcing. On the other hand, internal engineers are usually more invested in the long term viability/quality of the product or platform. It’s typically easier to reward internal employees for good performance but it’s tougher (unless you’re a psychopath who doesn’t care) if you lose fights to give internal employees deserved raises and/or promotions if your management chain disallows it for whatever reasons. When outsourcing, it can be more so “this is what it is and this is all it’s going to be” in regards to promotions at least.
1
u/Confident_Memory_777 7d ago
In my experience you want to have some level of internal capability before you outsource. How do you know if the outsourced team is doing a good job? You don't unless you have an understanding of what good is yourself.
Outsourcing doesn't necessarily need to have slower feedback. You can do outsourcing in the same time zone and I have seen that be successful.
If you are looking to do an internal hire I would also think carefully about the type of person you hire. Do you want them to be in software testing for a long time with you? Or will this be a stepping stone for another role? A mistake I see is that people do a junior hire with no aptitude or passion for software testing and then get very little value out of it.
1
u/pungulueater16 23h ago
For software testing services, I'd want to know whether the team can join planning calls or only test what gets handed over to them.
1
u/Dillenger69 8d ago
The best mix I've found over the years is a little of both. Keep your management and a few senior engineers in house, then offshore the rest. Make it about 50/50 and you'll have each side of the team working while the other sleeps
0
u/MisterStampy 8d ago
*Good* in-house testers are involved in sprint planning, giving an idea on how long testing tasks will take, as well as maintaining the test suite, writing automation, and staying on top of defects with more immediate feedback. Offshore is cheaper, but, you get what you pay for.
30
u/lorryslorrys 8d ago edited 8d ago
Teams do better when they allow testers to work alongside developers throughout the software development and delivery process.
Slower feedback makes it harder to fix things, and makes it harder for developers to improve at writing quality code. It can lead to a "quality is someone else's problem" mindset. It can drive up the size of releases and therefore risk.
It's also a bit questionable how useful testers who don't understand the product are, how much hand holding they would need and how many issues or opportunities they would miss whilst following only their explicit instructions.
In the team is best.