如果你底下的测试人员跟你反馈，这个迭代一共产生了 300 多个缺陷（团队不大，十来个开发），作为测试负责人，你的想法是什么？之前在团队中其实也遇到过类似的问题，当迭代交付质量较差时，测试该如何应对？本文聊聊自己的一些想法。
在听到这个反馈的第一时间，我做思考以下 4 个问题：
还有多少缺陷被遗漏
当测试人员发现了这么多问题后，是否还隐藏着更多的未知问题？当测试人员疲于提交大量的缺陷时，测试执行的有效性是否降低了？还有哪些风险项存在？
修复这么多缺陷的成本是多少
由于产生了这么多问题，那么研发修复的成本是多少？需要多少时间才能完全修复，在这个修复的过程中，是否会引入更多的缺陷？这个应该是必然的，否则第一轮为什么发现这么多缺陷。风险进一步升级。
交付质量为什么这么差
为什么会在测试环节出才发现这么多问题？在提测之前，团队为质量保障都做了哪些事？是否执行到位了。
带着这么多疑问，我会让测试人员针对已发现的缺陷做一次分析，简单归类，看看哪些类似的缺陷占比高。
进一步思考，还有很多事需要进一步澄清：
摒弃幸灾乐祸的想法
测试人员不应该为这件事感到兴奋，认为发现这么多缺陷是件多么值得高兴的事，因为这意味着最终的交付质量肯定不容乐观，用户不满意，伤害的将是整个团队，不应该隔岸观火，也不应该随意吐槽研发的能力，这是整个团队的事。
是否存在过渡测试的情况
产品处在不同的阶段，面对不同的用户群体，对质量的要求是不一样的。测试人员在制定测试策略时，是否产生了偏差，虽然说对质量的高要求不能算错，但也要注意的成本的问题。之前遇到过一个面对研发人员使用的架构底座产品，有测试人员针对页面样式提出了近 50+ 的问题。还有关性能测试的指标，明明只有 10W 多的用户，却要求有 1W 的并发量；这类的场景，明显就属于测试过度的情况。
审视整个研发过程
多数情况下，当测试发现了这么大量的缺陷，本质上是整个研发过程出了问题，需要从更高的维度去审视全链路的研发过程，拉上产品和研发负责人，一起来查找问题的根源：
需求是足够清晰，数量是否过多？
研发的产能是否过于超负荷？还是人员配置有问题，能力有问题？
测试左移是否实施到位，比如尽早提供冒烟测试用例，研发是否执行到位；
过程中是否存在许多无关的干扰项？比如环境问题，上下游依赖问题，数据问题等等；
下个迭代，测试可以为此做些什么
测试左移可能是解决这类问题的一个有效方案，拉着研发一起明确需求，做 AC 确认。在研发过程中，尽早提供冒烟测试用例，指导研发进行自测。通过自动化的手段，结合到 CICD 的流程中去，尽快发现问题，等等。总之，不能干等着。测试人员需要为质量作出一些改变。
进一步延伸，还有些问题值得去思考
如何与领导沟通，协调质量与速度
在排除团队人员素质问题后（能被团队招进来的人，能力上应该没什么问题），本质上还是质量与交付速度的取舍。需要拿着数据去和领导说话，而不是主观感觉。笔者的做法是关注团队的工时评估与最终的交付完成度。比如：团队在迭代初期，预计完成 10 个 Story，但是最终可发布的 Story 只有 8 个，那么完成度只有 80%。团队的产能就这么大，是想要更多的可交付内容，还是更多的半成品？团队一起来决策。
用户关注的是什么
对这个系统的用户而言，是质量优先，还是交付速度优先？在不同的产品形态下，取舍是不一样的。也取决于线上监控和发布形态，是否可以做到金丝雀发布？控制好问题暴发半径，也可以交付速度优先，让用户更早地体验到新功能。并不是一定需要没有缺陷了，才能交付。
质量内建如何有效落地
测试左移、质量内建是敏捷的核心之一，也是高效交付的生命线，没有质量的交付，速度越快，死得也越快。但是文化、思维的改变又不是一朝一夕的事，多数人都不太愿意走出自己的舒适区。这件事需要时间的积累、技术的改进、文化的沉淀。之前也讨论过好多次了，不再展开。
完成承诺是一种团队氛围
我们应该让团队形成一种按时保量交付的习惯，这也是质量内建的一部分。当大家都专注于完成迭代内的任务时，质量也会随之慢慢提升。每个迭代都按时完成了，团队的交付信心也会提升，对于自己的承诺，如果能够完全实现，对团队的信息是个极大的提升。反之，如果每个迭代都有未完成的 Story，大家就会慢慢习惯 Story 的不完成，那么不完成的 Story 就会越来越多，破窗效应无限被放大，进而伤害到团队。
共勉。
