How many testers per developer

This is particularly true if the test strategy calls for a regression averse approach to testing and whether the resultant regression tests are manually scripted and manually executed or automated. Clearly with automation, there may be a lower ratio of testers to developers less testing effort but a more specialised tester skillset. The more complex the requirements, the more testing effort required. This may also mean a more complex development effort. It does not necessarily follow that a complex set of requirements requiring more development and therefore more testing will result in a meaningful tester-to-developer ratio that can be relied upon for estimation.

Again, two identical projects with identical complex requirements may differ greatly if one is implemented poorly, with insufficient unit testing and with a higher number of bugs in the software compared to the same software better implemented, more thoroughly unit tested and with fewer bugs. The latter requiring less testing effort and resulting in a lower tester-to-developer ratio fewer testers than the buggier software. The type of testing will significantly alter the ratio if say the application is more in maintenance mode, hence small changes are being implemented by developers result in a proportionally small amount of development compared to the testing effort including regression testing.

Any ratio will increase subject to what the testers are actually doing. There are a number of factors that will result in a higher ratio of testers to developers, including:. Part of the problem with identifying a reasonably accurate ratio is not just the reasons above but also the lack of data collected by organisations on this information. Thus, for many, it is not an exact figure that is sought but an assurance that the testing estimates are reasonably correct and there is a degree of confidence that the testing can be undertaken within the project time frame with the staff and budget allocated to this function.

A separate informal poll of participants from 29 organisations in a conference session found the most common ratio was one tester to three developers:. My own industry experience of large complex real time systems was closer to 1 tester per 10 developers on V model and Waterfall developments with team sizes of 10 to 30 developers. More recently, based on training courses I have run, the ratios articulated by testers on Agile development projects across a range of companies have been 1 to 2 testers for 5 or 6 developers with maximum team sizes of 8.

Much of the above discussion focuses on the pitfalls of using a tester-to-developer ratio as a crude tool to estimate the number of testers needed. Here, we get the BAs, QAs, and developers at the start to write automated tests that serve as the functional requirements for the work to be done. If we keep the rate of production of these collaboratively-developed tests in line with the actual rate of production that satisfies the tests, we never have to fear that we have something off balance.

And, yes, there will always be a place for QA exploratory testing on integrated code. But that should be automated as well into regression suites that are automated and repeatable. I get it. I need to reduce WIP, and not worry so much about rules of thumb to get software done.

But what about that test in the market? How do we get better at that? Businesses that produce software do it for a purpose. Usually a pecuniary purpose. Understanding the reasons behind why excessive WIP is such a dangerous thing to have may put the onus on the business to see how to incorporate smaller product tests, in terms of releases to the marketplace, more frequently.

For those of you who never saw or have forgotten Star Trek II: The Wrath of Khan , the Kobayashi Maru was a simulation exercise that Starfleet put all of its officers through to test if they could save the civilians trapped in a disabled ship in the Klingon Neutral Zone. Because of the constraints involved, no cadet at Starfleet academy had ever passed the test. Even the legendary James T. Kirk failed the test twice, only passing it the third time by reprogramming the simulator.

But we can fall back on the values and principals of Agility, just like Kirk did for Star Trek values and principles. Elisabeth has seen agile teams functioning effectively with significantly lower tester to developer ratios. This doesn't indicate that testing is less important, however.

In her experience, agile teams need testing skills at least as much as traditional teams. The difference is that these skills, and the responsibility for ensuring quality, does not rest with a few people called testers.

The entire team is working to build quality in to the product, as opposed to counting on a QA group to test quality into the product. Learn everything you need to know about saving time and delivering higher quality software and applications with test automation. Join a community of over , senior developers. View an example. You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.

Your message is awaiting moderation. Thank you for participating in the discussion. I've been working with the same Agile development team since and we have tried several testing approaches. The QA team focuses more on manual and automated system integration tests tests encompassing multiple stories. With this structure, we have 12 developers and 3 QA resources. Selenium Tests can greatly help the QA people with the generation of test data sets.

Some of our QA people use selenium to generate initial dataset specially when testing UI features and role based access testing. On paper, we have one-to-one developer-to-tester ratio but it is not always possible. All non-developers chip in with testing but not on a full time basis.

Sounds like an excellent setup to me. In a previous project we pushed the border even further to include a few automated system tests in the DefinitionOfDone for the developers, just to make sure that the testers got working releases from the build server.

We had about developers, 1 tester and 1 automation scripter, but we definitely felt the need for an additional full-time tester.

Really interesting article. I think it all depends on a lot of factors. But I agree, Agile changes everything. Since we "have gone Agile" testing has been more flexible and effective. And what about software?

We use KT I mean this one here: kanbantool.