I was talking to a friend who had been a test manager for a while and I had a conversation about the construction of their department. As soon as he started, the manager was impatiently pouring out bitterness: "The work of the department is really difficult to carry out, and the employees have no energy..." "The employee of such and such is simply hopeless, always messing things up... ...", "So-and-so employee is really worrying. She has been in the company for three years, and she is familiar with the business. If you want to promote her, she is not motivated. If she is asked to do something she has never done before, she will panic. ", "Old employees are dead, new employees are not motivated...", "So-and-so recently resigned, I don't understand what happened, I always thought he was working happily...". After complaining for more than half an hour, he was still immersed in his own pain.
To tell the truth, I really sympathize with him, and sympathize with his current situation. As a new test manager, I will naturally have a lot of energy. I wish I could make the department look new overnight, and I wish all the employees could make rapid progress overnight... Unfortunately, Rome was not built in a day, the problem of department management It will never be solved so easily.
Management is an art, and the management of test teams is an art that requires care. Test engineers are generally sensitive and self-respecting, they have the ability to find defects, and naturally they can easily find your negligence in management work; they can evaluate the application system, and it is not difficult for them to evaluate your management work.
So, is it really that hard to build an efficient testing team? In fact, the core of management work is "people". As the person in charge of the testing department, as long as you grasp this point, you can mobilize the entire team smoothly. I have experienced different test teams in different companies, and in my opinion, test engineers are actually very easy people to get along with. Test engineers are not purely technical personnel. They are generally keen, patient, responsible, able to work under pressure, and have good communication skills. However, the collective term "test engineer" masks too many differences between them.
Going back to our original example in the article, when I asked the new test manager "What do you think your ideal test engineer would be like?" his answer was "I hope they all get better. Attentive, aggressive, with a high technical level, and able to bear the pressure of work." I think his answer may be to use his own requirements to require all the test engineers in the department. A team full of generals will never be more effective than a team with a clear division of labor and efficient cooperation.
So, how to build an efficient testing team? This question must be "the benevolent see benevolence, and the wise see wisdom". But here, I will not take the liberty to say some of my own views.
1. The "people" in the test team
First, an effective test team requires "people" in different roles. In my experience, generally speaking, test teams often have these types of employees:
1.1 Different types of employees
◆ Tiger
The tigers in the testing department are those who have energy and drive. They are smart, competent, perceptive, and not afraid of pressure. Every test manager I've met expects to find such talents, but unfortunately, such talents are rare, and most of these talents are cultivated by the test organization themselves. The power of the tiger will surely be brought into play in the new organization.
However, even with Tiger's presence in the department, a space must be created for Tiger to suit him. Many test managers will be troubled by the departure of the capable person in the department, but at the same time, have you ever thought about why he left? Purely for compensation? ——In fact, Tiger is very self-motivated. Once he finds that he can only do fixed things in a fixed environment, he will choose to leave. If you want to retain this type of talent, you must create a challenging environment for him at all times - let him open up a world and let other characters "guard the city", which is most likely the most suitable match.
◆ cattle
Niu is the most diligent and conscientious, and steadfast, hard-working and dedicated are the best portrayal of Niu. Such an employee can complete the definite task you give him, and it is most reassuring to hand the definite task to him. However, there is a fly in the ointment. Such employees often lack initiative and creativity. They are obviously familiar with the business and have rich experience, but once they are asked to jump out of the work atmosphere and role they are used to and complete some work creatively, they are helpless. This type of employee is both love and hate. What he loves is his diligent attitude, and what he hates is his unwillingness to make progress.
◆ Monkey
猴子是聪明的代名词，这种类型的员工聪明、大胆、活跃。在部门里，这类员工总是在鼓捣各种新工具、新技术、新名词。他们是工具引入的主要建议者和新技术采用的主要倡导者。这类员工对新事物有执着的热情，愿意去了解每一种他们所能接触到的新东西。对于解谜，这类员工有着天生的爱好，他们最大的兴趣就是从谜团一样的系统中找到能证明自己聪明的证据。然而，这类员工的缺点几乎和优点一样明显——缺乏持之以恒的耐心，一旦他们不得不长期进行一些重复性强的工作（例如，手工的回归测试），他们就会表现出不耐烦和由此因为疏忽产生错误。
◆ 长颈鹿
长颈鹿在这里并不是“迟钝”的同义词。长颈鹿通常是一个部门中最有前瞻能力的人。他们具有对软件测试深入的理解和认识，能够对测试部门的发展提出非常好的建议（而不仅仅是意见），唯一的问题是，对细节上他们总是缺乏关注，能够给出漂亮的流程图或是建议书，但如果由他来执行，则一定是一场灾难。
◆ 狐狸
测试部门中也会存在一些狡猾的人，我们可以把他们称为“狐狸”。狐狸这种类型的员工总是整个部门看上去最为忙碌的一个——他们为自己揽下一个又一个的工作，却用一个工作去掩饰在另一个工作上投入的无效劳动。每当你问起这类员工“A事情进行得如何？”，他们总能用“我正在忙着B事情（或是C事情）”这样的回答搪塞你。最终的结果是，经过几个月时间的忙碌，他们可能拿不出任何有效的工作成果。
◆ 鼹鼠
当然，这种类型的员工可能是我们都不希望见到的。他们永远都想没有睡醒一样，更多时候看到的是他们茫然的眼神。交给他的任何工作都可能没有理由地失败，而且，更可怕的是，他们很少能够从失败中学习到教训。
对这些不同类型员工来说，重要的不是改变他们的性格类型，而是要了解他们的性格类型，再根据他们的性格类型为他们分配不同的工作，让他们能够在一个能顺利施展自我和自我前进的环境中工作。
1.2 不同类型员工的对策
◆ 老虎——给他挑战，把部门最重要的、最困难的工作交给他，你只需要充分发挥他的主动性，定期让他汇报工作的进展就可以。让老虎觉得最安全的方法是让他能够充分证明自己的能力。当然，要注意的是，如果一个团队中有几只老虎，合理分配他们的工作（负责不同的方面）可能是一个好主意。
◆ 牛——让他做自己最擅长的事情。牛会很高兴自己在某个方面可以一直发展，直到成为这方面业务或是实施方面的专家。让他接手老虎开拓的工作范围，做一个好的执行者对组织是最有利的。当然，牛有时候也会提出想要一些“挑战”，这时候最好先为他准备好退路。
◆ 猴子——部门新技术研究的不二人选。无路是在测试自动化、测试工具引入、新的测试方法和测试技术引入方面，都可以仰仗猴子。不过，最大的风险来自于他们的不确定性和其天生地乐观心态，因此，如果让他们主导某个项目（例如，测试工具引入项目），要他们更加频繁地汇报工作进展和为他们规划细节。
◆ 长颈鹿——参谋。在规划部门发展的时候，可以多听听他们的意见，但最好不要让他们去完全承担部门测试过程改进的任务，在执行方面，他们可能并不会照顾到太多的细节。
◆ 狐狸——拿掉他用来隐藏自己的“多任务”。明确交给他一个任务，例如“完成某项目的测试”，时刻关注他们在任务进行过程中的报告，一旦发现他们主动承担不属于自己的任务，就要立刻分析，看他们是否又犯了老毛病。
◆ 鼹鼠——怎么说呢？给他一个机会吧。可能是他并不真正热爱这个工作，也或者是他有些心理上的疙瘩没有解开，不管怎么说，找出他这样糟糕表现的原因，如果真的没有办法改变他的工作，很可能只能选择让他离开现在的团队了。
1.3 团队成员的默契
没有一个测试团队可以依靠一个人取得成功，成功必然是大家共同努力的结果。在短时间内建立一支成功的团队非常困难，因为你必须按照部门的规划去了解每个团队成员、对他们进行培训、在必要的时候重新培训等等。
然而，由于种种原因，一个团队不可能总保持在建立之初的状态，有老成员的离开、也有新成员的加入。团队规模可能在变化，团队承担的职责也可能在发生变化。那么，在这些变化的同时，我们怎样让一个团队始终保持人员上相对的成功呢？答案就是“默契”。
一个团队必须依靠制度才能建立这种默契。比如，建立员工之间的定期的沟通会、强制的培训和接受培训的机制、人员的定期轮换、岗位角色的互相备份等等。这方面没有定式可以遵循，每个人都可以按照自己团队的特点来建立体系，但必须要有这样的体系，才能将团队的成果和发展以某种形式固定下来。
2、测试团队的“规则”和“氛围”
除了人员之外，最重要的就是团队的“规则”，也就是团队赖以生存的规范土壤了。一个团队的战斗力更多地体现在“令行禁止”上，因此，对成功的测试团队而言，必须要有明确的角色分工和明确的团队规则。
另外，“氛围”也是测试团队的一个重要因素。所谓测试团队的氛围，就是一种置身其中的感受，一个高效的测试团队，必然有良好的氛围。
2.1 学习和交流的氛围
一个高效的团队必然是一个持续学习的团队。测试团队中每个测试工程师其实都会对自己的未来有自己的规划，也会希望自己能够在团队中学习到更多的知识和技能。高效团队依赖团队中的每一个人来达到“高效”的目的，也要求每个团队成员都具有良好的技能，因此，学习的氛围是高效的测试团队必不可少的。
但是，要建设学习型组织，并不是一件轻易的事情。组织不可能把学习作为一个任务来下达，因此学习必须要与工作进行结合；另外，如何调动组织中“能者”带动“暂时不能者”进行学习，也是很有技巧的事情。
◆ 部门讲师制度
部门讲师制度是一种比较有效的制度。在我的实践中，部门讲师是一种权利，也是一种责任：“部门讲师”认证是获得“高级测试工程师”级别的必要条件；同时，要保留住“部门讲师”的认证，必须保证每月至少4个小时的内部课程，而且，内部课程获得的评价要大于平均8分。
除此之外，每年评选一次年度的“最佳内部讲师”，每年对内部讲师进行一次重新认证，内部讲师可以优先获得一些外部交流的机会等等，这些都进一步将内部讲师变成了一种荣誉，从而使更多的成员愿意为整个团队奉献自己的知识和经验。
◆ 专题研究
测试工程师都知道，测试工作最容易陷入的一种不好的工作状态就是“事件驱动”——测试工程师整天忙于处理临时的突发事件，而忽略了自身技能的提升和部门长远的目标。这种状态一旦持续下去，形成惯性，测试团队的成员很容易产生厌倦和倦怠的情绪，失去目标和方向，而这种没有目标和方向的氛围又很容易影响到整个团队的士气，乃至于导致人员的流失。
我在工作中会采用一种“专题研究”的指导方式。实际上，在测试团队中，可以进行的研究和提高工作是非常多的，我们正好可以利用测试工作的“间歇性”特点，在不是很紧张的时候进行一些针对性的研究工作。之所以采用专题的方式进行研究，是因为要确定研究的目标，否则，研究工作没有目标的指引，很容易就会被忽略。而且，这种专题研究不要设置过大的专题，最好是能够在短时间内可以看到一定成果的专题。
◆ 重总结的气氛
及时对自己的工作进行总结是一个非常良好的提升个人和组织能力的机会，一定要在组织内建立这种“重视总结”的氛围。总结并不仅仅是描述做了哪些事，更重要的是，要总结得失——“我们在这次的工作/项目中得到了什么？哪些地方有失误？能不能做得更好？”总结的目的不是为了惩罚某个人，而是为了让团队成员都能看到工作中的成绩和不足，总结出好的地方形成流程或是规范，从而提升个人能力和组织的能力。
2.2 用制度和流程形成团队的战斗力
◆ 制度流程先行
“没有规矩，不成方圆”。一个高效的测试团队同时也一定是一支纪律严明的队伍。我们团队的每一个新入职者，不是首先去学习业务知识和测试技能，而是首先用一个月的时间学习我们的测试流程和工作规范，因为这些才是团队最直接的经验总结和提炼。
◆ 知识不止是个人的，更是团队的
人员的交替对测试团队来说很很正常的事情，但无论人员如何变化，测试团队必须要能够保证团队不会由于某个人的离去而不能正常运转。我们在前面提到了“人员备份”的概念，除了“人员备份”之外，还必须通过一定的制度来保证人员的经验和知识能及时转化成团队的知识和经验。
- “项目总结”制度可以保证在每个测试项目结束时，项目成员的经验能够体现为组织的经验；
- “部门讲师制度”可以让个体（讲师）的技能与知识通过文字、语言的方式成为团队的知识和技能；
最后建立高效的测试团队并不是一个轻松的任务，但也绝对不是“Mission Impossible”，只要团队的管理者能够管好“人”、“制度”、营造良好的“氛围”，相信每个管理者都能营造具有特色的成功高效的团队。