问答 对于临时找过来描述很模糊的测试需求,大家都是如何处理的呢

miss_you · 2021年12月08日 · 最后由 笑哼 回复于 2022年01月07日 · 1785 次阅读

最近在工作中发现一些痛点,其中思来想去还是没有很好解决办法,想来请教各位大神有没有什么好的建议。这个困扰我的问题就是:开发组的领导经常有一些自主优化,优化完后就直接找到我让我过一下某部分的功能,但是描述很模糊,比如:过一下普通下单流程,这样我的理解就是用户登录 - 找到某商品 - 填写下单信息 - 提交成功等,不会去想到要验证更改库存再下单的场景一类。之前有想过整理主流程确认,以后回归的时候按照主流程来验证,但是这样工作量很大,手上最近工作也很多,有没有其他的办法呢?💡

共收到 10 条回复 时间 点赞

发挥你的探索性测试能力咯~输出测试大纲,产品研发测试三方确认,出锅一块背吧

首先这么做合不合理 是不是必须 不是请理清楚流程 放在迭代版本上线 小版本自测
如果必须这么做 无法推卸
拉会议 评审修改点 覆盖范围 一起评估测试范围 保留代码 commit 记录

做好风险预案

这种最好是看代码改动,改了哪些模块,影响到哪些服务,来确定大致测试范围吧。 确实需要评审一下

开发自主优化这个动作是没问题的,定期偿还下技术债务,避免大窟窿。

楼主的苦恼应该是以下几点:

  • 最近手上工作很多,开发这玩意儿提测给你增加了工作量
  • 开发提测描述模糊
  • 要进行主流程回归,工作量很大,不做的话,风险又感觉挺大

开发做了优化,肯定得测试的,这块工作量无法避免。
但是可以要求他们走正常的提测流程,有需求、测试申请、备注改动范围和方法,优先级,上线时间等。这样就可以综合其他任务来进行排期。
以上有了之后,就可以大致的划分测试范围,看看是不是仍然要进行主流程全回归。

说了这么多,其实核心就是做好任务跟踪,每个任务有准入准出标准,有工作量预估,有优先级,有测试资源分配安排。你做的事情都能看得见,统计得到,可以追溯。应该可以减少楼主的一些烦恼。

最后,需要提醒楼主的是,开发 “过一下普通下单流程” 只是建议(除非这是和你商讨之后得出的结论),还是需要你根据他们改动的范围(自己对比代码版本差异也行,不过感觉你应该也没空)自己判断应该测哪些内容,毕竟你才是专业的测试,避免他说测啥就测啥。

要是我就打回了,必须说清楚改动,评估影响范围

谢谢大佬们给予的建议,给了我很好的启发。结合意见,我这边已着手整理这块欠缺的流程规范,再次感谢👍

梳理一个紧急变更流程,加入评审机制。

立规范,排期做好

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