Software is buggy. If you ever tried to build anything you’ve probably noticed that. It’s quite common for a feature to be causing problems after being merged into the main codebase, so someone has to go over it and write down all issues that were found. Sometimes it’s done by the developer himself, which is a good thing because good developer always tests his work and fixes most obvious bugs. Sometimes it’s done by the product manager. That's also good because the product manager should be aware of how features are supposed to look and work and should have to try using them. But still, it’s quite common for a client to find bugs as soon as deliverables are handed out to him. If that happens often then most likely you don’t have a QA engineer.
So why do you need to do separate quality assurance and have dedicated employee doing this? Well, it turns out that most people only test the happy paths that they assume a user would take. A QA engineer would test all possible cases in combinations that a developer or a PM wouldn’t have thought of. They would try to log out in the middle of the checkout process, breaking a usual scenario. They will try to log in if they are already logged in — something a developer would never try for sure. Or they would try to enter large text written with non-ASCII characters in the comment box.
Good developers don’t write software with bugs (Wrong)
That couldn’t be further from the truth. Of course, a junior developer with little experience will make a lot of mistakes but even seasoned senior dev can’t predict everything. There are a lot of ways to reduce the number of bugs like automated tests, code analysis tools and code reviews, but there’s no way to get rid of them altogether. That's something that has to be accepted, just like the fact that it rains in the summer.
Another reason for bugs is multiple environments of the app. Typically developer tests his feature either locally or on a development server, but after the code is promoted further down the pipeline — to staging or production server, new bugs may and will pop up. There are many reasons for that such as different server config, other code merged into the code base that affects the feature in question, or maybe different pieces of the application being out of sync — for example, the backend has been promoted to staging and frontend still wasn’t updated.
But I can’t afford another person testing the app.
Someone does testing anyway. Either it’s the client who is paying for the work, or it’s PM or a developer. QA engineers time is much cheaper than developer’s or product manager’s time, and the client doesn’t usually have enough time for testing leaving features untested. The problem is that testing is boring and tedious to do. If you make skilled professionals do it, they would get sick of it and leave the team in search of a team that can afford more professional environment.
Hiring is not hard though because just you’re going to have a lot of turnover. Good testers typically get bored and move on so you would have to hire constantly to keep an inflow of people. You would want to provide testers with options to develop their career and learn programming by developing automated tests. That will make them loyal, and they will help newly onboarded members to get up to speed.
Customers will do the testing (Wrong)
It’s quite common to release beta versions and let customers report bugs. While this works in general because it’s impossible to catch all bugs during development or QA, it really makes sense to catch most obvious bugs early before customers spot them. Otherwise, you will be overwhelmed by the number of bug reports, and it will be tough to process and prioritize them.
There’s also a big problem with the way how customers report bugs. Their bug reports typically lack details necessary to reproduce the bug, so it takes an enormous amount of time for a customer support person to learn the details and then pass the bug to the dev team.
What makes a good QA engineer
Good QA engineer is looking for excellent customer experience in multiple areas — copy, usability, functionality. They always keep the user in mind instead of just detecting issues. They usually use automated tests where applicable to speed up the process and make testing more efficient. Writing clear, understandable tests that can be used and maintained by the team is also essential.
Well-written tests can be used as documentation, helping team members understand how the app works by running them manually. There are always lots of edge-cases and sidepaths to test so a good tester should be very organized to set priorities well and aim for quality rather than quantity of tests.
You can get away with testing yourself, but hire QA engineer as soon as possible
Of course, if you have a very small team and there’s nothing really to test you can get away by one of the devs or PM doing the testing but keep in mind that over the months as the code base grows testing will become much harder. Every new feature you add will potentially affect other features that you already had, so regression tests have to be performed every so often — meaning that you have to test everything in the app from square one to the very last feature. That quickly becomes cumbersome, mainly because there’s no process of writing test cases and documentation in the beginning.
If you can, try to hire temp testers to come and fiddle with your app for a few days — some of them will be good enough to hire them again. Look for unusual testers — college grads, smart teens, summer workers. They will save your budget but will alleviate the burden off your regular team members. But in my opinion, nothing can beat QA engineer who has domain knowledge and has been with your team for a while so hire one as soon as you can.
