测试用例设计和测试人员，开发人员，客户的责任

Question

所以看起来好像很多人在我工作的地方玩怪游戏，这带来了一个有趣的问题。

的已知，

需求团队编写产品需求。 开发人员根据需求创建自己的单元测试。 测试团队根据要求创建测试条件，测试设计和测试用例。

当且仅当测试团队中有X％的测试用例通过时，才会发布产品。

交付后，客户进行验收测试 - ＆gt;客户响应团队从现场获取错误，并让测试团队了解这些问题。

问题：

如果客户最终提交了大量缺陷，谁应该受到指责？是不是覆盖那些的测试团队？或者是不是要求更好的要求的需求团队？如何改进系统？

Answer 1

声明“当且仅当测试团队的X％测试用例通过时，产品才被发布”真的让我烦恼。团队可能希望考虑更好的发布标准，这些标准不仅仅是测试通过率。例如，已知，理解，考虑（和测试）的场景？当然不是所有的错误都会被修复，但被推迟或未被修复的错误是否正确分类？您是否达到了压力测试和性能目标？您是否对威胁进行了建模并将其作为缓解潜在威胁的原因？是否有x个客户（内部/外部）部署构建并在发布之前提供反馈（即“dogfood”）？开发人员是否了解来自现场和测试人员的错误以创建回归单元测试？需求团队是否了解这些错误，以了解为什么不考虑这些方案？在规范，开发或测试中没有考虑的功能之间是否存在关键的集成点？

对团队的一些建议是首先对发现的问题进行事后检查并了解其中断的位置，并努力尽可能地推动上游质量。确保需求团队，开发人员和测试人员在整个规划，开发和测试周期中经常进行通信，以确保每个人都在同一页面上并知道谁在做什么。当人们在开发过程中实际交谈时，您会惊讶于可以获得多少产品质量！

Answer 2

错误可以在需求和开发步骤中进入系统。需求团队在创建需求时可能会犯一些错误或过度简化假设，开发人员可能会误解需求或做出自己的假设。

为了改善目标，客户应在开发进行之前签署要求，并且至少在某种程度上应该参与监控开发以确保事情走上正轨。

Answer 3

我脑海中的第一个问题是，“缺陷如何与需求相悖？”

如果要求显示“OK按钮应为蓝色”且缺陷为“OK按钮为绿色”，我会责怪开发和测试 - 显然，都没有阅读要求。另一方面，如果投诉是“确定按钮不是黄色”，显然，需求收集或更改控制过程存在问题。

这个问题没有简单的答案。系统可能存在大量缺陷，责任在参与流程的每个人之间传播 - 毕竟，“缺陷”只是说“未满足的客户期望”的另一种方式。期望本身并不总是正确的。

Answer 4

“当且仅当测试团队中有X％的测试用例通过时才发布产品” - 是发布的标准之一。在这种情况下，书面TC中的“测试覆盖率”非常重要。无论是否遗漏任何功能或情况，都需要对TC进行良好的审核。如果在TC中遗漏了任何内容，可能会发现错误，因为测试用例中没有涉及某些要求。

它还需要一些临时测试以及探索性测试来发现TC中的发现错误。它还需要定义“退出标准”进行测试。

如果客户/客户发现任何错误/缺陷，则需要调查：i）发现了哪种类型的错误？ ii）是否有关于此的书面测试案例？ iii）如果有关于正确执行的测试用例？ iv）如果TC缺席，为什么错过了？等等

经过调查决定可以采取谁应该受到指责。如果它是非常简单和睁大眼睛的bug /缺陷，肯定应该责怪测试者。