问测试用例设计与测试人员、开发人员、客户的责任

EN

“产品发布当且仅当测试团队测试用例的X%通过”这句话真的让我感到困扰。团队可能想要考虑有更好的发布标准，而不仅仅是测试通过率。例如，这些场景是否已知、理解、考虑(和测试)？当然，并不是所有的错误都会被修复，但是那些已经被推迟或者没有修复的错误是否被正确地重新分类了呢？你是否达到了压力测试和性能目标？您是否建立了威胁模型，并对潜在威胁进行了评估？在发布之前，是否有x个客户(内部/外部)部署了构建并提供了反馈(即“狗食”)？开发人员是否了解来自领域的bug和测试人员创建回归单元测试的方法？需求团队是否理解这些bug，以了解为什么没有考虑到这些场景？在规范、开发或测试中没有考虑到的特性之间是否存在关键的集成点？

给团队的一些建议是，首先对发现的问题进行一次事后分析，并了解它的故障所在，并尽可能地将质量推向上游。确保需求团队、开发人员和测试人员在整个计划、开发和测试周期中进行频繁和良好的交流，以确保每个人都在同一个页面上，并且知道谁在做什么。当人们在开发过程中互相交谈时，你会惊讶于产品质量的提高。

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

为了改进事情，客户应该在开发开始之前签署需求，并且至少在某种程度上参与监视开发，以确保事情走上正确的轨道。

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

如果需求是"OK按钮应该是蓝色的“，而缺陷是"OK按钮是绿色的”，我会责怪开发和测试--很明显，两者都没有读取需求。另一方面，如果投诉是"OK按钮不是黄色的“，很明显，需求收集或更改控制过程存在问题。

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