Tester Developer Ratio

If you are asked about the optimal tester developer ratio during an interview, you need to treat this as an open-ended question rather than simply answering with a number.

Tester Developer RatioIn case you have previous work experience, explain what the tester developer ratio was, and whether you thought this was an efficient balance or whether it could have been improved.

Even if you don’t have previous experience, you should be able to give an answer and reason about it.

First, mention that the effectiveness of a testing team doesn’t depend only on the number of people who are doing testing. For example, the size of the project, the type of application that is being developed, and the stage at which testing will be performed will all influence the required number of testers. Additionally, good reasons can be found to justify more testers per developer (more testers means more testing), but bad reasons also exist (the efficiency of a team generally decreases with the number of members; more testers might make developers less concerned with quality).

Finally, you can mention some actual numbers. It’s been widely known for a while that Microsoft maintains a 1:1 tester to developer ratio. It seems Google actually has multiple testers for each developer. In other scenarios, a single tester per three developers seems to be the norm.

How Would You Introduce Testing at a Company?

Interviewers might sometimes ask you this software testing question simply to hear you reason about the different things that software testing actually does within a company. There is no single correct answer; in fact, you should start off by asking your interviewers some questions in turn.

First of all, would testing mainly support new development? If so, it would be good to institute unit testing of new code to incrementally build up the code base. It would also be smart to create an automated test suite covering the typical usage scenarios, which could then be used as regression tests for future releases.

Alternately, would the goal of testing be to provide insight into the correctness of existing code? If so, the first thing to do would be a comprehensive manual test of the program. Afterwards, it makes most sense to focus on testing the essential parts of the application. Imagine you have a complex application that deals with all aspects of giving out loans to customers. The most important part of this application will be the engine that does all the loan calculations, and its correctness should be tested first.

Finally, is there an established process of documentation, or a concrete development process? If not, the management should first agree on which process they want to institute, and the kind of documentation they want to have in regard to bugs and issues. Testing should come as part of this process.