问答 对于临时找过来描述很模糊的测试需求，大家都是如何处理的呢
最近在工作中发现一些痛点，其中思来想去还是没有很好解决办法，想来请教各位大神有没有什么好的建议。这个困扰我的问题就是：开发组的领导经常有一些自主优化，优化完后就直接找到我让我过一下某部分的功能，但是描述很模糊，比如：过一下普通下单流程，这样我的理解就是用户登录 - 找到某商品 - 填写下单信息 - 提交成功等，不会去想到要验证更改库存再下单的场景一类。之前有想过整理主流程确认，以后回归的时候按照主流程来验证，但是这样工作量很大，手上最近工作也很多，有没有其他的办法呢？
发挥你的探索性测试能力咯~输出测试大纲，产品研发测试三方确认，出锅一块背吧
首先这么做合不合理 是不是必须 不是请理清楚流程 放在迭代版本上线 小版本自测
如果必须这么做 无法推卸
拉会议 评审修改点 覆盖范围 一起评估测试范围 保留代码 commit 记录
做好风险预案
这种最好是看代码改动，改了哪些模块，影响到哪些服务，来确定大致测试范围吧。 确实需要评审一下
开发自主优化这个动作是没问题的，定期偿还下技术债务，避免大窟窿。
楼主的苦恼应该是以下几点：
- 最近手上工作很多，开发这玩意儿提测给你增加了工作量
- 开发提测描述模糊
- 要进行主流程回归，工作量很大，不做的话，风险又感觉挺大
开发做了优化，肯定得测试的，这块工作量无法避免。
但是可以要求他们走正常的提测流程，有需求、测试申请、备注改动范围和方法，优先级，上线时间等。这样就可以综合其他任务来进行排期。
以上有了之后，就可以大致的划分测试范围，看看是不是仍然要进行主流程全回归。
说了这么多，其实核心就是做好任务跟踪，每个任务有准入准出标准，有工作量预估，有优先级，有测试资源分配安排。你做的事情都能看得见，统计得到，可以追溯。应该可以减少楼主的一些烦恼。
最后，需要提醒楼主的是，开发 “过一下普通下单流程” 只是建议（除非这是和你商讨之后得出的结论），还是需要你根据他们改动的范围（自己对比代码版本差异也行，不过感觉你应该也没空）自己判断应该测哪些内容，毕竟你才是专业的测试，避免他说测啥就测啥。
会做自主优化是好事，长期可以持续保障代码的质量，毕竟赶需求很容易导致代码写得比较临时（比如各个配置项没抽离，各种 if 嵌套等），也叫做欠技术债。听楼主的描述，问题不是出在自主优化，而是出在临时插入不好安排，以及改动点模糊不好评估测试范围。
其实这个核心还是缺少流程规范导致信息不够透明，沟通不通畅。这类优化开发会觉得小 case 想简单处理，简单过头就变成无计划无规律了。如果说频率很低那还好，频率高还是有个流程规范统一一下，否则容易开发觉得测试效率低，测试觉得开发计划乱，双方都不满意。
建议你们的需求里增加一种类型，叫做技术优化类需求，提出者就是开发方。让开发这类调整都作为这类需求进行提出（注意不是提测时提出，而是在开始进行时就提出，和普通需求一样进入开发阶段前就明确提出并同步测试），并且提测时描述清楚改动点（直接附带 MR 更好，代码是最好的文档），这样整体测试的排期和资源安排就可以合理纳入，测试也可以有足够的时间根据改动点进行评估，如果改动风险低的甚至可以直接开发演示自测结果后，直接给予测试通过，减少测试投入时间。
要是我就打回了，必须说清楚改动，评估影响范围
上面已经回答得很好了，我来蹭蹭热度，我觉得的问题有几个：
- 开发自主优化，私下找你出时间测试 —— 不正规的流程，私下对接的工作不公开，做了事情没人知道，出了锅又无法撇清关系，吃力不讨好。建议让他走正规流程提测，对清楚排期，一般分 “产品需求” 和 “技术需求”，两者可以用不同的测试方式，“技术需求” 你可以要求开发给进出改动细节，一起去评估测试范围和测试用例（产品新增功能需求可能会较少做到好的代码改动评估）
- 找你测试，但是描述很模糊，导致你不知道要怎么测 —— 这种情况下测试同学就很被动，不去追问细节的话，最后线上出质量问题肯定第一个还是找测试盘问。建议让他澄清改动，否则不排期测试，而且设计出的用例一定要跟他一起评估（出锅一起背，很合理），直接无脑回归，一方面是浪费自己的时间，一方面对自己确实没有思考没有成长纯粹的工作量，从公从私出发都是不利的
- 手上最近工作也很多 —— 公开你自己的人力排期甘特图，或者其他形式都行，只要是对外公布你手头的事情，这个信息让别人获取到，只要是讲道理的人都知道不会再乱给你事情，插事情进来优先级评估好各方确认就没问题。
所以说，正规的流程，对大家都好，不用再顾虑太多人情世故，大家都遵守规则就好。
谢谢大佬们给予的建议，给了我很好的启发。结合意见，我这边已着手整理这块欠缺的流程规范，再次感谢
梳理一个紧急变更流程，加入评审机制。
立规范，排期做好
