QA to Dev ratio
What is the ideal QA to Dev ratio? I always thought it was 1:2. The current organization that I am in is 1:6.
Originally Posted by swtester99
I think it depends on the criticality of the bugs and the level of automation, and how well developed the change control is. 1:3 will get very stressful without any formal change control and formalized deployment procedures (all phases qa/staging/production), things will be breaking and you'll have no idea what broke it. 1:4 without any peer code review will be very hectic, as you'll probably spend more time filing bugs than you are providing good coverage. 1:6 and above you'll need to have good automation or other ways of offload work like crowd sourcing. Of course some industry like banking, medical, etc... that has a high cost of bugs in the wild will need higher qa to dev ratios.
1:8 ratio in say a typical consumer web app you'll need the following
* Strict change control. QA needs to be able to track every change going on.
* A good merging and branching strategy. Potential merge conflict bugs needs to be minimized.
* Good amount of unit testing. You'll want at least 80% code coverage and 100% of low level business rules covered.
* A good amount of story (for agile) or requirement (waterfall) coverage on the end to end level with configurable tests on a solid test framework.
There is no ideal ratio that would apply across organizations, or even across projects. It completely depends on the context.
Post Thanks / Like - 1 Thanks, 0 Likes, 0 Dislikes
I'm with Joe on this one... It all depends...
Automated Testing Evangelists
Definition expert - noun - Unknown drip under pressure
I have always gone by the rule for every 2-3 Devs, at least 1 tester. Of course if they are not pumping out a lot of work and the QA is not over whelmed, then you don't need more, but if the work is non stop, more help for sure would be needed.
It all depends on the complexity of the application, work load and overall organizational setup.
very subjective question but mostly I have seen 1:2 ratio.
It varies. I'm currently the only tester in a team of ten devs and not overwhelmed - but we're working with mature products where typically much more work is needed on the development end than on the testing end (and there has been precisely one significant new feature introduced in the last 6 months). The last place I was at there were 6 testers and about 25 devs, but the pace of development (quarterly releases with anywhere up to a dozen significant new features) and the amount of regression was such that even with a massive amount of automation (which proved its value nightly) there wasn't enough testing resource to go around.
What I've seen is that if the development pace is high, more testers are needed. In some cases, 1:1 or higher is necessary (and almost never happens) even where there's mature automated regression. A slower pace means there isn't as much need for testers, and a lower ratio of test to dev is fine - regardless of the quality of code the devs are generating or how mature the automated regression is (where I am there's none. I'm in the process of creating it in my spare time - and I actually HAVE spare time to do this).
TL;DR - rapid development needs more testers.