如果发布后在应用程序中发现主要问题（测试逃犯）最终应该由谁/谁负责？
开发人员介绍问题？
测试人员未找到问题？开发人员和测试人员？
没有一个（是系统失败了，而不是人员）
每个人
思路？
注意：没有实际意义人员在撰写此问题时受到伤害。
#1 楼
简短的答案是“每个人”，正如其他回应中所指出的那样。 br />评论
一篇很好的文章。 “在意外情况发生时挂上责备游戏是浪费时间。”真好！
–乔·斯特拉泽（Joe Strazzere）
11年5月31日在16:22
#2 楼
在这种情况下，我不确定您所说的“负责任”是什么意思？他们的下一次年度审查谁应该采取措施来解决问题
其他
显然，开发人员和测试人员，以及几乎可以肯定其他人
测试人员应该尝试确定为什么未将其捕获到测试中（假设它实际上未被检测到，而不是被检测到但已将错误推迟） ），以及如何防止再次发生此类逃逸。测试人员还应该参与在测试环境中重现问题，并验证最终的修复方法。错误，如何解决错误以及如何防止再次发生。
管理（测试和项目管理）可能需要了解导致此缺陷逃逸的原因。进度计划激进，需求不足/不清楚，缺乏培训等，可能会或可能不会表明需要修订某些流程。
评论
+1代码并非以编码器开头，而是以测试结束。可以这么说，厨房里有很多厨师。对客户需求的理解不正确，要求低下，缺少设备/工具，硬件不明等都可能导致缺陷。使用事后调查确定漏过的内容以及原因，以便下次可以使用它。
– CKlein
2011年6月2日13:20
#3 楼
整个团队无论承担什么责任都应该承担责任。这不是“测试逃生”，而是“团队逃生”。测试不仅是一个部门，也是团队中每个人都应参与的一门学科。评论
正在投票。将责任归咎于个人至少是徒劳的，而且可能是破坏性的。而且，没有任何平凡的软件是完美的。修复错误，然后如果要分配责任，请查看您的流程并询问是否需要更改。
–user246
2011年5月31日19:32
#4 楼
正如大家所说。这就是为什么验尸很重要，很有价值的原因，以及人们在社交环境中乐于承担责任而又不怕受到指责的高沟通环境。 -将管理人员，项目经理，开发人员，测试人员，企业主等放入一个房间。头脑风暴，想出一个行动计划。由某人（可能是PM或管理层）负责实施该计划，并安排会议以在一段时间后检查进度。结果是人们因承担责任而获得荣誉，而不是因对问题负责而受到指责。如果您因负责任而受到指责，那么您的目标就是不对任何事情负责。责任真空不会产生质量。
评论
+1“如果您因负责任而受到指责，那么您的目标将是不对任何事情负责。责任的空缺不会产生质量。”喜欢这个！
– TristaanOgre
2011年5月31日20:00
#5 楼
在我工作的地方，对QA / Dev采取了非常开明的方法，实际上，我们有一份报告，详细说明了在客户站点发现的每个错误，为什么在QA中遗漏了每个错误以及正在采取哪些步骤来确保不会遗漏类似的错误。我们知道每个人都是人。如果我们希望开发人员偶尔将错误写入代码中，那么我们应该期望QA有时也会错过一个错误。这就是为什么我们报告测试覆盖率，并定期检查测试计划的原因。我们试图做的是找到导致错误逃逸的过程中发生的所有故障。通常，在同一条路径上要发生3-4次故障才能发生这种情况。然后，如果有些偶然地使用5种为什么的Kai-Zen方法来处理每个故障。
很明显，如果失败之一是报告为已完成但未真正完成的测试，我们可能需要让相关人员严厉地与之交谈。在代码中所做的更改也是如此，而没有通知质量检查人员应重新测试。可能会有所不同。
评论
对此评论+1，但您应该补充一点，如果存在测试转义，则应开除布鲁斯。
–user246
2011年5月31日19:38
@ user246大声笑...我很幸运，这只是一个假设的，引起讨论的问题，然后:-)
–布鲁斯·麦克劳德（Bruce McLeod）
2011年6月2日，下午3:12
#6 楼
以上所有内容...开发人员负责编写错误代码
测试人员负责未发现问题
谁问这个问题，以及“负责任”的目的和意义，您可以通过对测试转义的根本原因分析来获得更好的答案。不够好）或由于意外丢失而导致的错误（人为错误或自动化错误），这可以进一步划分为测试开发程序的存在和遵循（是否有明确的要求？谁审查了文档？），测试执行程序甚至工作超负荷
如果您希望继续挖掘更多内容（遵循5个Whys规则），那么就举一个覆盖范围问题为例-我们想了解谁是为什么的原因？这种情况不包括在内。是否有人审查过您的测试和测试实施？有明确的程序应审查每个测试文件吗？一个责任-上帝（没有给公司首席执行官足够的头脑去雇用一个好的测试经理）。
评论
我认为当您将“覆盖率不够好”作为基本原理时，您还需要注意计划表，有时日期是固定的，并且没有任何测试方法可以使您的所有测试都在短时间内完成。您可以尝试，但有时您必须在日期滑落的时候选择。可悲的是，这仍然是要考虑的情况。
– MichaelF
2011年6月2日，11：41
#7 楼
我讨厌对失败的反应是要找到负责任的工作场所。这并不鼓励人们提供他们所能提供的最好的服务。#8 楼
这是一个很好的问题。每个人都有责任。开发-测试-支持-UAT。除了确定谁错过了，我们还需要查看
为什么错过它
我们应该从中学到什么
它是术语重复/永久修复吗？流程变更/检查清单
对于开发人员-识别缺少的设计审查流程/单元测试用例并导致此问题
对于质量检查-知识差距/缺少测试用例/根本原因丢失的原因<我建议使用正交缺陷分类来识别阶段错误（设计/编码/代码审查更改/数据问题/集成测试问题/边界案例）。下一步是修复该阶段的流程/检查点/确定前进的课程。
这里的优点是实际阶段，该阶段还可以识别注入了错误的漏洞，并且可以在将代码部署到生产环境（UAT / Test）之前添加其他检查点以识别/发现该漏洞。
http://www.research.ibm.com/softeng/ODC/DETODC.HTM
http://www.chillarege.com/articles/odc-concept
#9 楼
我发现将责任归咎于思考是错误的方式，但回答您的问题可能是一个人或每个人。即可能是未与开发团队沟通的业务规范，也可能是没有适当测试特定COS或每个人对此事的测试人员。质量检查线索是我们可以采取的措施，以防止其再次发生。每次推出后，我们都会检查泄漏的错误并分析我们可以做些什么来防止这种情况。我们公司目前将错误归为以下类别。需求（COS）
单元测试（低级开发测试）
验收测试（COS验证）
回归测试（与QA相关的功能）
自动化测试
其他
不确定
我发现当前我们很多最近的错误都已落入回归部分。使用此模型确实帮助我们的团队分析了我们在防止错误发布方面的优缺点。
#10 楼
尽管体系结构开发人员测试技术支持团队负责泄漏的缺陷，但是大多数公司都有根深蒂固的责备测试人员的文化。我一直在不断地更改API定期进行，并且相关团队之间没有协调的沟通。测试人员不断地更改API测试框架，导致遗漏了一些导致系统集成测试中出现泄漏缺陷的场景。
RCA做得不好，我们只是发现了测试设计中的空白以及如何改进测试设计，但从未集中讨论为何在测试设计期间会错过它们。
全权负责后，我们开始为我们的测试团队设置规则。 />
所有API与它们之间的交互的功能交互矩阵
除非有已发布（经开发经理/建筑师与Test协商批准）的API /功能更改和更改应该通过单一联系点进行。
要认真进行测试审核，测试团队应该与自己以及开发人员进行更多讨论。团队了解更改背后的原因以及更改可能导致的问题类型。
评论
目前，我正在担任软件测试人员，并且我知道只有测试团队对此问题负责。但是在某处不仅有测试人员的过错，开发人员也要负责。在产品发布之前，测试和开发团队必须先对其进行正确预览，然后再继续。