It’s often said that people divide into 2 groups:
Or maybe you’ve heard that nobody thinks they need an IT security guy until someone eventually hacks their system?
I would say that it’s similar with QA specialists but worse, because in contrast to not making backups and not having security guys, lacking a good QA specialist constantly harms your product and your team - not just in case of a critical mess up.
Technically a QA specialist is a software tester responsible for catching and describing bugs before they go to production so your poor users don’t find them first.
In reality, QAs probably do a little bit more than you would think. Their work starts even before a single line of code is written - when they need to gather all the business knowledge to know how things should work in the first place. Or preparing a test suite which is a collection of test cases covering all user flows.
During the development phase, they are responsible for more than just testing new features. At the same time, they’re also responsible for testing backwards compatibility with all other previous functionalities to make sure the new ones did not break them.
When you think of QAs as I described them above it seems they’re just a natural part of the development team like programmers and designers.
Developers, designers, scrum masters, business analysts… They’re all not trained to test the app they’re building. Them thinking they can split the QAs’ work between themselves is a worst case scenario.
You see, these guys have their own goals and priorities. And none of them is looking for an edge case that will break the app - trust me. Of course you could say: developers are responsible for producing working features with their code, so why don’t they test the app? Well, having developers testing your code leads to two unwanted situations.
First, they will be testing the app in a way they know it will work. Inside their minds they have a single scenario of how users should use that feature and that would be the flow they will focus on. In the real world, users will try to use the app in ways you would never imagine (or at least your developers).
Second, you actually lose money not hiring a QA. It depends on the project but usually developers are a little bit more expensive than QAs. That means when you ask your developers to focus on testing, you’re spending more money but the outcome can be far from satisfying.
Talking about money, there’s another reason to have a QA on a team. Not testing your product during its development doesn’t mean it doesn’t have bugs. It just means these bugs will be eventually found by your users (with more or less serious consequences, sometimes even legal). You will probably ask your team to fix that bug ASAP, but after a few weeks or months after publishing it, it will be much more time consuming to debug it and fix it. For example, there could already be a few other functionalities built on top of that broken one.
First of all, the whole team will thank you for letting them work with an experienced QA specialist. You will notice an improvement in team morale. They will start delivering new versions of the product with much more confidence.
It could also increase your conversion rate because your users won’t notice as many bugs, making them happier and adopting/loving your product faster.
To be sure you hired the right person as a QA, they should be active in both the business and product team meetings because they should be engaged in the whole development process.
A good QA works very close to the business to fully understand what specific features the team is going to build and who is going to use them. This kind of knowledge is necessary for them and it’s important to let your QA be a part of the business team or at least provide him with a set of documents or recordings of meetings where these details were introduced.
An experienced QA will not only find and report bugs in your product, but should also prepare a small report describing how to reproduce it, what was the environment and the app’s state when that error occurred, and sometimes even suggest a solution for that problem. Especially in case of UX type of bugs, when there may be no specific error, but there is a usability issue, a good QA will catch these problems too and will suggest an alternative to the current implementation.
If you read the whole text above, you probably agree with me and understand that a good QA is irreplaceable in every product development team. It’s not someone whose work you can split between other team members. It’s someone who binds the whole team together and assures the quality of your product.
But if you still don’t agree with me… Well, I hope you won’t have to find out what it’s like to build a product without a QA ;)