Going from no testing to full QA automation

Problem

"With a small team, it's common for engineering to test their own code. Sadly, this can result in missed bugs due to the myopia that comes from testing your own work. As the work grows, this problem gets worse."

Actions taken

"As we've grown the engineering organization, I've been focused on maintaining a QA-to-engineering ratio of about 1-to-4. This ensures that there's always a third party that is focused on testing. At first, these tests can be manual; this will also mean that you can hire someone affordable. A critical procedural invariant to have here, though, is that any regression, i.e. something that used to work that no longer does, needs to be taken as very high priority and resolved ASAP. Without this, your users will not have trust in your product, as they will have learned that what worked today may not work tomorrow."

"With this acknowledging, we've focused on fixing regressions quickly, and when we had budget for our third QA person, we hired someone who had interest in automation. From this, we started by automating the most common, least likely to change test cases (e.g. logging in, creating an account, etc.). These automated tests then get run every time new code is checked in. Through a continuous build, we're able to then catch bugs as soon as they enter the codebase."

"If code coverage is measured and regularly shared broadly, the team will focus on improving the coverage over time. By focusing on these tests as well as developer-initiative unit tests and other functional tests, your code is more likely to be stable in production over time."

Lessons learned

"Start with no QA, but as you grow your engineering team maintain a ratio, e.g. 1-to-3, 1-to-4, or 1-to-5, whatever feels right for what your organization does. Manual testing is a great way to get started, but automating overtime is critical. Again, regressions must be treated with very high priority to maintain user trust."