Quality Quest: The Irrational Ratio

While there's no hard and fast rule for determining the best mix of developers and testers, the secret is to know when and why to adjust the ratio based on the type of development and the phase of the project.
Posted September 1, 1998
By

Linda G. Hayes


(Page 1 of 2)

Linda G. Hayes

Do you remember learning about irrational numbers? I always pictured them as being somehow unreasonable, numbers you had to coax or cajole into behaving rationally. Actually, they are numbers that never end--no matter how far you carry them out--like pi. In that sense, the term is particularly apropos for describing the proper ratio between developers and testers, because the answer keeps changing the longer you look at it.

Not a conference or class goes by that the question is not asked: What's the magic ratio? Some breathlessly report that they heard Microsoft has a one-to-one ratio, while others abjectly confess that their companies have 10 or more developers for every tester. So what's the best answer? That's easy. It depends.

The ideal ratio between developers and testers depends on the type of development and the phase of the project. In some cases, developers should outnumber testers, but in others--believe it or not--the testers should outnumber the developers. The secret is to know when and why to adjust the ratio.

Planning and Design

In the earliest stages of developing a new application--that is, one being written from scratch--developers should outnumber testers. Although test planning and design can and should commence during the planning and design phases of the development project, the fact is that there is simply more work to be done by developers. Until the design stabilizes, which in most cases happens during coding, testers can at best define and prepare the test environment and process.

The ideal ratio at this stage is probably one tester per team, or about one for every four or five developers. Most applications are built with a team this size; especially large applications might have multiple teams, but each team typically stays small. We have all learned the hard way that adding more people does not always add more productivity.

Testing Ratio Tricks and Techniques
If you follow these basic rules, you will be in a better position to effectively use temporary resources and/or employ automation in testing when it's appropriate. These tricks and techniques may also help you achieve a more rational method for managing the ratio of developers to testers in application development.

  • Plan your test
  • Document your tests
  • Dumb-down your tests
  • Standardize your tests
  • There is an exception, however. In some cases, new applications are really just modifications of existing ones. For example, a retail data analysis firm developed six applications that were simply just special versions of the same system customized for different customers. The same application in other cases might be ported to execute on multiple platforms. The effort in these situations is more like maintenance and enhancement, so the rules are different.

    Coding and Testing

    As a new application completes the coding phase and moves into test, the ratio should start to shift in favor of testers. In fact, a ratio of one or two developers per tester is probably realistic.

    This happens because the testers now have enough information to design, develop, and execute test cases. It takes time to review the application's intricacies in order to design the proper tests, then more time to develop the tests, and then even more time to execute the tests and document the results. Then it takes yet more time to work closely with developers to resolve issues. The iterative retesting of corrections and changes adds substantially to the testing workload as the application nears release.


    Page 1 of 2

     
    1 2
    Next Page





    0 Comments (click to add your comment)
    Comment and Contribute

     


    (Maximum characters: 1200). You have characters left.