What is a good ratio between developers and software quality assurance people?

There are many answers to this question depending on the stage of the startup and where they stand in the product development cycle. Also, it depends on the type of software development and the industry sector they play in.

Some types of products and technology stacks lend themselves to test-driven development - in which case a few QA engineers can go a long way. Other products may require manual testing - for instance, software that runs on custom hardware needs full system testing via manual testers - and in those cases, you would need a healthy balance between developers and quality assurance engineers.

The balance also changes depending on the current stage of the company. For a software startup, in the beginning they are really not doing production level coding - they are prototyping and hacking and creating testable MVP's (minimum viable products).  During this phase, when the total headcount is below 5 full time equivalent, they can get away without a dedicated software quality assurance (SQA) function and share the burden of testing their software between themselves and their early users / testers.

When the team starts to get beyond 10 people and they are really starting to crank out product releases, quality and reliability becomes important because the lack of these things will result in reputation risk and an erosion of trust by customers. 

For non-mission-critical, cloud software systems that are compatible to continuous integration and continuous deployment, you should start standing up a QA department and go for more automation engineers and fewer manual testers.

For companies developing custom software on custom hardware, or companies developing products in highly regulated industries such as healthcare IT or financial services, you may want to move towards a developer-to-SQA ratio of 3:1, moving to 2:1 as the team scales and capping off at 2:1. You would want to have more manual testers than automation engineers in cases where the custom hardware is very complex, or the ultimate quality and user experience requires a human in the loop (such as robotics and haptics).

 

Was this article helpful?
2 out of 2 found this helpful


      This website and all posts and content are intended for educational purposes only and for no other purposes. This website does not and is not intended to provide legal, financial or tax related advice. Although we take great care to make sure that all of our information is accurate and useful for it intended educational purposes, if you have a specific issue for which you need actionable advice, please come to the Martin Trust Center in person to speak to one of our Entrepreneurs in Residence (EIR) or consult a licensed attorney or other professional. Despite the backgrounds and qualifications of our staff, mentors, lecturers, authors, EIRs and speakers no attorney-client, advisor, or other confidential/privileged relationship exists or will be formed between you and the Martin Trust Center or the Massachusetts Institute of Technology. Under no circumstances should any content be relied upon in making any decisions that could have any financial or legal impact(s).
Have more questions? Submit a request

Comments

Powered by Zendesk