What is the ratio of testers to developers reasonable?

InIn some software conferences, people often ask the question: What is the ratio of testers to developers reasonable? However, it is difficult to directly give an answer to such a question. Why is there such a problem that may come from two pressures:

• Many company leaders always want to get a reasonable proportion, and then allocate recruitment quotas according to this proportion, or try to narrow down the testing team to reduce development costs.
• In most cases, testers are more busy than developers, so they want to seek a piece of data to persuade their company to recruit more testers.

According to some experts, according to the survey results, the ratio is usually one tester to three developers. In fact, this proportion is meaningless. The ratio of testers to developers is affected by many factors, depending on different business, culture, and products. Regardless of the company's culture, product type, and responsibility definition, testers and developers must be allocated according to a certain proportion. This is an arbitrary approach and lacks scientific knowledge. There are two typical examples to illustrate this problem:

• The ratio of testers to developers in Microsoft is generally. Even in the Windows 2000 development team, there are 1800 testers and 900 developers, the ratio of testers to developers is 2:1.
• At Google, the ratio of testers to developers is very low. According to Google's test Manager, the ratio is.

Why? Here is the definition of the scope of work between testers and developers. The two companies are quite different. at Microsoft, unit testing is done by the testers (Software Development Engineer in test, SDET, it is equivalent to writing another set of SDET.CodeThe workload of product code written by developers is no less than that of developers. In addition, products developed by Microsoft are complex operating systems and server software, naturally, many testers are needed. Google's unit testing and function testing are generally completed by developers themselves, and testers mainly provide support for automated testing tools.Software developers perform sufficient unit tests, with coverage up85% Above, when the software is handed over to the tester, there are basically no functional defects. In this way, the tester mainly focuses on performance testing, load testing, and security testing.These are all completed by automated tools, and fewer testers are needed.

 

In addition, testers and developers are also subjectThe product type, corporate culture, project environment, quality requirement level, developer or tester's own quality, etc. For example:

• The developed products are operating systems, basic platforms, general client software, and simple Web The test requirements, scope, and workload of an application system are different. For example Windows The operating system must support 3 Various ApplicationsProgram, Supports a large number API And various hardware drivers And other applications compatible with DOS, 32-bit/64-bit, etc. The system is very complex and user operations are flexible, so the test workload is much larger and requires a lot of efforts from testers.
• The quality of software design and code, that is, the enterprise culture, the quality and ability of developers, directly affect the quality of the software's stage results. If the software construction quality is high, the regression test scope is limited, and the number of repeated tests is only 1 ~ 2 Times, instead 4 ~ 5 The test workload is greatly reduced, and the number of testers is also reduced.
• For example, many free network application products always place themselves in the beta version, which will lower the quality level, allow users to try it out, and help find some defects (because it is free, users can't complain.) in this way, the company's internal testing efforts will be much less.
• The quality of testers is high, and the number of testers is smaller. If the tester is positioned low and the treatment is low, it may rely on human-sea tactics, so there will be more people.
• In Agile Methods, developers play a dominant role, and testers have a lower proportion of developers. If you use test-driven development, the ratio of testers to developers will be lower. In this case, the boundaries between testers and developers become blurred.

Of course, the process, product, and culture of a specific company are finalized. You can determine an appropriate proportion based on your own experience and historical data, such as and, yes. It may be unreasonable for a software company to refer to the practices of Microsoft, Google or another company. You must look for a similar company. If the company is successful, you can directly refer to it.

 

Maybe one day in the future, testers and developers will join each other and there will be no obvious difference, but each person's tasks will be different, everyone can perform testing and development in a task. Therefore, as a tester, it is also necessary to master good technologies, including programming capabilities.

 

 

[Newly discoveredArticle4/14/2010]Google
V. Microsoft, and the dev: Test ratio debate

Google testing engineer responsibilities:

• Developing test strategies.
• Automating tests using test frameworks.
• Write moderately complex code/scripts to test systems.
• Take responsibility for monitoring product development and usage at all levels with an eye toward improving product quality.
• May create test harnesses and infrastructure.

 

Responsibilities of Microsoft SDET:

 

 

• Hire developers to write code to test code. Our goal is to have engineers writing robust, reliable and repeatable tests that find issues early and cover the surface area of the component under test thoroughly.
• sdets are in the source code for the product as much as they are working with test source and our sdets build the framework used for testing.
• build programmatic tests that are self-Verifying, that are easily extensible and that are not simply comparing "Data in" to "expected out ".
• A successful SDET derives pleasure from building lasting designs, implementing robust maintainable code, and being a partner in the design of the components while advancing the technologies and approaches for testing software