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.
The design of your application can define its success; therefore, as a developer, you need to think about how to organize your CSS to have the greatest impact. The traditional way to organize CSS files in your React app is to import them into each component that is using that…
Why build or buy a robust feature flags as a service platform when you could just implement a simple toggling mechanism as a one-off and be done with it?
Blind spots have a way of coming back to bite you down the road. When building software, the size of that “bite” grows exponentially with time.