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.
With feature flags, you can control the percentage allocation of users you want to be exposed to a specific feature. This process provides risk mitigation and confirms both usability and scalability. Canary releases, or controlled rollouts, serve as an added layer of protection in case something goes wrong. What is…
Feature flagging is a technique development teams deploy to enable easy switches between codepaths in their systems, at runtime. In simpler terms, they’re control structures that toggle on and off the code inside them. Dev teams use feature flags for a wide variety of purposes, from canary releases to A/B…
If our organizations want to survive this period of political and economic uncertainty, they must be able to move with speed and adaptability.