小道消息 鼎叔返场:如何应对测试时间被迫压缩?

兔子🐰 for 一起听播客 · 2022年05月12日 · 最后由 liu 回复于 2022年05月13日 · 2675 次阅读

鼎叔返场,深入聊聊测试团队管理——如何应对缩短测试时间来守住项目上线日期?

本期嘉宾鼎叔 @dylan.zhang :互联网/通讯行业大厂技术总监,高级架构师,测试专家,敏捷教练。公众号「敏捷测试转型」作者,在 TesterHome 论坛著有同名专栏《敏捷测试转型》。

先来三个链接,大家各取所需:

一、放平心态,坦然接受

做项目必然要面对交付的风险,测试团队经常被推到风险 “兜底人” 的角色——且不论这种做法是否正常,但确实存在。因为测试阶段之前的环节延误,而导致留给测试的时间变短的情况也经常发生。

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

二、面对测试时间可能被压缩,应该重点把握的几件事

A. 尽早跟产品或项目经理或者开发,充分沟通整个项目的交付周期,并明确测试独占周期。

“尽早” 是多早?这时候还在项目规划中,开发可能还没开始写代码。我们在这个阶段就要考虑好,需要多长时间留给测试独占。
什么叫做 “独占”?就是在开发写完代码并且正式提测后,单独留给我们开始测试到最后完成测试的一段时间。

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

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

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

到底有哪些事情可以左移呢?以我自己现在所做的大型项目为例,可以左移的事情大概有这些:
1)通过提前计划测试范围和测试策略,估算所需测试人力,预测后期可能需要借调多少测试人员

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

2)把一些专项规划提前做好

什么专项呢?比如说测试环境。

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

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

3)让技术能力比较强的测试同学参与 code review

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

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

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

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

未完待续
左手管理右手技术,测试团队管理者应该如何做好自我发展?
做员工绩效考核时,怎样给出合理的低绩效?

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


把眼睛留给路上风景,把耳朵留给小道消息播客
共收到 5 条回复 时间 点赞

发邮件通知项目中各端管理者,做好预期管理

如果测试时间可以被压缩,说明本身这个管理层对测试的认知无非就是 “点点点” 了,我的建议是直接开摆,你的后果无非就是换一家,有啥呢!

因为你呗压缩了 1 次,2 次、3 次,这个之前的债原来越多,甚至觉得测试本来就不需要那么多时间。我觉得要反向思考一下,为什么不可以考虑不上某些不成熟的项目。

补充下这种问题明显是管理问题,只是个人一次,那就是列好各方责任就跟文章说的一样,但是常态化就算了。

liu 回复

那家公司看得起测试,一个项目组最烦的就是测试

hu 回复

这个观点不敢苟同,我自己也做过测试,没有觉得在哪里被项目烦过。看不看得起这件事很虚,首先要看得起自己。

hu 回复

你说的也没错吧,你会遇到这样或者那样的公司。针对你说的这种,我的建议是开摆啊,或者自己走人啊,这个自己衡量了。如果你是测试的话,最烦的是测试这句我理解是你的测试工作做的太好,对他们提出了很多的 bug,或者流程提出了很多问题,那说明你的质量管控工作做的好,那是公司或者你的领导不识货呗,不用置气,直接开摆或者换啊,你的人生你自己做主哟。

当然,也可能是你的工作做的不是他们想要的,这个跟测试还是开发还是产品没有关系了,这是单纯烦你这个人,这个要自己区别一下。

总结;如果你感受到的烦是针对整个测试组,那你趁早走人;如果只是针对你,那你自己可能需要再判定下是你太积极太优秀还是你太菜。不知道这样说在不在点子上

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