如何对测试团队进行管理

71 阅读 0 评论 47 点赞

我是靠谱客的博主细心糖豆，最近开发中收集的这篇文章主要介绍如何对测试团队进行管理，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

最近经常被问到如何对测试团队进行管理的问题。

我自己总结了一下自己的一些看法，希望书面记录下来，加深印象，也借机像各位同行大牛请教一下

我从5个方面进行总结：

第一、团队组建

分别从2个团队的情况来说：

第1个是团队内部晋级为测试经理，这个时候因为对团队业务和人员比较熟悉，一般整个团队的工作内容和方式都变化不大，初期萧规曹随即可，主要是心态适当转变即可。待团队工作顺畅后，再不断考虑团队工作的优化，包括产品优化、甚至人员的优化。

第2个是空降到一个新团队做测试经理，这个时候一般都是原有测试经理离职或领导不满意，才会出现的情况。对于这样的情况，一般到一个新环境，首先要尽快熟悉工作环境，包括工作流程、团队成员和协作团队成员，尽快熟悉后介入到日常的工作中。这个时候的沟通特别关键，毕竟做一名空降兵，如何让团队认可是开展后续工作的基础，同时也要和领导多沟通，找到领导关心的痛点和团队日常工作的痛点和难点，按重要程度和操作难度上综合考虑，制定合适的计划并开展工作，逐步施加自己对团队的影响力。空降兵初期领导的支持很关键，所以多于领导沟通，并提供自己的问题解决思路，并尽可能和领导达成各项工作的一致性，对后续的工作特别关键。

不论哪种情况的，在能力范围内尽全力拿到团队成员的考评权限，这对后续团队管理的工作尤为重要。一个对团队成员最终结果无法施加太多影响力的领导，多数的管理也是无效的，除非这个领导的领导力和个人魅力特别强，能强到所有团队成员愿意服务安排，甚至甘愿放弃少许利益的接受这个管理者的领导。

第二、团队日常管理

团队的日常管理，我觉得主要从这几个方面来说。1、任务清楚 2、分工明确 3、及时跟进 4、赏罚分明 5、适当的独裁

1、目标清楚—— 明确团队目标，明确每项工作每个人负责的工作，预期的产出，工作过程的里程碑和deadline，并和团队童鞋达成一致。当然这里也包括对某个任务安排后的初期方案制定和选择，尤其是偏技术的任务，需要在实际开展前就讨论制定好整体方案，并确定按这个方案执行的里程碑点，避免因个人自行选择方案造成的方向性错误。

2、分工明确—— 这个和第1是相辅相成的，团队目标明确了，每个人的具体分工清楚了，团队成员就清楚了具体的工作内容并可以开展具体日常的工作了。现在很多公司都讲究扁平化管理，更多是希望所有人能做所有事，即使这样，每一次迭代，或者每一项任务的明确分工也需要明确，才能更好的开展工作，减少成员的惰性。这个说起来很空洞，我还是举个例子，可能就更形象一些。我在工作中有这么一个场景，需要记录下每个团队成员处理的生产问题，我就在组内的群里下达了这个指令，要求每个人把自己协助处理的生产问题都记录到生产问题记录表中，所有的，包括现场提出的但最后定位出来不是问题的都要记录。我当时觉得这个要求很清楚。但是实际执行过程中发现存在问题：问题一、经常出现某些童鞋遗漏记录。问题二、经常出现有童鞋反馈不及时，需要我发现时再去催促。基于这个情况我请教了一下一位直属领导，他了解到我的情况之后就指出了我的问题——分工不明确。这种要求每个人都做，经常就会出现相互依赖，结果没人主动负责这件事。应该指定具体哪个人，或者每个人轮流一周处理这个事，而且要明确每周的时间节点，清楚的要求到每个周五18:00下班前提交完成。这样，明确的分工和完成时间节点才是清楚而明确的分工。

3、及时跟进—— 就是需要在安排任务后根据任务的紧急重要程度和自己预估的可能存在风险点的时间去关注任务的进展和执行中的困难，通过日常的进度跟进，确保整个任务的进度和风险可控。同时，对任务的及时跟进也会及时发现下属的困难并协助解决。很多时候计划往往赶不上变化，及时跟进并更新调整计划是经常需要做的事，也是管理过程中的重要工作。

4、赏罚分明—— 管理本就是一种约束，让做的好的受到奖赏，做的不好的受到惩罚，只有这样大家才有把工作做好的动力。说到赏罚，很多人都要吐槽了，确实目前IT公司有大部分都没有明确的赏罚规范，也很难采集到令很多人认同的考评数据，所以对考评很反感。但是考评对一个领导确实非常重要的管理手段，越是头部的企业考评体系越好，绩效工资占比也成一定的比例，这就更证明考评的重要。对于非头部公司，由于各种客观原因，无法让考评更客观、更全面，但也是管理者的重要手段。至于如何赏罚，每个人都有自己的想法，充分运用就好。我觉得没有人能获得所有人的喜欢，从我自己的体会看，领导都是要考虑自己利益的，自然也愿意把奖励奖给那些能更好的完成自己部署的任务与长期规划的员工，只有这样。当然，员工也是这样，没有哪个人愿意跟着不认可自己的领导。对于一些不能很好贯彻自己思路的下属、还有态度或能力不足，不足以胜任本职工作的员工，适当的惩罚（包括指出存在的问题、提高工作要求、提出改进建议、甚至扣绩效督促其进步），也是对团队负责。对于那些实在和自己不合拍的下属（不能胜任工作或者不能贯彻自己的任务要求），想法劝退也是一个迫不得以的选择。

我做测试经理（测试主管）5年多来看，赏罚多数还是以罚为多。虽然我也明白，IT行业还是应该主要以奖励来激励大家的工作，但是很多时候，团队的经费不够，很多时候1年只有1、2次项目奖，1年最多2次加薪机会，所以可以给的奖励多数都不多，而且不及时，所以日常时还是以罚居多，当然这里面的罚可能也多数是指出问题，提出要求。当然，在有条件进行奖的时候，一定不能搞平均主义，因为这样对今后的工作一定会带来管理上的不便。同时，这里面的赏罚自己一定要争取到一定的比率，比如下属员工的考评，自己的评分一定要占最终结果一定的比例；年终的加薪和日常的项目奖金，自己要有合理的建议权，如果一个经理（主管）对下属的奖惩没有影响力，那这个领导也离残废不远了。

第三、团队成长—— 进步是一个个人和团队所必经的道路，也是一个团队管理者的重要工作内容。如何让团队不断成长，不断提高战斗力和战斗范围，这是一个测试经理必须考虑的事情。从我自己总结来看，主要从3方面开展：

1、团队的业务能力。测试团队的业务能力是日常测试工作的基础，也是团队能力提升的首位。这个说起来可能没有太多，但是还是需要测试经理对整个团队的业务学习做一些指示。在团队稳定初期，重点学习业务基础知识，不断完善测试用例，通过这些业务细节，提升团队的业务能力。在满足这样条件后，深入了解业务的整体架构，加强对中间件的测试；如果在这块业务也完成的很好，那还可以继续去学习同类产品的业务，通过业务对比找到自己产品的优势和劣势，一般如果能做到这个水平，团队的业务水平就已经达到一个较高的高度了。我目前所管理的团队，一直停留在业务学习和中间件学习和测试阶段，也有简单的学习和对比过一两个同行的产品（没有系统的整理出优势和劣势）

2、团队的技术能力。测试技术的提升那就是全方位，毕竟测试需要掌握的技术太多，而且是没有上限的。这部分内容，我个人觉得主要要注意2点。首先，技术的提升要能运用到团队的日常工作中。现在业界都在推自动化测试、性能测试，所以很多测试人员都有性能和自动化的学习需求，基于这样的现状，这两块技术是团队技术提升很关键的一块。但是，如何把这两部分技术充分应用到日常的工作中是关键。我觉得无法应用实战的技术，那就是空中楼阁，可能有利于团队成员跳槽，但是无法给团队带来正向价值。另外，也只有应用到实战，团队的技术提升才能落地并不断前行。其次，团队的技术提升应尽可能针对团队成员的意愿和现有技术基础。毕竟测试技术提升的地方很多，比如用例设计、自动化、性能测试、中间件测试、安全测试等等，充分了解团队成员的主观意愿，结合实际的工作需要，选择1——2项技术做为主攻方向，并分组专研和提升，比较容易开展和实现。再次，要注意阶段性成果的目标确定和分享，没有输出的技术提升是没有意义，也是没有动力的。在选定某些技术方向后，经调研并确定技术方向后制定阶段性目标和结果汇报是非常重要，既是对任务责任人的督促，也可以方向管理者本身调整方向和预期，如果确实对团队有贡献，还能跟上级领导争取相关资源（人力或者奖励），以方便后续继续提升这个领域的技术水平。

3、团队的凝聚力和战斗力。这个其实说起来都是废话，但是团队的凝聚力又是真实存在，我见过团队牛人不少，但是产出成果不好的；也见过牛人云集，团队战斗力爆棚的。当然，也有一堆矬子，但是团队产出不错的。如何提高团队的凝聚力，我觉得可以从这些方面着手。a、打胜仗。测试的胜仗就是交付一个高质量的版本，让领导、协同部门（研发、产品、运营）都认可测试的工作和重要性。 b、不断进度。包括技术和业务上，尤其是技术上的。每个职场人都有提升和进步的需求，让团队的成员看到成长的方向，这自然就会让大家更有干劲，反之，如果可见的未来上限就不高，那大家的动力自然就不足，团队的凝聚力也就不高了。 c、明确领导地位。一个没有明确领导的团队，必然是一个心思各异、人心不稳的团队，这也是一个好的团队，在建立之初会有团队战斗力下降过程的原因。所以，做为测试经理，明确自己的团队领导地位，使团队成员能够支持自己的领导，并愿意为其而努力工作，这是一个团队凝聚力必不可少的。有了凝聚力，即使偶尔走错方向，只要注意复盘和改进，团队的战斗力一般都不会弱.

4、团队的知识积累。建立团队的知识积累体系，加强团队的知识书面话是测试管理的重要组成部分。这能有效的减少团队成员变更带来的影响。文档化、书面化这些都是知识积累的重要手段。如果能更好的应用gitlab、conference这些通用的知识积累系统就更好。

5、团队的作战范围。测试团队的最基础工作就是测试系统版本，发现问题；再这个基础上，通过结果反向推动测试提前，最终从需求阶段开始测试是很多测试团队成员所预期的。而测试团队如果不断在整个过程中更多的发挥自己的价值，是测试团队作战范围成长的方向。在测试团队完成最基础本职工作，如何反向推动、开发提升版本质量，如何推动运营深入学习系统，减少系统误操作带来的非问题，如何快速处理生产问题等等都是可以努力的方向。

第四、团队成员交流和分享——一个团队，团队间成员的交流非常关键，为团队成员提供良好的交流和分享氛围也是一个团队领导的重要工作内容。目前我所做到有定期会议（视项目情况定，最短每天站会，最长每周例会），通过简短的会议，让团队成员能了解到其他团队成员的工作内容、遇到问题和解决经验；定期的组内分享会（每个月1到2次），主要是进行业务和技术的组内分享，大家共同学习进度。定期的TB，这个说实话，我组织的不多，一般都是加班后聚餐，而且，1年也就3——4次，主要是团队经费有限，自掏腰包1、2次，团队经费2-3次，也就差不多了。当然，如果团队经费充足，而且团队成员的共同爱好多，可以更频繁的组织团队成员进行TB。

第五、对领导的管理 —— 这部分我其实本身并没有总结到，是参考了同行群友给的意见，才整理出来的。这部分我自己尝试做的是这么几个方面：1、尝试给下属争取利益。这个其实很现实，又很困难。现实是很少有下属会不愿意跟着一个能给自己争取到利益的领导，所以给下属争取利益是最能凝聚人心的方式，不仅仅能获得受益人的支持，也会让其他人看到希望。困难是整个团队的利益有限（加薪、奖金、升值），所以能给到测试团队的最终packpag都不高。我之前的团队，为1个团队成员成功争取过2次，当然这个前提是这个下属本身表现确实出色，而且他的所得确实少（14年本科毕业，17年6000*15的薪资）。2、管理领导的预期。很多情况下，测试团队受于各种原因的制约，没法提供一个完美的版本。那在有限的资源内，测试团队能完成怎样的结果，可以充分和领导沟通，并尽可能达成一致，同时为了提供更高质量的版本，测试团队需要其他部门（尤其是研发部门）的高质量工作，这也是需要获得领导认可并支持的。

第六、对协同部门的管理——这个也是在同行的指点下我总结出来的。目标是让协同部分认可测试部的工作，并为测试团队的输入提供高质量的需求和版本，为测试部门的输出（产品）提供足够的保障和反馈（运维和运营）。这部分我暂时能总结出来的东西也不多，总的来说就是与人为善，及时沟通，共同提高。毕竟大家都是一条船上的同事，遇到问题，对事不对人，沟通问题。一般不会遇到解决不了的问题。

之前一直不怎么喜欢整理博客，最近突然发现自己需要再这些方便不断提升，特编写该文档，整理了大半天，感觉很多还不够精炼，欢迎各位同行交流指证。让我们共同进步。

附：

其他人的相关建议：

无论哪一层级的管理者都可以用这三句概括：自我提升，向上管理，向下负责。
关于「自我提升」三点：
1.以身作则
这点是管理中最重要的一点，没有之一！
2.提升领导技能
培养胜任新职位所需要的能力。
3.学会时间管理
新的时间分配结构，决定如何工作。

关于「向上管理」五点：
1.向上管理要影响老板而不是服从老板.
2.向上管理首先要管理好老板的预期
反复跟老板确认他对你的期望是什么，达成共识。共识非常重要，共识就是生产力！
3.向上管理必须只提建设性意见
4.向上管理要做到及时反馈
能用数据做反馈的一定带上数据。这点非常重要，数据不会骗人并且最能反馈客观情况。
5.向上管理要尽最大努力争取资源
资源包括人、钱、时间、等等。没有资源的管理者，寸步难行。

「向下负责」四点：
1.向下负责要对下属的成长负责
成长是下属最关注的事情，不能给下属带来成长的管理者都是弱鸡！
2.向下负责要对下属的工作结果负责
绝不能当甩手掌柜。
3.向下负责要对团队目标负责
管理者要给团队提供清晰的目标和努力的方向。没有明确目标，或者目标错误的团队注定不会做成事情。
4.向下负责要对团队文化负责
负责团队的文化打造和维护。正直、诚信这些就不必说了，这里出问题的团队都会烂掉。个人比较倾向于打造透明、开放、包容、学习型组织。这种团队更容易打硬仗，攻山头。