What are the minimal quantity of testers per programmers? [closed]_问答_开发者

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. Closed 12 years ago.

i want to know if exist a ideal qua开发者_JAVA技巧ntity of testers per programmer. I heard that in many enterprises exist 1 tester for 20 programmers and i don't imagine how this is possible, whatever the question is exist a ideal quantity of testers per programmer? if exist, how is the relation ?

It's completely dependent upon the organization, and what priorities they set on testing, how much unit testing the developers do themselves, etc.

Depends on the programmer. If you work at Microsoft, the ratio should really be 20 testers per programmer.

In the ballpark between one to one and five to one, developers to testers, is what I'm used to seeing.

It varies based on industry, team, development cycle, and a lot of other variables. I'd go heavier on testers with a less experienced - or offshore - dev team.

It very much helps to have automatic tests setup to smoke test new builds, or to go further, and do some automated testing plus continuous integration.

it depends organization to organization. But for a quality product it should be 1:2 i.e. 1 tester per 2 developers.

If you are doing test driven development, then there are 20 testers for 20 programmers.

This depends a bit on what methodology is used as if someone is following a pure Waterfall methodology then the testers may not be needed until the next stage for example. Some enterprises may have no testers, though I think this may reflect other ways that quality control is handled.

Where I work for a project we have 5 developers and 2 testers, but earlier in the project we had no testers. The quantity can vary and I doubt there is an ideal that can be applied universally to all company sizes and methodologies. Where I worked before where I am now, there were a handful of developers and no testers most of the time, with one tester popping up every so often as the company would hire a contractor who would then pursue other opportunities after a few months.

In answer to the title question, I believe the minimum would be zero testers as it is hard to imagine having a negative or imaginary number of testers that would be lower than zero.

The minimal number is 0 testers, of course. That's far too few for most organizations, I'd think. Most places I've worked have been in the range of one tester per ten developers to about one tester per 5 developers. We could always have used more good testers, though.

It is posible because the programmers are supossed to test their own code before passing it to the tester... but this is not always true ;)

You won't find a concrete answer because of the sheer amount of variables here.

Legacy code can be very stable or very buggy if being incorporated or updated.

New code can be buggy because of the programmers or even when they worked on the code. I would expect code done around a holiday or Friday to be more likely to have issues than stuff on a normal work week Wednesday.

Your best bet is to look at the needs of your organization against the resources available and make a conscious decision to splurge on testing. While QA is often assigned a low priority, it should not be and a dedicated team (even if it is a team of 1) should be checking how things interact at all stages of development. Having done this I can safely say it ends up costing less if the issue is found early and programmers are given plenty of warning.

Just as with programmers, the star testers can be much more productive than the bulk of their peers (the best guy I've worked with has managed on some projects to make almost half the total number of problem reports all by himself). Unless you have such a star to hand, having less than half a tester per programmer throughout the project (from design through to release) would risk cutting corners on quality.

Testers per programmer isn't going to work. Try Function Points per tester or Functional Subsystems per tester. Testers are verifiers of functionality, not sieves for crappy code.