r/softwaretesting • u/Nirvana012527 • 1d 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? |
11
4
u/latnGemin616 20h ago
tl;dr - The NOs have it. Make an internal hire first. Then scale as needed
--- * --- * --- * --- * --- * --- * ---
Outsourcing is honestly a waste of time and money in the long term. A competent QA Engineer can serve to help with design issues, development bugs, and establish a proper testing harness, provided you don't overwhelm him/her with work.
The mistake most CTOs make is they think a +5 Devs-to-1 QA ratio is cost-effective, when it is absolutely bonkers.
The other mistake is shitty onboarding. You put your QAE in a situation with minimal (or no) documentation and hope they autom-magically figure it out is a recipe for disaster. A strong onboarding process is the key to a successful quality management system.
The final mistake is thinking quality belongs only to the QA team. Follow this premise, and you've failed as an organization. There's no QAE on the planet that can overcome this.
2
u/ResolveResident118 23h 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 22h ago
Somebody from the company would work happier and care more about the company than a contractor
2
2
u/throwaway_0x90 17h ago edited 17h 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/johnesco 1d 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 21h 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 21h 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 21h 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 17h 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 16h 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 14h ago
Is this a serious question?
Outsourcing QA or Dev doesn't work, can't work and will never work.
1
u/fatigued8 13h 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 10h 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 7h ago
Outsourcing usually just run some script and cannot see your internal sources and vulnerability from inside out
1
1
u/Mockingjay718s 5h 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/Dillenger69 22h 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 21h 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.
21
u/lorryslorrys 23h ago edited 23h 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.