The general advice on when to hire your first QA is simply "as soon as you can afford one". But that is not actionable advice. A startup's decision to hire a QA engineer is going to be highly contextual and we cannot cover every case. Instead, we'll present you with an array of solutions we have seen startups try before they hire QA. You can pick and choose what suits your context. Once you have tried most of these solutions and still have quality problems, it is probably time to hire professional QA engineers.
We have been the first QA at several startups. Here are some ideas for you to try based on what we have seen startups do before they hired their first QA engineer. We have broken down our advice based on job roles, so you can jump to the sections that you find useful.
1. Hiring and orientation
Better hiring practices is an under-used way to improve your organization's testing IQ. Consider modifying your developer job descriptions to include a line about testing. During the interview, ask about their experience in writing tests. You'll be surprised at how many developers have setup some sort of automation framework at a previous job.
Another useful trick is to have at least one automated test setup and ready to execute for new hires. A quick test reduces the friction that new developers feel towards testing. Make one of their first tasks writing a new test for you.
2. Development teams
Add more forensics to the application: logging, monitoring, 'login-as-user'. If the volume of bugs you have is pretty large, consider assigning one developer per sprint to only squash bugs. You could consider (we don't like this either!) having 'hardening sprints' to periodically pay off technical debt. Another common approach is to hire an intern to setup some automation. If you try this, let them find and use an existing framework and not write one on their own.
Note 1: We assume you have tried to make your developers write more tests.
Note 2: Some companies dole out funny punishments but we have no idea if this is effective or not.
3. Cross-functional teams
Our experience is that the first version of a feature is the buggiest. So take the help of your product owners and support staff to test new features before they are deployed to production. This activity alone will save you a lot of time over the long run. You can also try regular bug hunting sessions - typically a Thursday before close out. Ask your sales and pre-sales teams about their demos - this is usually a good indicator of what features are important and need thorough testing. Document at least a few user-facing acceptance tests. Usually, your product owners and customer success teams can help a great deal with this activity. Try to come up with acceptance criteria for each ticket during your planning meetings. Dog food your product, if applicable. Communicate better on your tickets.
Pro tip: Make sure you teach the business side of your company how to file clear, reproducible bugs. If not, you are going to be frustrated with the number of unclear bugs you end up handling.
Note 1: We assume you have tried process changes like code-reviews, better planning and estimation, etc.
4. Outside help
If you have tried your best and you still have quality issues, you can try a few other things before you hire your first QA:
One final tip: We see too many startups do not have realistic ideas about testing. So during this process of trying to manage testing on your own, develop a feel for what you can realistically expect from your first QA engineer.
© Qxf2 Services 2013 -
