所以似乎很多人都在我工作的地方玩指责游戏，这提出了一个有趣的问题。
已知：
需求团队编写产品需求。开发人员根据需求创建自己的单元测试。测试团队根据需求创建测试条件、测试设计和测试用例。
当且仅当来自测试团队的 X% 的测试用例通过时，产品才会发布。
交付后客户进行验收测试 --> 客户响应团队从现场获取错误，并让测试团队了解这些问题。
问题：
如果客户最终提交了很多缺陷，那么该怪谁？是测试团队没有涵盖这些吗？还是需求团队没有写出更好的需求？以及如何改进系统？
问问题
1481 次
4 回答
3
“当且仅当来自测试团队的 X% 的测试用例通过时，产品才发布”这句话真的让我很困扰。团队可能想要考虑制定更好的发布标准，而不仅仅是测试通过率。例如，场景是否已知、理解、说明（和测试）？当然不是所有的错误都会被修复，但是那些被推迟或没有被修复的错误是否被正确分类？您是否达到了压力测试和性能目标？您是否对威胁进行了建模并考虑了对潜在威胁的缓解措施？有 x 数量的客户（内部/外部）部署构建并在发布前提供反馈（即“dogfood” )? 开发人员是否了解来自现场和测试人员的错误以创建回归单元测试？需求团队是否了解这些出现的错误以了解为什么没有考虑这些场景？在规范、开发或测试中没有考虑到的特性之间是否存在关键集成点？
对团队的一些建议是首先对发现的问题进行事后分析，并了解问题出在哪里，并尽可能将质量推向上游。确保需求团队、开发人员和测试人员在整个规划、开发和测试周期中经常和良好地沟通，以确保每个人都在同一页面上并且知道谁在做什么。当人们在开发过程中真正互相交谈时，您会惊讶于产品质量可以提高多少！
于 2010-03-27T03:38:07.780 回答
0
错误可以在需求和开发步骤中进入系统。需求团队在创建需求时可能会犯一些错误或过度简化假设，而开发人员可能会误解需求或做出自己的假设。
为了改进事情，客户应该在开发开始之前签署需求，并且应该至少在某种程度上参与监控开发以确保事情在正确的轨道上。
于 2010-03-27T03:28:47.053 回答
0
我脑海中的第一个问题是，“缺陷是如何与需求相叠加的？”
如果需求是“确定按钮应该是蓝色的”而缺陷是“确定按钮是绿色的”，我会责怪开发和测试——显然，既不阅读需求。另一方面，如果投诉是“确定按钮不是黄色的”，那么显然，需求收集或变更控制过程存在问题。
这个问题没有简单的答案。一个系统可能存在大量缺陷，责任分散在流程中的每个人之间——毕竟，“缺陷”只是“未满足客户期望”的另一种说法。期望本身并不总是正确的。
于 2010-03-27T03:40:21.207 回答
0
“当且仅当来自测试团队的 X% 的测试用例通过时才发布产品” - 是发布的标准之一。在这种情况下，书面 TC 中的“测试覆盖率”非常重要。无论是否遗漏了任何功能或场景，都需要对 TC 进行良好的审查。如果 TC 中遗漏了任何内容，则可能会发现错误，因为测试用例中未涵盖某些要求。
它还需要一些临时测试以及探索性测试来发现 TC 中的错误。并且它还需要为测试定义“退出标准”。
如果客户/客户发现任何错误/缺陷，则有必要进行如下调查： i) 发现了什么类型的错误？ii) 是否有任何关于此的测试用例？iii) 是否有关于正确执行的测试用例？iv) 如果 TC 中没有它，为什么会错过它？等等
After investigation decision can be taken who should be blamed. If it is very simple and open-eyed bug/defect, definitely testers should be blamed.
于 2013-05-07T12:45:06.290 回答