本期嘉宾鼎叔：互联网/通讯行业大厂技术总监，高级架构师，测试专家，敏捷教练。公众号「敏捷测试转型」作者，在 TesterHome 论坛著有同名专栏《敏捷测试转型》。
主播 / 老徐，兔子
策划 / 小道消息播客节目组
以下内容是根据 4 月 3 日的直播整理的文字内容，戳链接可收听完整音频分享。
01 如何进入了测试行业？
——推开一扇窗，打开广阔新世界
自己的计算机根基主要来自中学时期，大学里主修数学专业，也做过一些计算机的课题，但是整体上自己的编程能力偏竞赛方向。
大学毕业时，依靠编程竞赛的成绩进入一家外企做开发工程师（也叫做 Designer）。做了一年后发现，自己对通信行业核心网方面的编程，实在没有太大兴趣，自己的进步也比同期加入公司的同学们要慢一些。后来我被调派到测试部，因为对业务逻辑和测试范围这些都非常感兴趣，在测试部做的非常不错。我就萌生了在测试这个方向继续发展的想法，然后逐步从测试工程师，做到高级测试工程师，再到更高级的管理者。
02 如何向上体现测试团队的价值？
从业这么多年，我自己也接触过各种不同的上级：跟有的上级在管理理念上非常合拍，做事就很顺；也遇到过不太理解测试，或者是跟自己的测试管理方向不一致的上级，在这样的上级手下带团队就会做的很痛苦。
总结我个人的经验教训，我认为跟上级沟通最重点的事情就是：我们首先在概念里要有这样一个自我认知，就是测试团队在公司里是一个成本中心。什么叫做成本中心？就是一般从上级的角度，或者从公司高管的角度来看，测试团队里的人越少越好。明确了这一点，我们就容易理解：做为测试团队的管理者，如果找老板要尽可能多的资源，是很容易引起上级的负面看法的。因为从经营者的角度，是希望控制测试团队的成本。
但是另外一方面，我们怎样给测试团队争取到更多的利益或者更好的发展前景呢？那就需要我们对老板的认知进行一些拓展：让老板从把测试团队当做一个必须付出的成本，变为认可测试团队也可以带来更多的价值。
具体应该怎么做呢？我们后面会聊到一系列的相关技巧，在这里先列出几点。
除了找 bug，测试团队是不是能给公司的业务带来更多贡献？比如帮助整个团队的品质得到进一步的提升：“品质 “要比” 缺陷 “的范围大很多。比如帮助提升用户满意度：与一般的客服人员相比，测试团队在这方面是不是可以带来更多的价值。如果我们从这些角度去跟老板交流，并给出我们测试团队的打法和策略，我觉得老板是会愿意在这一块付出更多投资的。
总结一下就是，我们可以从给公司带来更大回报的角度，去提供更多的可能性和更多的方案。
还有一方面是我比较喜欢的，就是测试是否一定要等到最后才去做一些必要的检查呢？如果我们只做必要的检查，那么老板愿意在测试方面付出的钱是非常少的。但是如果我们告诉老板说：我们可以把测试往左移、往前推，我们可以帮助产品经理提高所输出需求的质量；让项目中用更少的产品经理，给出更高质量的需求，让用户更加满意——那么这个价值就会大很多。
另一方面是，作为测试如何帮助开发提高所提交的代码质量。一般而言，开发是公司中最大的一个主体。如果我们能在开发方面做出更大的贡献，让我们的 CTO 了解到测试团队能给公司业绩和工程效能输出较大的推动力，就会让老板对测试团队有一个更好的印象，ta 也会愿意给测试团队更多的支持。
03 如何向上维护关系？
作为一个测试 leader，首先我们不能默认只要好好工作就可以，平时不需要跟上级有太多沟通。不能等到出了故障，或者是出现了一些负面舆情的时候才出面，才跟老板汇报。
第二点是，我们要面对的老板可能是测试方面的高管，可能是技术的高管，也可能是综合性的高管。来自不同背景的人，对于测试的理解差异也非常大。哪怕是测试方面的高管，也可能不是测试出身。做为测试团队管理者，要主动了解上级对测试团队的需求。
我的习惯是，每次绩效考核周期的早期，比如说每半年、或者是三个月的时候，我都会主动跟自己的上级管理者聊一聊，聊什么呢？比如工作的规划，以及过去几个月核心的成果进展。在聊天的过程中，我会刻意搜集 ta 对测试团队的诉求。对于上级管理者来说，我们主动发问，了解 ta 对测试团队有什么抱怨，有什么期望，对 ta 来说就是一个很好的反馈。ta 会认为测试团队正在关注自己的痛点，我们跟上级管理者之间的距离就可以被拉近。
另外，我会趁这个时候跟 ta 汇报一下自己是如何开展工作的。比如说我的重点工作是怎么提效，那提效的具体打法策略是什么，效果怎么样。我会尽量的找一些恰当的时机给上级管理者做 demo，比如在月度会议的时候。如果没有刚刚好的机会，那就单独约 ta 的时间，跟 ta 说测试部有一个很重要的项目，希望 ta 给一些评价。在 Demo 时，可以把自己团队中做得最好的一个测试案例，当做 showcase 展示给上级管理者，然后搜集 ta 的反馈。
简而言之，我们做为测试团队管理者，首先要了解上级管理者对测试的痛点，再把痛点传递给一线测试骨干，让测试骨干把它作为个人的 OKR 或者个人要公关的一个堡垒。另外一方面要定期跟你的管理者有一个规划上的同步，及时展示测试团队近期的里程碑，给管理者一个直接的、面对面的，或者是一个可视化的成果展现。做到这几点，我觉得管理者对我们的信任度和满意度，都会在一定程度上得到提升。
还有一个提醒：我们不能忽略了产品（部门）。有的团队中，测试可能跟技术走得比较近，但是跟产品走得比较远。产品中相关的平行高管或者平行管理者，也是我们作为测试团队管理者需要打通的一个重要资源。我在工作中可能跟产品的打通会少一点，但我也会让产品经理搜集他们对于质量的一些痛点要求。同时我也会试探，看测试能给产品经理的需求带来哪些帮助。
那么还有一个角色跟测试的关系也比较重要的，那就是 PMO——项目总监。测试团队和 PMO 如果是一个正向的合作关系，那就双赢。项目经理最怕的就是项目延期；遇到项目延期的情况，很多时候上线的负担就会压到测试头上。如果项目总监跟测试团队管理者是站在一个战壕里的队友，那么测试会尽快把风险暴露给项目经理，然后借助项目经理去把这个风险往前拉。如果反过来，测试总是被项目经理摧着问 “你有没有人，或者你有没有风险”，那么测试一方面很被动，另外一方面，项目经理会把这种负面信息传递给高层，那对测试的发展就不利。
综上所述，测试团队管理者一方面要定期跟上级沟通，进行比较好的工作成果的里程碑汇报；另一方面跟相关角色的拉通也非常重要，包括开发 leader、PMO 以及产品 leader。
04 向上沟通的正确姿势：该强势还是含蓄？
首先，测试的 leader 做为管理者，沟通是非常重要的基础技能。如果一位测试同学，他的技术非常强但是沟通比较弱势，那么他其实更适合走技术专家的路线，不一定适合做管理。但沟通是可以修炼的，并不是说现在沟通水平一般以后就都不行。我也带过很多 leader，刚开始他们在沟通上比较内向比较保守，但是经过长时间的修炼，也是能够胜任沟通的角色。
那么再回到这个问题本身，我们在沟通 PK 的时候一定会遇到一些非常强势的核心角色。比如说，我就遇到过一些产品总监，会觉得漏测就是测试的锅，为什么你不多投人——是一种非常简单粗暴的逻辑。我觉得这种情况下，不要陷入鸡同鸭讲的无谓的争吵。
面对比较大的冲突（或者预想到可能有冲突），我倾向于提前将我的分析写下来，把我的逻辑放到群里面——可以事前也可以事后放，目的是让群里相关的人看到我的分析逻辑。我会一步步的说明，为什么这次出了问题并不是我们要加人的锅，更多是因为我们没有排好优先级；或者是因为我们的一些信息没有做评审，如果做了评审，我们根本就不需要加用例，就能够拦截这个问题。
在看了这个清晰的逻辑后，相关人员在跟我沟通的时候，就不会争吵。尽量避免陷入在现场靠声音的大小去 PK 胜负的困境。
总而言之，在跟那些强势的人沟通之前，我们要做好充分的准备。这种准备最好是可视化的，不要陷入完全靠情绪去争吵的情境。但如果真的陷入了这种争吵，那我们首先要及时刹车，晚一点再进行沟通会议，或者会后再单独聊。把刚才提到的所要准备的数据和逻辑列清楚后再聊。
作为相对而言 “羞涩” 一点的 leader，就尽量利用我们的逻辑做武器，还有数据分析作为沟通交流的道具。在聊的时候，如果是有第三方在场，我们也可以把一些内容投屏出来。当然，我们也要储备一些必要的小证据，把得到共识的证据抛出来，尽量减少无谓的争吵。这些证据可以是公司里一些高管的要求，或者高管的一些认可，包括历史上出现过的典型的问题等。
最后一点是关于管理者的性格，如果本身性格比较 “羞涩” 一些，那我建议你先在团队内创造一些交流 PK 的氛围。比如在自己团队中，针对一些可能的问题，在每次的周会或者月会中多找一些话题进行演练讨论。然后在团队之外讲遇到的问题，就不会那么被动，在谈问题时更容易把控自己的情绪。
我个人有一个习惯，就是每隔一个周期（比如月会时）都会跟团队成员聊一下现在遇到了哪些困难，我们的对策是什么，我们怎样去说服别人；或者是我们遇到了哪些事故，背后的真正原因是什么。在团队内已经做过事故原因的同步和研讨之后，再跟其他团队 leader 甚至上级沟通时就不会那么怯弱。
05 优秀测试团队的标准？
首先我们要承认一个现实，虽然都是测试，但是因为各种各样的原因，测试团队间的差距是很明显的。这中间的差距，就是需要我们不断自我突破、自我积累的一个过程。团队也有不同的发展周期，下面是我个人总结的一个测试团队从普通到卓越的演化过程。
1）最初级的测试团队，或者说 “原始社会” 时期的测试团队更多就是接活。比如老板给你三个人力的活，你把活接下来并好好完成，必要时候加加班。
2）升级一小步：慢慢的我们就会有一些基本的自动化建设，有一些基本的自动化工具，形成基本的测试和分析流程。做到这些，就成长为自组织的初级熟练型的团队。
3）再往上，就是逐步成为一个优秀高效的团队。优秀的测试团队是什么样子的呢？首先要求团队中的个人要优秀：团队里不应该有混日子，或者是对于测试没有什么兴趣的人。团队成员首先关心问题背后的根因是什么，对业务逻辑非常精通，其次对所使用的测试工具能够不断精益求精，愿意开阔眼界，从外部找一些更合适我们业务现状的测试工具。
4）后面的修炼会越来越困难，个人认为要从 “优秀 “变到更高一级的” 卓越 “的专家型团队，在有些方面需要至少数年的积累。
第一个就是我们的现在的技术方案，是否具备方法论的潜质？所谓的方法论就是我们能否把自己团队做过的一些事情变成一个，大家都能够快速掌握，快速复制的体系化打法。
另外一点，一个卓越的专家型团队，是能够找到现在的创新点，能够用比较少的精力突破低效的现状，拉高大家的效率上限。
最后一点要求，算是针对持续改进型的变革型的团队（比如阿里的 P9、腾讯 senior 的专家所带的团队），我们会期望这种团队能够找到突破行业普遍困难的抓手和技巧，能够有一套让优秀团队再向前进步的方案。并且这些方案是通用的，可以在不同部门甚至整个行业都可以复用和受益。
06 如何有效地激励团队成员？
无论对于优秀的测试管理者，还是任何技术团队的管理者，这都是一个非常好的问题。解决这个问题所涉及的理论，或者是行业中的打法各种各样，我在此分享一下自己个人喜欢使用的激励方式。
首先，作为一个普通的 leader，你一般没有太多给下属加薪升职或者发奖金的权利。哪怕有，也是有限的机会，不可能给到很多人。另一方面，就算你有加薪升职的权利，建议也不能乱用，千万不能把它变成每个人都觉得理所当然的 “激励 “，那就不再是激励。一旦某个同学觉得自己做得不错，没有升职，反而心里有负面情绪。
所以激励一定要精准，能够撬动团队成员改进积极性的才是好的激励。我的个人见解：最终极的激励一定是从个人的本质内心来激发。如果你能够给团队成员机会做自己感兴趣的事情，同时给与支持；并在这个基础上，给他一个名副其实的物质激励：这就是一个非常高级的激励。
具体来说，除了加薪升职，观察和了解团队成员的其他需求。比如，如果有人想成为效能专家，那么作为团队管理者，可以给出相关学习课程和书籍的建议，或者刚好有提效的专项项目让 ta 去做。还有的测试同学想开发某个测试工具，在更详细地了解他的想法后，可以减少 ta 一部分现有测试工作，让 ta 有机会去实践测试工具的开发。
但是也要有自己的原则，做为团队管理者我们要给到能力范围内的支持和资源，也要求看到成果和团队成员实实在在的付出。不接受团队成员只会一味要人要资源，完全不能独立自主解决问题。
07 团队中的孙悟空、老油条、老黄牛和初生牛犊
先说一个我在很多年前 “情境领导” 的课程中学到的基本概念：很多传统的管理学理论，会把我们的员工按照潜力的高低和个人意愿的高低，组合分为四个象限。有高潜高意愿、高潜低意愿、低潜高意愿和低潜低意愿。对于不同象限中的员工，有不同的管理方式。
在这里就不展开说这个通用的管理理论，大家有兴趣可以自己学习。回到测试团队管理，我们测试团队中的角色可能来自不同的年龄段，有不同的背景。作为团队的 leader，首先要画出团队工作的价值观：让大家知道在团队中工作，什么是底线，什么是红线。要用具体的案例，给大家明确一些不厚道不职业的情况绝对不能出现在自己的团队中。
其次是要明确激励的导向。让无论团队中哪种角色的成员，都了解团队中激励的导向，知道团队所讨厌的行为是什么，形成明确的共识。
如果明确了团队价值观，形成了自己团队的管理文化，那些不适合我们团队的同学就自动离开，甚至不需要团队管理者去做额外的一些动作。
再具体说一下几种个性化的团队成员。
初生牛犊（新人）：团队有义务为新人提供完备的学习指导，比如要为新人指定师兄，设定新人必修的课程。但同时我们也要求新人一定要能够自主学习，因为企业不是学校。我们可以给新人一个观察期，但如果你自己对学习没有兴趣，就想躺平，在企业里是不能接受的。所以给新人传输的理念就是：我们会有足够多的资源帮助你成长，但是你要自主学习。同时可以对新人的学习成果进行考核，不是说离开了学校就不能考试。
孙悟空：我们鼓励团队中出现正儿八经的孙悟空，但前提是你要能够一个人，或者能带头把事情搞定。而不是说我空有一个很牛逼的想法，或者是三分钟热度后面就把当初想做的事情搁置了。那说明你并不是真正的孙悟空，更多是徒有其表。
老黄牛：首先，我觉得测试团队要有一个必要的价值观，就是我们不鼓励低效的加班或者说低效的敬业。我经历过的一些传统公司，老板一说质量要提高，测试就把用例增加一倍，或者是把覆盖的机型增加一倍。那增加这些对于我们测试团队有什么作用呢？答案是没有，甚至会让别人觉得测试团队就是个人力密集型的岗位，对我们的口碑有负面影响。更好的方式是，梳理出来我们要在哪些场景做适配测试，背后的根本逻辑是什么，然后针对这些逻辑去找用例。如果你这个老黄牛就是每天反复执行被分配到的测试用例，没有总结和梳理；那我觉得这种工作给到外包团队，用更低的成本来完成反而更好，没有必要留这样一个老黄牛在自己的团队中。
总结来说，对强者给与一定的挑战、设立一定的目标，同时检验他们是否真的是强者。对于技术和业务能力一般的人，提供非常严格丰富且完善的培训内容，但不是手把手地教。对一直没有什么进步的同学，要适当地施加压力。未来要淘汰的话，首先是踩红线和价值观不符合的同学；如果时局比较紧的话，那些一直没有进步的同学也可能会被淘汰掉或者外包化。
The End
看到这里，恭喜你又收获了满满的干货知识~更多关于跨团队、跨部门管理，管理者的自我修养等内容，将在《跟鼎叔聊聊测试团队管理（第二话）》中为大家分享。大家记得关注不要错过更新。
