At the end of 2010, the vigorous promotion interview of the Technical R&D Department slowly came to an end. Some were happy and some were lost. A few months later, the pain of failed promotion gradually subsided, and the pleasure of successful promotion gradually faded. The next very practical question posed before us, especially for those engineers who were successfully promoted, that is, after the promotion, are you still doing the same job, no different from before.
Despite some controversies, the new job model played a more critical role in this promotion process. It clearly defines the capabilities of test engineers at all levels and what tasks of different difficulty can be completed. In addition, we can see a "Test Engineer Career Development Roadmap" almost every other time. Each one is different, but the main idea is basically the same. It means that testing is a panacea and can go in multiple directions. development of.
Regarding the future development of test engineers, it seems that we already have enough information. It stands to reason that we should clear the fog and move forward with confidence. But we felt something was wrong, and did not experience the relaxed and invigorating feeling. On the contrary, we still felt that we were in the depths of the maze. These are not normal. I think the technical committee should do a return visit to test engineers who have been successfully promoted and ask them how they feel, whether they feel that their personal value has doubled, their confidence is doubled, and their goals are clear.
The following is just my speculation. I think the results of the return visit may not be so good, and the opposite answer is likely to be obtained. Although the feeling of success in promotion is very high, the salary is also high, and the enviable eyes of colleagues, but these joys are extremely short-lived. When everyone calms down and returns to work, the successfully promoted engineers will find an embarrassing reality: they are still doing the same work as before, and they are not authorized by the organization, completely different task challenges, and no new tasks. The movement of delegation, everything is so peaceful. Looking around, they found a more terrible problem. Test engineers at different levels were doing similar testing. P6 is carrying a project, P5 is also carrying a project, and even P4 is carrying a small project.
In fact, I really want to say the difference, it’s not without it. The projects they bring are still different, some are big and some are small, but looking at the specific work in the project, the difference is not very big. You have to write a plan and write one. Heap use cases, execute over and over again, and record a bunch of bugs. This kind of division of labor seems reasonable, the responsibilities are clear, and each has its own share. In fact, it is not. This kind of distribution method is the simplest, but it is not scientific. Because everyone knows that in the testing work of a project, there are always some tasks that are very simple and have a large amount, and some are very complicated but the amount is not large. Let’s take the 28th principle. P6 engineers will find it boring to do simple tasks, while P4 engineers will find it difficult and tiring to do complex tasks.
I think this is the main reason why test engineers feel confused about their career development. P4, P5, P6...Each level should be a milestone. When you reach this milestone, you will have a big breakthrough in all aspects. It is definitely not a cycle of repetition. You are constantly working on projects, and then endure a lot. In years, I became the leader of a group, and then dealt with a bunch of chores every day, and finally lost myself. This is definitely not the way we should go.
I learned in school that one of the keys to human evolution is the great division of labor in society. Each organization is responsible for different types of work, strives for perfection, and evolves continuously. How the test engineer's work is divided has a certain connection with the job model. The job model needs to complete the definition of 3 levels: 1. The definition of the ability of test engineers at each level. This has been completed, we will not say more here; 2. What types of work need to be completed by various levels of test engineers. In fact, the current model is not clear, so everyone will feel a little confused in the work, but according to the existing job model, it can be inferred, and I will summarize it later; 3. A healthy testing team, at all levels Proportion of test engineers. This is completely undefined, so we will focus on the analysis immediately.
Let me talk about the second point first. Really reasonable division of labor for test engineers, I think it should not be P5 responsible for A project, P6 responsible for B project, nor in a project, you are responsible for module A, I am responsible for module B, of course not, the person in charge of the test divides the modules evenly Give it to a few people, and then take charge of the so-called "communication and coordination" work. Test engineers at different levels, their division of labor should be divided according to the type of work. We look at the following table:
| Test engineer level | Responsible for work content |
| P4 | 1. Master the test strategy according to the requirements document and the test document 2. Perform most of the simpler TC 3. Record the bug 4. Complete the simple daily test of the project |
| P5＝PTM | 1. Develop the project test plan 2. Complete the design of all TCs, including design and test preparation work plans 3. Execute the more complex and core TCs in the project 4. Record bugs, control bug health 5. Write knowledge precipitation and training for the project Documents to facilitate P4 engineers to get started quickly 6. Control the weak points of project quality and reduce the number of online bugs |
| P6 | 1. Design a more scientific test strategy based on the project's business characteristics and architecture characteristics. 2. Help PTM improve test efficiency (multiple aspects) 3. Solve particularly difficult technical problems in the project |
| P7 | 1. The work content is almost the same as that of P6 2. The way to solve the problem must be more scientific and applicable to more projects 3. The joint development team and other test teams are required to deal with the problem together |
Here we have a clear concept, which is the project. In the new twork, the concept of the project has become larger. Shopping carts and favorites are all projects, while shopping cart 2.0 and favorites 3.0 are some versions of evolution. Therefore, PTM (Project Test Manager) has a new meaning. In fact, it is the "owner of sub-products" mentioned before, but it is too awkward to call it PTM in the future. Note that within the scope of P4 engineer's responsibility, there is no PTM's responsibility.
Okay, let's continue to talk about the division of labor at different levels. The above classification is based on the work content. Below, we will classify the bugs submitted by them. Please see the table:
| Test engineer level | Bugs found |
| Development Engineer | 80% of elementary bugs Elementary bugs can be discovered as long as they develop a simple self-test. If they are discovered by testing, recording, repairing, verifying, and communicating, the project's human resources are greatly wasted |
| P4 | 20% primary bugs 80% intermediate bugs The test cases covered by P4 engineers are logically clear and easy to judge. Therefore, most of the bugs found are intermediate bugs. |
| P5＝PTM | 20% Intermediate bugs Advanced bugs PTM needs to cover the most complex logic in the project, and it takes a lot of time to conduct exploratory testing, so most of the bugs found are advanced bugs |
| P6 | You figure it out |
| P7 | You figure it out |
From the quality of the submitted bugs, it is easy to see the skill and ability of an engineer. If the bugs found in P6 are similar to those found in P4, how embarrassed to continue mixing. Let's compare from another dimension below, that is: whether to focus on a project, please see the table:
| Test engineer level | Concentration on Project |
| P4 | Can reincarnate in several projects |
| P5＝PTM | Must stick to their own project |
| P6 | You can choose to stick to a Project, or you can not limit the Project |
| P7 | Project is not limited at all |
Speaking of here, the second point "Division of Test Engineers" is over. The evaluation of P4 engineer is the simplest and best quantified. He only needs to complete the test of certain function points according to the document. In the implementation process, P4 does not need to be a big headache, if there is pressure, it is also the pressure of workload. If the P4 engineer feels that it is difficult to perform the test, it means that the design and preparation of the PTM is not in place. As for P5P6 engineers, although they are free from a lot of mechanical work and feel very happy, they will soon feel a little uneasy, because they have more resources, so they will be under greater pressure. This pressure is mainly ideological. Pressure, but these are normal and reasonable.
I think there will be many people who will have questions about this division of labor, so here I will first predict some problems and explain to you.
Q：如果一个project的用例都由PTM写，ta能忙得过来么？
A：这就要看用例的规模了，如果按照现在我们的写法，估计够呛，用例写成“说明书”，PTM肯定累半死。用例应该是一个结构化的文档，与知识沉淀珠联璧合，总之这就要看PTM的能力了，怎么设计才能既简洁，又可读。另外如果项目太大（不禁想起WCS），那估计要多位PTM合作。
Q：PTM把用例写好，那执行第一轮测试的时候，他不是没事干了。
A：这是因为以前的规定是，用例全部写完，评审完，才能测试，这样其实是不敏捷的，用例的设计和执行本身就可以并行来做，评审只要把关键的测试逻辑评审通过就可以了。开发工程师也是希望我们尽快投入测试，尽快提交bug。另外，测试开始后，PTM还需要不断完善测试方案，特别是测试数据准备方法，PTM要为P4的工作铺平道路，绝对不是甩手掌柜。
Q：这样定义，对现有的P4工程师，是不是会感觉不好，好像在说他们只能做简单的执行似的？
A：说到这个问题，还请大家保持冷静。对岗位的定义，和对人的要求，是完全不同的，要区别对待。我们设定P4这个岗位，说明团队需要这样的岗位产出，绝对不是说现在这个岗位的工程师只能做这些。对这个岗位感兴趣，适合的人，自然会接受岗位offer。当ta在这个岗位上有了较好的绩效，经常会涉及更高层级的工作时，那么就可以自然晋升了。
到这里第二点我们分析完了，下面讲第三点：健康的测试团队中，各个层级的测试工程师比例应该是怎么样的。
现在我们的招聘策略是尽量挑选精英工程师，简单来说是至少P6级别，这是非常正确的方针。如果一个团队全是P4P5，在测试技术发展上，必然会遇到难以逾越的鸿沟。那么是不是P6越多越好呢，也未必，试想一个产品线测试团队都是P6，是什么情景。在篮球论坛有人提出这么一个观点，如果由5个科比组成的篮球队，可能战胜不了大联盟的任何一支球队。虽然没办法证明，我认为还是有些道理的。足球队最出风头的是前锋，要是11个都是前锋，也没法踢了。推理到测试团队也是一样，大家自己体会。
说到这里想起三国杀游戏，里面分了主公、忠臣、反贼、内奸几个角色，在多人游戏中，这些角色的数量是严格定义的，只有这样设定，各方面势力才能均衡，才好玩，忠臣太多反贼太少，一下就结束了，一点不好玩。并且，当游戏人数发生改变的时候，这些角色的数量也会跟着变，还要遵守一定的规则，保持生态平衡。
测试团队也是一个生态圈，各方面势力均衡，工作才好做下去。其实一直以来，“开发测试比”就是开发团队和测试团队保持生态平衡的一个重要指标，这个指标也是讨论最多，大家关注最多的。我认为每个测试团队，也需要确定自己的人员比例，可以根据所对应的Project的特点进行调整。下面假定有一个10人的测试团队，我们按照足球队的阵形，排出了测试人员比例模型，大家参考一下：
| 比例模型 | 不同层级的人数 |
| 5-3-2 | 5*P4 3*P5 2*P6 |
| 4-4-2 | 4*P4 4*P5 2*P6 |
| 4-2-3-1 | 4*P4 3*P5 2*P6 1*P7 |
排下来感觉也挺靠谱的，才发现软件测试和足球还有这么点联系。当然，这只是常规团队的排兵布阵，有一些特殊的project和产品线，是不太合适的，需要重新定义。不过要遵守这个原则，并不是层级越高的人越多越好，而是要各司其职，方能百战不殆。
希望这篇文章，能够帮助大家理清思路，从职业发展的迷雾中走出来，也希望能以这篇文章作为引子，与各位测试经理们继续讨论测试团队的建设模式。最后总结一句话，我希望测试团队向着生态平衡，良性循环的方向前进。