At Split, our first hire was a Quality Automation (QA) Engineer. It would be an understatement to call it unusual. I’ve yet to see another company that has done this. In fact, most companies don’t hire a QA engineer until around 20 employees.
However, it is one of the best decisions I ever made. I believe that a QA engineer should be one of the first 10 hires of a technology company.
Hear me out. There are many arguments for why people put off a QA hire, but they boil down to three key points:
- Money – We’d rather spend limited, early-stage capital on engineers building the product.
- Little Customer Traction – We don’t have a lot of customers; they can deal with lack of quality.
- Devs do QA – We expect our engineers to do their own testing.
These are all fair concerns, however, they miss the point as they are rooted in looking at QA as a tactical function, and not a strategic one. Let me explain.
Why QA is critical for early stage startups
Most early stage companies fail. The ones who succeed iterate fast in search of “product market fit”. Until they achieve that fit, nothing matters.
In engineering terms, this boils down to moving fast even if it means breaking things. However, from our experience, a quality automation engineer builds systems and tests that put guardrails around the rest of the engineering team moving fast. Even if things break, they don’t cause disruption for hours or days. Without those guardrails, the engineering team slows down, tripping over its own speedy shoes. The productivity gains are worth the money spent on a QA engineer, as fast moving engineering teams help find product market fit faster.
But, what if you only have a handful of customers, or worse yet, no customers? When the customers are few, this is the time in a company’s life when the product rapidly increases in its surface area. Every sprint comes with a batch of new features. Without an investment in QA, the quickly expanding product can end up without any testing. As a result, when you do get customers, each new release can lead to bugs destroying customer experience and confidence. An early investment in QA helps with customer success.
Lastly, some engineering cultures expect developers to test. This is a great movement, but in practice it leads to quality without automation. Continuous delivery – which is at the heart of fast moving companies – requires automation and infrastructure for UI testing, integration testing, regression testing, and canary deploys. Your engineers are going to build the product, not the infrastructure.
And just to be clear, when I think of a QA engineer, I am thinking of a Software Development Engineer in Test, similar to those at Google. These people are not selenium test writers. They do that, plus work as software engineers who build the infrastructure necessary to let your entire team acquire a culture of testing.
Focusing on QA early on equates to higher ROI
Our early investment in quality has made our product stronger and customers happier. Even as a young company, we have built a canary release infrastructure, integration tests for every REST endpoint, 24/7 QoS tests, diffy, as well as framework to test fat clients written in over 9 different languages. As a team, we are proud of what we’ve accomplished. Check out some of our open source contributions here and here.
So take my word for it. Hire a Quality Automation Engineer as one of your first 10 hires. You will see a great return on investment in the months to come.
And if you are an engineer who deeply cares about quality and craftsmanship, join us.
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
Last week, I spoke about the foundational idea of decoupling deployment from release. This week, let’s answer the question, “Why would I want to?” At a high level, there are really just two reasons: #1: You want to prevent code that’s still a work in progress from being exposed to users…
Recently, there was a very active twitter thread that started when John Cutler asked whether everyone knew about the idea of decoupling deploy and release: From the replies, retweets, and likes, it was pretty clear that not everyone knew about decoupling deploy from release, and how feature flags make that…
How do you know if your rollouts are going well and should be ramped up or are surfacing issues that need to be fixed before you ramp up? That’s the focus of today’s post and video.