Building a bug-free product is important at any company, but at a startup especially, it can make all the difference.
While there’s an old startup trope that your product should be so needed that people will use it even when it’s buggy, that advice does not seem to stand time. In today’s hyper-competitive environment (more companies were started last year than ever before), and with people more reliant on digital products (e.g. it was once okay if your chat client had 10 min downtime, today when your entire office runs on chat, it is a showstopper), quality is no longer negotiable.
At every company, but especially at startups, quality is a full team effort. It takes everyone on the team to be dogfooding the product, giving feedback and reporting bugs. Still, having a dedicated QA person on board to systematize testing, and be the point person responsible to not let a single bug out the door can be incredibly powerful.
While it may sound unconventional for early-stage companies to hire QA, I’ve seen in Jam’s userbase that it’s actually quite commonplace for even pre-launch startups to bring in QA these days.
So, how to go about bringing on your first QA tester to your early stage startup
Finding the right QA tester for your team
Just like with any role, it’s not about finding a QA tester. It’s about finding the right fit for your team.
For an early stage startup, you’re most likely looking for a QA tester who:
- is self-sufficient, is going to jump in and figure out how to get things done well without much guidance
- has a sense of urgency, and picks up the pace when things need to move fast
- enjoys working in chaotic and ambiguous environments, and is happy to adapt their process as the company grows
- has probably worked with startups before and gets how things are done, the process-light environment and the changing nature of the product
- has a lot of availability and flexibility to jump in within a reasonable time frame whenever your team is ready for a new round of QA
One approach is to use Tana, a company that trains QA and places them.
Another way to find someone who matches that criteria is to ask your startup friends. But let’s say you don’t get any leads from there, then what?
Below is a guide you can follow. This is how we found our QA tester.👇
There are great QA people on Upwork
Step one is to post a QA job on Upwork. In the job description, you should include the above criteria so people who won’t like the startup environment can self-select out of your pipeline. You should also mention you are looking for someone who can work ~4 hours every weekday (though of course there will be days with more or less depending).
Once some people apply, filter for the top job applicants (Upwork lets you filter by rating & job success) and ask them a couple of screening questions (I suggest: tell me about the tech startups have you worked with in the past, what company/team environment do you thrive in, how do you approach working with a new team, and tell me about your approach to QA - what’s the difference between good and great QA work?). You’re looking not only at their answers, but also their communication.
From those answers, choose the top applicants and hire them for a 1 hour trial project on Upwork. In that trial project, they will need to look through your product, and come up with a test plan. Also, they should create bug reports for any bugs they run into during this time.
This should help you narrow down your search to a couple of applicants who you will interview to assess who is the best fit for the job.
Working with QA
Once you find someone awesome, how do they work with your team? QA at every startup is different, and your process will evolve as you iterate each week. Here is how we work with QA at Jam:
- Every ticket goes through a QA step before being marked as done.
- For major changes, QA reviews preview branches and gives the 🟢 to merge to staging.
- QA reviews staging and gives a 🟢 before we ship major changes to production.
- QA reviews key flows in production after every new release looking for regressions.
(This is in addition to engineers writing tests, and testing their own PRs. Quality is a group effort!)
When QA finds any issues, they use Jam to file bugs to our issue tracker. Obviously, we are biased, but the benefit for us of using Jam is we ensure every bug ticket includes enough information for developers to get started without ever being blocked on follow up questions.
Pro tip: frequent communication in the first 30 days
The key to success is communication. Especially in the beginning of working with QA, there should be weekly communication between the engineering team and QA so they can iteratively build a process that allows engineers to move fast with a high degree of confidence.
Hiring versus contracting
There are pros and cons to hiring versus contracting, but for your first QA tester, I highly recommend contracting with someone, preferably from an agency. QA contractors and agencies have a lot of experience being dropped into a company without much guidance and figuring out how to be effective quickly. When you work with an agency, another bonus is agencies often have great processes for documenting their work so that when you need to scale up - or sub someone in while your QA tester is on vacation or out sick, that’s much easier to do so.
We work with Antidote QA, a QA agency based in Florida. They are awesome.
Bringing QA into Jam early on was incredibly helpful for us, and many founders I have talked to since have echoed the same. Best of luck!