Code bugs: not as gross, but harder to kill.
Not sure whether you should hire a QA team to test your software? You’re not alone. While there is no doubt that software testing in the development process is important super important, there are a lot of strong and compelling arguments against delegating the role quality assurance testing to a separate QA team.“Test is dead” was what former Googler Alberto Savoia said in his keynote speech in the 2011 Google Test Automation Conference. This guy believes that it’s more efficient to move the responsibility for testing back to the developers.
Here are the most common reasons for not hiring QA testers
- QA slows down production.
- Developers write better software if they realize there’s no QA to help them. QA gives developers an excuse for being lazy.
- QA heavily adds to the project cost.
- It creates a “them versus us” conflict between QA and developers.
- It’s more cost efficient to get issues from customers.
All of these are very good arguments, and many of these are really based on both the experience of PMs and developers themselves. But of course, there’s the other side to the equation as well.
Why developers shouldn’t do quality assurance testing:
- Developers lose focus. This is probably the strongest argument to getting your software testing done by another team. So you’re paying an above-market salary to a junior developer to find edge cases where the code will fail?
- Developers have a blind spot for our own mistakes. Developers, even other developers in the same team, are not the best people to check for bugs. At best, they miss a few bugs. At worst, it might piss them off and affect team candor. Developers are human too, despite evidence otherwise
- Developers don’t test for a living (but QA testers do). They know where bugs will likely be found, and have years, even decades, of experience doing it.
There are also a few more benefits to getting a dedicated QA team to test your code.
Benefits of using QA teams:
- QA testing isn’t that expensive. While it’s okay to keep testing in the team if you’re pre-beta and still scrappy. Once your software becomes something people depend on for their business or daily lives, it makes more sense to invest in testing. Especially if your bottom line really depends on working software.
- QA testers have no bias. Developers tend to get too attached to their own work and are unlikely to be flexible in adapting the two contradicting mindsets of developing and testing. A QA team on the other hand is detached, and will perform quality checks more rigorously.
- QA testing goes beyond the app. A QA not only tests the app technically, but also validates that what’s created is what customers want. App users nowadays expect ease of use and it’s the responsibility of QA to verify that the app works the way users expect it to work.
- QA testers have greater discipline in bug tracking, documentation and reporting. Developers hate documentation. QA teams remove this burden from the developers while also documenting code better.
Now there are arguments to keeping testing within the development team but once your team or codebase grows and you’re actually shipping products that are critical to your end users, we encourage you to take a look at getting a separate QA team to look at your code. Your next question might be: should I create an in-house software QA testing team or outsource? All things considered, it’s probably best you get a distributed quality assurance testing team since in-house teams will be expensive, not to mention hard to hire for. And getting an experienced QA team these days actually costs less if you get from outside the US. If you’re deciding on building a offshore QA team, ask us. We’ll walk you through how you can do it and how Get[Devs] makes remote QA feel as if it’s done in-house.