Software testing and development ratio

introduction

This article is translated from stackoverflow. If I encounter a good article in the future, I will continue to translate it.

problem

I am a development engineer, and I am arguing with our test team: Should the number of test team members exceed the number of developers in a product?

I know this is not a programming question, but I think this question is closely related to software development, so I hope this question will not be closed so that I can get a professional answer.

Reply one:

This is my personal experience. At Microsoft we have a strong test and development organization. This is a bit different from traditional QA, because we hire programmers to test and include them in the design phase. Their job is testing, especially automated product testing. According to my experience, how long it takes testers to test and automate a function is about the same as the time it takes for developers to code and fix defects in the product. This means that their ratio is 1:1, which is the same as writing unit tests. The time it takes is very similar to the time it takes to write the code.

This combination will vary according to different standards:

1. How many unit tests developers have done, and the more they do, the less work they need to test.

2. How much code does the developer have to write instead of using existing libraries. If there are many pre-written codes used, testers also need to verify whether these functions are also normal, so that the ratio of development and testing must be 1:1.

3. The dynamic nature of development work. If you write a UI, relatively small developers will make major changes to the surface of the test, you will need more testers.

4. How many important functions are there. If you are writing GMail, you can use it at will, and bugs in this area can be tolerated and fixed, so few testers are needed. On the other extreme, if you are researching medical imaging equipment, you need more testing, because it is difficult to fix defects in this area, and they will be very bad if they have bugs.


Reply 2:

For most of the company projects I work for, their ratio is 1:1, but it may be different due to the following factors:

1. Development efficiency. I once talked about a developer who has very high output and 3 QAs are busy with the functions he developed.

2. Product quality standards. An important, high-reliability system should have a better QA, and requires more QA personnel.

3. Some projects must be tested in a better number of configurations and scenarios, the developer may remain the same, but you show that more QA is needed to cover the entire test matrix.

4. How automated is the test? If the test cannot be easily automated, you need more people to test manually.

Reply Three:

My current development test ratio here is 8:1. The reason is that we attach great importance to automated testing. All work needs to be close to complete unit test coverage. We also use Fitnesse for functional testing (all user stories must have a Fitnesse test), complete testing with CI (Continuous Integration) server, developers often check, and we often release.

This is a huge application, with thousands of classes and countless scenarios. Its advantages are speed, flexibility and cost. Regardless of the extra time the developers spend on writing tests, it is less than that of the human capital management department/management of more QA personnel, or defects found in the product (even QA personnel are ordinary people).

Few of our QA staff will spend their time writing automated tests, using Selenium or participating in new features. They spent very little time repeating the same function over and over again.

Reply Four:

In my experience, there are two main types of QA personnel: 1) those who simply follow written scripts and interact with applications to find boundary problems, and 2) those who can write automated test programs themselves, looking for new and innovative ones Methods (reconnaissance, Selenium, writing API client) to break the code of the development team.

If your QA team consists of the first type of people, then a 1:1 ratio or just the right developers is a must. Otherwise, they say it is difficult to keep up with any new features introduced by the development team, and will often address any changes to the product, because this will make their testing workflow more complicated.

If your QA team is the latter (test engineers who can write code are a godsend for any productive development team). Programmers can communicate with them, and testers find useful ways to automate and improve their own processes by writing smarter, more abstract test tools. A really good test engineer may support 2~3 development tasks, especially if those developers have written useful unit tests and integration tests, testers can use them as a starting point.

At last:

To talk about my opinion, the development test ratio of domestic software testing companies is generally 3:1, 4:1 or even 5:1. Developers are generally reluctant to do detailed functional testing, because there are testers, and the unit test coverage is not high. They will write written programs directly to the test, and testers are more doing functional testing. If it is a relatively stable project, the test has time to do automated testing to facilitate future regression testing to reduce the workload.

As a tester, it is recommended that every software test engineer should improve coding ability, not only in automation, but also understand the technology used in development, run the currently tested development project locally, be familiar with the development code, and finally You can know how to fix the bug you find. Can write unit tests and become development and test engineers. I hope we can make progress together.

Guess you like

Origin blog.51cto.com/15127514/2657682