Test Resource Allocation

Test Management FAQ 3.

How much is the test development ratio suitable? ? ? This statistic is purely nonsense, and the analysis team has many indicators. This is the most unreliable one, but many people just like it, so they do not know how many bosses are misled.

How much is the test development workload suitable? 5: 5? 5.5: 4.5? This is even more nonsense. Everything in the world is ever changing. This proportion cannot be applied in general cases.

I believe that everything in the world has its own internal laws, but the law is far from a simple proportion that can be summarized. The reason why many people like it is that it is simple, you don't need to know too much details, and you don't need to do in-depth analysis. You can just say that a small team has made several products over the years. The larger the team, the more complicated the business, the more difficult it is to apply, as a qualified manager, accurate evaluation of the overall performance of the team's production capacity team is required to do homework and skills must be mastered. If not, you can honestly do technology or business, don't advertise yourself as a manager all day. Let's say it's far away, stop it.

This article mainly describes the distribution of testers in R & D tasks, which does not involve the concept of proportion. It simply describes how many testers are involved. It mainly describes what types of tasks can be assigned less testers under normal circumstances, as a reference only, it may be a little partial, so do not argue. If it is common sense, it will not be explained. As a seriesArticleWhat the boss needs has been described in the first two articles, and I will not repeat them here.

1. Task Type

• Business Model: If the R & D task is mainly for business needs, fewer testers can be allocated. Compared with optimized tasks, business tasks have clearer objectives, clearer task scope, and easier risk identification. In addition, the small-step operation requires no large investment.
• New Type: New features, non-transformation tasks, for the same reason.
• Emergency: It may be online fault repair or temporary changes made to meet a large activity. The common characteristics of such tasks are short cycle, high priority, and high urgency, the more such a task, the lower the communication cost. If there is no time circle for a large group of people to discuss the solution repeatedly, it is the primary goal to quickly launch and solve the problem.
• Collaborative: Cross-department collaboration tasks, especially across technical departments, the more cross-department collaboration, the less workload the team may have. The majority of tasks are in joint debugging, and there is no need to find multiple contact persons.
• Technology: non-business and non-optimization, purely technical research, practical value to be determined, may be used for half a day without a line of business, this is the first thing developers can do.
• Cycle Type: long cycle, many phases in phase I and phase II, occupying fixed resources for a long time, with as few personnel as possible.
• Test type: the agile or similar products on the dust are full of people playing, but most of them are not persistent. It is unknown whether the agility on the Chinese mainland will be as smelly as the streets of ISO and cmme, but it is clear that in the current form, there is no need to invest too much resources to do this. If the task process adopts the new mode, the fewer resources, the better.
• Incomplete: The task information is incomplete, for example, there is no document, or the owner is on the road before taking over the task temporarily. For such a task, the first task is to clear the task clearly, instead of doing it manually.
• Self-testing: This method is the first choice to ensure the quality, and should be widely promoted.

2. Team Composition

• Male: male ratio of large teams is out of stock. If the testing team has a majority of female employees, you can allocate them less. You know the reason.
• Infrastructure: The test infrastructure is complete and the maturity of large teams is high. In many cases, no tests are required for R & D tasks.
• Compound: A majority of professionals are specialized. Testing jobs are inherently compound, especially skill combination. I can do both development and test, functional test, and performance test. I can do more in-depth work in a certain field and other fields. This is my favorite team structure, you do not need to set up a special post for a job. Instead, you do business testing and other jobs at the same time. Is it because it is not deep enough? It is possible, but it is better than leaving the business.
• Flat: the organizational structure is flat, vertical, with low communication costs, consistent task objectives, especially KPIs.

3. Product Features

• Latency: non-real-time interaction products, and there is enough time to fix problems.
• CommunityType.
• Search type: It is difficult to accurately verify the results, especiallyAlgorithmWe are still being raped using Baidu.
• Media type: videos, text, and images. Users are more interested in content and can open it.
• There are many other examples. Note that these products are not important, but do not need to invest too much test resources. Do not confuse them.

 

The test resources mentioned above mainly refer to ordinary testers and non-test "experts". I have never been clear about what the test experts did. I recently sent a curious number to Mars, should experts participate? Haha.