本期嘉宾鼎叔:互联网/通讯行业大厂技术总监,高级架构师,测试专家,敏捷教练。公众号「敏捷测试转型」作者,在 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。
来源/Canva

04 向上沟通的正确姿势:该强势还是含蓄?

首先,测试的 leader 做为管理者,沟通是非常重要的基础技能。如果一位测试同学,他的技术非常强但是沟通比较弱势,那么他其实更适合走技术专家的路线,不一定适合做管理。但沟通是可以修炼的,并不是说现在沟通水平一般以后就都不行。我也带过很多 leader,刚开始他们在沟通上比较内向比较保守,但是经过长时间的修炼,也是能够胜任沟通的角色。

那么再回到这个问题本身,我们在沟通 PK 的时候一定会遇到一些非常强势的核心角色。比如说,我就遇到过一些产品总监,会觉得漏测就是测试的锅,为什么你不多投人——是一种非常简单粗暴的逻辑。我觉得这种情况下,不要陷入鸡同鸭讲的无谓的争吵。

面对比较大的冲突(或者预想到可能有冲突),我倾向于提前将我的分析写下来,把我的逻辑放到群里面——可以事前也可以事后放,目的是让群里相关的人看到我的分析逻辑。我会一步步的说明,为什么这次出了问题并不是我们要加人的锅,更多是因为我们没有排好优先级;或者是因为我们的一些信息没有做评审,如果做了评审,我们根本就不需要加用例,就能够拦截这个问题。

在看了这个清晰的逻辑后,相关人员在跟我沟通的时候,就不会争吵。尽量避免陷入在现场靠声音的大小去 PK 胜负的困境。

总而言之,在跟那些强势的人沟通之前,我们要做好充分的准备。这种准备最好是可视化的,不要陷入完全靠情绪去争吵的情境。但如果真的陷入了这种争吵,那我们首先要及时刹车,晚一点再进行沟通会议,或者会后再单独聊。把刚才提到的所要准备的数据和逻辑列清楚后再聊。

作为相对而言 “羞涩” 一点的 leader,就尽量利用我们的逻辑做武器,还有数据分析作为沟通交流的道具。在聊的时候,如果是有第三方在场,我们也可以把一些内容投屏出来。当然,我们也要储备一些必要的小证据,把得到共识的证据抛出来,尽量减少无谓的争吵。这些证据可以是公司里一些高管的要求,或者高管的一些认可,包括历史上出现过的典型的问题等。

最后一点是关于管理者的性格,如果本身性格比较 “羞涩” 一些,那我建议你先在团队内创造一些交流 PK 的氛围。比如在自己团队中,针对一些可能的问题,在每次的周会或者月会中多找一些话题进行演练讨论。然后在团队之外讲遇到的问题,就不会那么被动,在谈问题时更容易把控自己的情绪。

我个人有一个习惯,就是每隔一个周期(比如月会时)都会跟团队成员聊一下现在遇到了哪些困难,我们的对策是什么,我们怎样去说服别人;或者是我们遇到了哪些事故,背后的真正原因是什么。在团队内已经做过事故原因的同步和研讨之后,再跟其他团队 leader 甚至上级沟通时就不会那么怯弱。

05 优秀测试团队的标准?

首先我们要承认一个现实,虽然都是测试,但是因为各种各样的原因,测试团队间的差距是很明显的。这中间的差距,就是需要我们不断自我突破、自我积累的一个过程。团队也有不同的发展周期,下面是我个人总结的一个测试团队从普通到卓越的演化过程

1)最初级的测试团队,或者说 “原始社会” 时期的测试团队更多就是接活。比如老板给你三个人力的活,你把活接下来并好好完成,必要时候加加班。

2)升级一小步:慢慢的我们就会有一些基本的自动化建设,有一些基本的自动化工具,形成基本的测试和分析流程。做到这些,就成长为自组织的初级熟练型的团队

3)再往上,就是逐步成为一个优秀高效的团队。优秀的测试团队是什么样子的呢?首先要求团队中的个人要优秀:团队里不应该有混日子,或者是对于测试没有什么兴趣的人。团队成员首先关心问题背后的根因是什么,对业务逻辑非常精通,其次对所使用的测试工具能够不断精益求精,愿意开阔眼界,从外部找一些更合适我们业务现状的测试工具。

4)后面的修炼会越来越困难,个人认为要从 “优秀 “变到更高一级的” 卓越 “的专家型团队,在有些方面需要至少数年的积累。

第一个就是我们的现在的技术方案,是否具备方法论的潜质?所谓的方法论就是我们能否把自己团队做过的一些事情变成一个,大家都能够快速掌握,快速复制的体系化打法。

另外一点,一个卓越的专家型团队,是能够找到现在的创新点,能够用比较少的精力突破低效的现状,拉高大家的效率上限。

最后一点要求,算是针对持续改进型的变革型的团队(比如阿里的 P9、腾讯 senior 的专家所带的团队),我们会期望这种团队能够找到突破行业普遍困难的抓手和技巧,能够有一套让优秀团队再向前进步的方案。并且这些方案是通用的,可以在不同部门甚至整个行业都可以复用和受益。

06 如何有效地激励团队成员?

无论对于优秀的测试管理者,还是任何技术团队的管理者,这都是一个非常好的问题。解决这个问题所涉及的理论,或者是行业中的打法各种各样,我在此分享一下自己个人喜欢使用的激励方式。

首先,作为一个普通的 leader,你一般没有太多给下属加薪升职或者发奖金的权利。哪怕有,也是有限的机会,不可能给到很多人。另一方面,就算你有加薪升职的权利,建议也不能乱用,千万不能把它变成每个人都觉得理所当然的 “激励 “,那就不再是激励。一旦某个同学觉得自己做得不错,没有升职,反而心里有负面情绪。

所以激励一定要精准,能够撬动团队成员改进积极性的才是好的激励。我的个人见解:最终极的激励一定是从个人的本质内心来激发。如果你能够给团队成员机会做自己感兴趣的事情,同时给与支持;并在这个基础上,给他一个名副其实的物质激励:这就是一个非常高级的激励。

具体来说,除了加薪升职,观察和了解团队成员的其他需求。比如,如果有人想成为效能专家,那么作为团队管理者,可以给出相关学习课程和书籍的建议,或者刚好有提效的专项项目让 ta 去做。还有的测试同学想开发某个测试工具,在更详细地了解他的想法后,可以减少 ta 一部分现有测试工作,让 ta 有机会去实践测试工具的开发。

但是也要有自己的原则,做为团队管理者我们要给到能力范围内的支持和资源,也要求看到成果和团队成员实实在在的付出。不接受团队成员只会一味要人要资源,完全不能独立自主解决问题。

07 团队中的孙悟空、老油条、老黄牛和初生牛犊

先说一个我在很多年前 “情境领导” 的课程中学到的基本概念:很多传统的管理学理论,会把我们的员工按照潜力的高低和个人意愿的高低,组合分为四个象限。有高潜高意愿、高潜低意愿、低潜高意愿和低潜低意愿。对于不同象限中的员工,有不同的管理方式。

在这里就不展开说这个通用的管理理论,大家有兴趣可以自己学习。回到测试团队管理,我们测试团队中的角色可能来自不同的年龄段,有不同的背景。作为团队的 leader,首先要画出团队工作的价值观:让大家知道在团队中工作,什么是底线,什么是红线。要用具体的案例,给大家明确一些不厚道不职业的情况绝对不能出现在自己的团队中。

其次是要明确激励的导向。让无论团队中哪种角色的成员,都了解团队中激励的导向,知道团队所讨厌的行为是什么,形成明确的共识。

如果明确了团队价值观,形成了自己团队的管理文化,那些不适合我们团队的同学就自动离开,甚至不需要团队管理者去做额外的一些动作。

再具体说一下几种个性化的团队成员。

初生牛犊(新人):团队有义务为新人提供完备的学习指导,比如要为新人指定师兄,设定新人必修的课程。但同时我们也要求新人一定要能够自主学习,因为企业不是学校。我们可以给新人一个观察期,但如果你自己对学习没有兴趣,就想躺平,在企业里是不能接受的。所以给新人传输的理念就是:我们会有足够多的资源帮助你成长,但是你要自主学习。同时可以对新人的学习成果进行考核,不是说离开了学校就不能考试。

孙悟空:我们鼓励团队中出现正儿八经的孙悟空,但前提是你要能够一个人,或者能带头把事情搞定。而不是说我空有一个很牛逼的想法,或者是三分钟热度后面就把当初想做的事情搁置了。那说明你并不是真正的孙悟空,更多是徒有其表。

老黄牛:首先,我觉得测试团队要有一个必要的价值观,就是我们不鼓励低效的加班或者说低效的敬业。我经历过的一些传统公司,老板一说质量要提高,测试就把用例增加一倍,或者是把覆盖的机型增加一倍。那增加这些对于我们测试团队有什么作用呢?答案是没有,甚至会让别人觉得测试团队就是个人力密集型的岗位,对我们的口碑有负面影响。更好的方式是,梳理出来我们要在哪些场景做适配测试,背后的根本逻辑是什么,然后针对这些逻辑去找用例。如果你这个老黄牛就是每天反复执行被分配到的测试用例,没有总结和梳理;那我觉得这种工作给到外包团队,用更低的成本来完成反而更好,没有必要留这样一个老黄牛在自己的团队中。

总结来说,对强者给与一定的挑战、设立一定的目标,同时检验他们是否真的是强者。对于技术和业务能力一般的人,提供非常严格丰富且完善的培训内容,但不是手把手地教。对一直没有什么进步的同学,要适当地施加压力。未来要淘汰的话,首先是踩红线和价值观不符合的同学;如果时局比较紧的话,那些一直没有进步的同学也可能会被淘汰掉或者外包化。

The End

看到这里,恭喜你又收获了满满的干货知识~更多关于跨团队、跨部门管理,管理者的自我修养等内容,将在《跟鼎叔聊聊测试团队管理(第二话)》中为大家分享。大家记得关注不要错过更新。

戳此链接可收听完整音频分享,我们下期再会 >>>


↙↙↙阅读原文可查看相关链接,并与作者交流