某业务团队的测试人员在迭代的末期，发现还有很多缺陷未修复，原则上达不到上线要求，那么，他应该如何处理？如果你是测试负责人，要如何处理？测试人员是否需要有决定上线的权利呢？
在做质量保障体系的时候，有很多测试人员从质量的角度出发，提出了这么个问题。本文聊聊个人的理解。
这是一个复杂问题，很多东西可以算作软件的质量。
从用户界面的角度来看：它是否能便捷地引导我完成某项任务，使我更有效率且不会遇到阻碍？从可靠性的角度来看：它是否包含导致错误和崩溃的缺陷？
从架构的角度来看：源代码是否分为明确的模块，以便程序员可以轻松找到并理解本周需要处理的代码？
我们当前讲的质量基本上都是外部质量，因为那是客户最直观的感受，也愿意为更好的界面，更友好交付买单。
但是客户并不会为内部质量买单，因为他们无法感知软件内部模块化的结构，更不用说判断它的好坏。既然如此，为什么软件开发者要花时间和精力来提高软件的内部质量呢？
另外，从研发的角度上看，内部质量从长期看，会极大地提升后续的交付效率，高内部质量可以最小化技术债，使得添加新功能的工作量、时间和成本都更少。但团队往往不一定能等到那个时候，这也是为什么重构、单元测试这类的技术比较难在团队中落地的一个重要原因。
#02 为什么质量可以被取舍
项目管理的基本 4 要素：范围、时间、成本、质量。通常我们都在讨论时间、范围和成本，默认质量是必要的，但是实际上，时间和范围在多数情况下，更会被管理者或者市场固定。
传统项目中，强调的是范围固定，成本和时间是可以调整的；
在敏捷的语境下，强调交付节奏固定，范围是可以调整的；
但是现在的大多数项目，是既要也要，范围、成本、时间都是固定的！！（如果你的团队能够完善遵循某一种研发模式，也是幸福的。当然这个中的原因，有可能是领导不懂，也有可能是市场不等人，也有可能有其他的原因）
那怎么办？只能牺牲质量，否则项目就肯定崩溃。
因为，质量是可以在事后来弥补或者应对的。虽然成本可能会更高，但是相对于交付节点（市场原因、合同原因等），还是轻一些，因为如果不能按时交付，那就是 0（特别是 ToB 的业务，质量是可以通过商务解决的，但是不交付，那是不可接受的）。
当然，如果你的团队重视质量，并以质量为第一要素，那只能说恭喜你。你是幸福的。
（关于交付时间与交付质量的案例，另开文章再讨论，不在本文的讨论范围）
先说结论：哪怕给了测试这个权利，你也行使不了。
首先，测试不是质量的生产者，只是质量的监管者。测试很难从根本上去解决质量的问题，不论是左移还是自动化，都是为了更好地协助研发，提升交付质量，但不是决定性因素。
其次，权责不对等。产品能决定业务是否上线，是因为产品对最终的交付结果负责，对产品的成功失败、运营数据负责。但是没有哪个项目失败了，会说是因为测试不到位，把测试开了的。前期的产品调研、用户访谈、竞品分析等，都是产品在跟进的。所以只有产品才能决定迭代是否上线。
那么，在质量可以被取舍的情况下，测试能够做什么？
在笔者的团队中，笔者在审核测试报告的时候，非常重要的一项内容，就是风险评估。
对于测试负责人，在出具测试报告的时候，必须学会对交付的版本做对应的风险评估：
识别风险：经过这段时间的测试，现在如果发版本，会有什么样的风险？可以从质量、配置、影响范围，甚至是发展过程来识别风险；
给出可能的方案：在有效识别风险的情况下，需要给出一些解决方案，有是最好的，没有不强求。
及时上报：除了在测试报告中体现风险外，在迭代快结束的时候，是否及时把风险上报给团队负责人或者项目组，透明信息，为项目组做决策，提供依据。
识别风险，比一票否决，更能体现测试的价值。
在整体的研发过程中，其实有一个环节，测试可以做得很强势，那就是研发移测的 Showcase 环节。
在 Showcase 环节，测试可以提供 P0 级的测试用例，让开发做对应的执行并标注结果，如果测试不通过，则不允许转测。
这样做可以有效地提升研发的移测质量，保障测试活动的正常进行。同时对于研发而言，也是有利的，因为在这个时间节点修复缺陷的成本是最低的。
由于权责不对等，所以测试人员没必要强求一票否决的权利（通常也落地不了）。把更多的精力放在提升研发的移测质量上，同时在迭代后期，有效地识别出质量风险，给项目组提供决策依据，会更合理些。
共勉。
