QA to dev ratio [closed]

Question

We have a pretty complex Java system which includes a few back-end tiers including a database and a proprietary Swing front-end. There are back-end APIs to which external parties can attach that mimic our front-end. There are approximately 5 silos within our org that share this system. In total there are around 15 developers maintaining this system.

Is there a rule of thumb on what the size our QA team should be?

Edit: To add a bit of context based on questions raised in the responses thus far:

1. We have about four major releases a year, and a bunch of minor ones in between.
2. Our platform has money changing hands, so there are calcs that mean a lot to our customers.
3. We do use a formal bug tacking system.
4. We don't utilize TDD.
5. We use tools like cruisecontrol for continuous integration.

Answer 1

As a former test team lead, I would suggest having as much testing as you can. It sounds like a lot of people in your organization depend on your software. Test early and test often.

It's very important to realize that testing is everyone's responsibility. Developers need to be writing good unit tests. UI developers should be manually testing the UI.

I try to encourage test driven development, keep eyes on metrics (using a formal bug tracking system, tracking defect densities, etc), setup a continuous integration service, and design code for testability (use a framework like Spring for dependency injection, use mocks and stubs for external services, etc - I'd be happy to discuss in more detail). The cost of fixing a bug gets exponentially more expensive the later you find it, so it's best found before it gets to formal QA.

Jeff

Answer 2

A rational QA to dev ratio can only be derived relative to the complexity of an application in question.

Clearly, an uberdeveloper can probably come up with a complex application where only 3 QAs full time can efficiently test because of the complexity of the workflow; in turn, there can be 1 QA for 3 junior devs piecing together a relatively simple input-output report application.

So the number of QA personnel you need will be determined by the number and complexity of requirements you have, and not the number of software developers you use.