敏捷测试转型 聊聊项目测试时间不足怎么办

鼎叔 · 2022年06月09日 · 最后由 简一 回复于 2022年06月24日 · 3867 次阅读

这是鼎叔的第十九篇原创文章。
行业大牛和刚毕业的小白,都可以进来聊聊。

欢迎关注本人专栏和微信公众号《敏捷测试转型》,大量原创思考文章陆续推出。

4 月 23 日周日,鼎叔返场再次参与小道消息播客,和主持人老徐和兔子继续畅谈。本文是返场直播的第一部分,重点分享项目测试时间不足怎么办,以及 leader 如何同时修炼好管理和技术。

在之前的直播中,鼎叔分享了他关于向上管理、向下管理,跨团队跨部门管理,以及 leader 自我修炼的经验。欢迎查阅:聊聊 leader 的向上管理和向下管理 https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247483800&idx=1&sn=96aa54572e672ec236b8bfb3dc9b9ac7&chksm=c24fb4faf5383dec9369e842487b711d55121fb8fd6d08fc4f9fb092c3ecdebf72ee501d6e7e&token=912696903&lang=zh_CN#rd
,聊聊 leader 的自我修炼 https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247483802&idx=1&sn=bcbd8484c38b95b7c83e73e6e560b53e&chksm=c24fb4f8f5383deed7ab529402e7bc27751832010f8c3a9a612bd89f20399791f9b60b514e5c&token=912696903&lang=zh_CN#rd

本次返场,继续分享涉及多维度的项目管理和人员管理问题。

本文是根据分享,精简和提炼出的文字版本。点击文末链接,收听完整音频分享。

01
如何应对为了守住项目上线日期,缩短测试时间的情况?
一、放平心态,坦然接受
做项目必然要面对交付的风险,测试团队经常被推到风险 “兜底人” 的角色——且不论这种做法是否正常,但确实存在。因为测试阶段之前的环节延误,而导致留给测试的时间变短的情况也经常发生。

在这类事情发生后,只要我们已经做好 “分内” 之事,尽到专业精神,实际上并不会承担太大指责。哪怕项目失败了,也很少真的归咎于测试。

二、面对测试时间可能被压缩,应该重点把握的几件事
尽早跟产品或项目经理或者开发,充分沟通整个项目的交付周期,并明确测试独占周期。
“尽早” 是多早?这时候还在项目规划中,开发可能还没开始写代码。我们在这个阶段就要考虑好,需要多长时间留给测试独占。

什么叫做 “独占”?就是在开发写完代码并且正式提测后,单独留给我们开始测试到最后完成测试的一段时间。

一方面我们要公开透明地给出测试所需的独占周期,如果测试时间会被压缩,也好明确能接受的最短时间。

比如,预估的测试独占周期是七天,但是产品或者项目经理说只有五天测试时间。我们可以只用五天来测试,但是要公开一份项目关键角色签字承认的风险声明:通过倒排,把原本七天的工作按照优先级放在五天来做;如果发生一些意外或者发生一些问题,那么有可能要放弃优先级低的两天的工作,或者是降低质量。如果像这样规划好,在这五天保证好基础的质量,就算上线后有一些小 bug、小故障,我相信大家也是可以接受的。

另一方面要考虑,测试独占周期里面的所有测试工作,是不是只能按顺序 “串行”?比如说,我们的测试工作包括兼容测试、性能测试和功能测试,在时间有限的情况下,这些不同类型的测试工作是否可以并行,在短时间做好更多的工作。

B. 不是只能在提测后进行的事情,可以左移到独占周期之前来做,并且透传给项目的关键角色。

到底有哪些事情可以左移呢?以我自己现在所做的大型项目为例,可以左移的事情大概有这些:
01

通过提前计划测试范围和测试策略,估算所需测试人力,预测后期可能需要借调多少测试人员
有一些大型项目,在测试阶段会很慌乱的一个原因就是,突然临时找了一堆人来协助测试。如果临时抱佛脚,虽然人力增多,但是可能比原来的质量更差。作为测试负责人,当我们预见到人力有可能不足的时候,就早一点把可以帮助测试的人力卷入进来,提前告知他们后期有可能要来协助我们做测试。可能这些测试人员手上已经有其它项目要跟,我们至少可以先给他们分享一些项目资料——比如已有的测试资料、测试用例和测试策略等知识,让他们先从学习的角度做好准备——后期就能更好地缓解测试资源的不足。
02

把一些专项规划提前做好
什么专项呢?比如说测试环境。

越是项目时间紧张时,测试数据和测试环境经常是导致 “意外” 发生的主要原因之一。怎样提前构建好测试环境呢?其中一个做法就是,让开发在我们的环境里做自测。有的公司会实行 show case:在开发提交集成测试前,要当着测试、产品和 leader 的面,做一个代码能够正常运行的的 show case;开发同学为了保证自己的代码在 show case 时跑通,会自觉做大量的环境搭建和数据准备,以及自测。

还有比如压力测试、安全保障等方向,也可以提前规划:要不要做,需要什么样的环境来做,具体包括哪些方面等。提前列好清单,安排好负责人。
03

让技术能力比较强的测试同学参与 code review
如果测试同学参与 code review,至少就能够知道这一次版本发布中提交的代码跟上一次比,主要的差异是什么,开发到底引入了哪些变化。那么,这些变化可能就是这次测试的重点。如果 code review 后发现,很多东西没有变更,那没有变动的部分,在测试时投入的精力就少一点,只做一些经典的 regression。而是把更多的精力放到 code review 发现的风险点上。
04

预设应急响应 SOP
应急响应的 SOP 需要关注的点包括:一旦发生了线上异常,谁做第一步的追查,告警要发送给谁,什么样的角色小组要做回滚,要采取什么措施进行止损等。

综上所述,围绕着测试时间不足的问题,我们要梳理好风险清单,针对每一条风险都要有一个结论。常见的结论包括:首先明确,如果某个风险发生了,对业务的影响大不大?假设影响并不大,我们希望它尽量少发生,但是真的发生了也不会有很严重的后果。第二点是指定一个责任人或者一个角色,处理风险。第三点是规划好缓解的措施,比如可以提供支持的后备人力和团队。第四点是做好监控,一旦发生我们再响应。

相信如果我们做到这些,加上前面所说的在项目中公开测试独占周期、测试方案和计划,就已经在能力范围内做到足够专业,哪怕项目上线后真的有问题发生,也不会有人对我们做太大的追责。

02
左手管理右手技术,测试团队管理者应该如何做好自我发展?
管理是一个非常长的修炼的过程,可以说它一半是艺术,一半是科学。想要成为一个很牛的管理者,需要不断学习。单纯要做好一个测试团队管理者,或者是一个技术团队的管理者,需要学习的东西已经非常多了。

一、方法论
首先是更好地管理团队的方法论,然后还有很多演练性的东西,比如说脑暴会、沙盘等。这些可以通过 MBA 或者一些技术 leader 专属的培训资源来学习,但相比学习资源,更重要的是与人交流。

二、多与人交流
如果参加过管理者修炼的课程,就会发现,老师在课上教授的教材,其实网上也找得到,更重要的跟你一起上课的人。所以如果你能跟自己周围优秀的 leader 同学,或者是跨部门、甚至跨公司的优秀 leader 多切磋交流,参加一些管理沙龙,对于管理能力的提升会非常有帮助。

管理不同于技术,掌握了一门技术,你可以在这个方向越挖越深。而对于管理,因为管理者的性格和团队情况的差异,所以需要不同的解决方案;并且没有最优解,只有适合和不适合,以及最终的效果是高还是低。

三、实践和总结
有了管理的理论和学习交流的社区,接着就是一边实践一边做 AB test。在自己的团队中,用不同的管理方法都试一试,慢慢积累效果好的管理方法变成自己的武器。换了一个部门、一个公司,之前好的管理手段还可以复用。

管理经验是可以不断正向积累的,前提是你真的把管理当做重要的事情对待。我也看到很多的测试 leader 或者是开发 leader,他们觉得管理这个事情比较 “虚”,还是 “务实” 一些把项目跟好。一年下来,可能除了自己去参加培训,不会在自己团队里做任何的管理实践。我也见过很多的 leader,觉得管理不就是打考核,不就是跟员工沟通绩效这些简单的事儿吗?这些做法还是把管理想象得太简单了。

修炼到高阶的管理者,一定是让自己的下属觉得跟着自己干是有收获的。这个收获不只是技术上和项目上的收获,也包括做人,做一个成熟的职场专业人士;员工会把管理者当做导师,能够跟着管理者学习成长。另一方面,通过管理者好的营造方法,团队氛围也更加健康,让下属觉得在这个集体非常开心。

在管理层的晋升上,也不是说只要管理做的非常好,就一定有机会向上晋升。还要看你把握关键项目的能力,还有一部分的运气。但是机遇出现前,你有没有足够多的影响力,能不能让老板放心,是需要靠你自己进行长期积累的。

如果你在自己团队内树立了良好的口碑;其他团队的同僚也觉得你在管理上做的很好,要向你学习;同时适当的把一些管理成果展现给上级,或者邀请上级来参与自己的一些管理上的举措,让上级也对自己的管理能力认可。当合适的时机出现时,你就更能把握机会更上一层楼。

来源 | Canva

以上是我的答案的前半部分,下面来说一下后半部分:到底应该多修炼技术,还是修炼管理能力?

个人认为,作为工程师出身的管理者,还是尽可能把技术修炼好。如果你既是一位非常懂测试的专家,又是一位管理者,会更有前途,否则可能只会在特定的公司发展得好。当前这个公司的老板可能非常欣赏你,但是万一局势发生变化,比如一些业务调整,你必须换部门,甚至你可能换到其他公司;在这种情况下,强管理弱技术就存在很大的风险。甚至在被迫寻找新机会时,你的技术实力可能根本无法支撑自己换工作。

如果你属于高阶的 leader,会更有可能发现技术的缺失带来的风险:因为越高级的 leader,在市场上的 “坑” 就越少。如果你没有很强的技术积累(从零到一、或者从一到十的系统化的技术积累),技术上的沟通表达不够专业,其他公司的老板可能也不放心把一个大团队交给你来带。

假设我的团队有一个 leader 的空缺,在挑选候选人时我肯定不会只看 ta 管理上的经验。我首先会看 ta 在相应的业务线,有没有一个完整的系统化的思考?ta 的测试策略是不是经得起推敲的?只有当我觉得 ta 认知的深度和广度能够撑得起这个团队的发展,我才会考虑让 ta 成为候选人。我不会单纯因为某个人在某家公司做了五年、十年的管理就直接让这个人上任,相信其他公司也是一样。

作为测试团队管理者,首先要打造自己体系化的管理思路,另一方面要积累属于自己的核心项目经验。这个经验既可以支撑你在当前公司的发展,也能为你将来寻找新机会加码。

如何积累核心项目经验呢?
你带的团队起了十个项目,每个项目你都有参与开会,做了粗略了解——这些项目都不能成为你的核心项目,因为你没有在项目发展中发挥实际作用。除非把这十个项目的 leader 都培养好,那也可以给自己的管理成果添彩。

一个核心项目,首先在公司里是受到老板关心和重视的;然后你要真的投入进去,在项目里起到主导作用。这个主导作用,不一定是画各种架构图或者写代码,或者做接口设计,而是参与从孵化到上线的每一个关键会议的技术讨论。同时在认真思考后,对现有的技术方案提出质疑和建议。不管自己的建议是否生效,至少自己是真正动脑子想过的。如果你做甩手掌柜,个人认为你不太可能在日新月异的技术行业,成为一个优秀的 leader。

但有一点要注意,你不能用自己的质疑去取代下属的决策。你可以提出一些不同的想法,但是不能因为你是 leader,就强制下属执行。而是多跟下属切磋,了解他们的想法,最终还是尊重团队的决策。通过这些思考、切磋和交流,在这个项目成功后,你跟别人聊这个项目,才能让人感觉你真的是其中的一份子。

从团队的角度来说,每个一线团队,既需要一个管理成熟的 leader 能够给大家更高的满意度,也需要 leader 在方案的把握上,能给出自己的见解,给大家一些指引。

如何帮助技术弱的 leader 更好地成长
在大公司,有的 leader 型人才,在晋升方面反而比不过一些强技术型的人才。因为技术专家的成绩说出来以后,容易得到各个部门的评委认可。而有一些 leader,ta 的专业职级还不高,但是又想晋升专业职级。Ta 能在技术上输出的东西非常浅,表现就是东一榔头西一棒——在整个项目中一下子搞搞质量,一下子搞搞度量,一下子搞搞改进,然后好像又懂一点点架构——但是什么都不深。这种情况下,ta 的晋升是非常痛苦的,而且也让人感觉 ta 不太适合作为一个优秀的 leader 来培养。

对于这样的 leader,我们会给 ta 一个核心项目,让 ta 去做更重要的主导角色。简单来说就是:缺什么补什么。如果 ta 对于架构学习不够,就让 ta 在项目里画架构图,给大家做架构的分享;如果 ta 对于质量意识不足,就让 ta 担任质量改进专项的负责人:原则是一定让 ta 自己上手实践。如果给了 ta 一定时间的实践机会,但是 ta 在某方面的意识还是不够,我觉得应该暂缓 ta 的晋升。还是可以继续给他机会,补上自己的短板。但是如果经过一定周期后,ta 还是没有进步,可能就有被替换掉的风险。

☟点击https://www.ximalaya.com/sound/529143008?source=m_jump ,收听完整音频节目

共收到 2 条回复 时间 点赞

学习了,最近一直被压缩的测试时间所折磨,只能基于风险做出取舍的测试。还是项目管理不太行

比如,预估的测试独占周期是七天,但是产品或者项目经理说只有五天测试时间。我们可以只用五天来测试,但是要公开一份项目关键角色签字承认的风险声明:通过倒排,把原本七天的工作按照优先级放在五天来做;如果发生一些意外或者发生一些问题,那么有可能要放弃优先级低的两天的工作,或者是降低质量。如果像这样规划好,在这五天保证好基础的质量,就算上线后有一些小 bug、小故障,我相信大家也是可以接受的。

--非常赞同的优秀产践,我们也经常这样处理呢😀

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册