This quality problem inflicts especially organisations where the acts of programming and testing are clearly separated from each other. If it seems that the testing is the bottleneck in the organisation, it might not be the testers' fault.
Often testers have too much to do because too many bugs slip through from upstream, the programmers. If this is the case it makes more sense to tighten the checks upstream than adding more testers. The testers have generally no control over the number of bugs in the code. They can only report the bugs they find. In general, this does not lessen the flow of new incoming bugs in the future at all. The programmers will fix the found bugs but learn typically very little in doing that. The feedback is not timely enough for learning. The programmers keep on making similar kinds of errors. You'll need to provide faster feedback to the programmers to enable their learning.
One way to provide good feedback early is to check the code as soon as it is written. Qualiteers Code Inspection can be performed on code, which doesn't even compile yet. Even then, the programmer gets meaningful feedback from his peers. Once the programmers learn to avoid typical mistakes in coding, the testers get less buggy code to test and can manage more test cases in less time. The imbalance between programmers and testers corrects itself.