1-它使质量检查人员可以了解有关系统甚至业务领域的更多信息。示例：Web应用程序中的搜索功能不适用于一个测试数据。对于另一个测试数据，它正在工作。那么，是搜索引擎中的错误还是其他错误？从开发人员那里，我了解到索引可以简单地修复错误。在此过程中，我了解了系统以及如何触发索引。他们可以利用这些知识为其他情况提供更可靠的测试用例。
人为的示例：在网页上，单击一个按钮后，将调用一个api。在极少数情况下，api的响应会延迟，并且副作用是其他UI元素会被禁用。这些UI元素与该api调用无关，如果响应延迟，则不应禁用这些UI元素。开发人员告诉我，延迟的响应导致了问题。下次，当我进行UI测试时，我将查看是否应该模拟延迟的api响应。错误中的详细信息。
那么，质量检查人员是否应该提及导致错误的根本原因的详细信息？请也说明原因。
#1 楼
这取决于测试的类型。对于白盒测试，也许。对于黑匣子测试，不需要。黑匣子测试的全部要点是，您根据规范而不是代码进行测试。黑匣子测试仪应该不在乎为什么不满足规范，而只是不满足。而且了解内部细节实际上可能会损害黑匣子测试。负载/压力？复苏？安装？正在升级？这可以告诉您将来可能要关注的活动类型。但是，在某些事情上我会提醒您。
首先，您需要提供一致，定义明确且全面的根本原因列表；如果一个开发人员使用“并发”，另一开发人员使用“线程”，而另一开发人员使用“竞争条件”，则您不是在收集有用的数据。
其次，您需要确保根本原因就是根本原因。在您给出的案例中，我认为您列出的根本原因不是根本原因。需要索引的数据库并不是根本原因；根本原因可能是为什么未对所述数据库建立索引。否则可能会超出此范围。同样，API超时也不是该错误的根本原因。您需要查看API超时的原因。
第三，您需要确保正在使用数据，如Michael所说。
您似乎在这里将两种不同的东西混为一谈：根本原因分析和更多了解被测代码。您不必找借口来了解被测代码，也不必进行根本原因分析，除非您打算将这些信息用于某些事情。
#2 楼
测试宣言指出防止错误而不是发现错误。考虑到这一点，我认为您应该对发现的每个缺陷进行根本原因分析。然后找到一种策略或实验来防止将来发生类似的问题。根本原因要比不良测试或草率的编码要深。这背后的真正原因是什么？缺乏技能，时间压力或个人问题？问为什么至少要五次。
在您的示例中，您仍将重点放在症状上。 ？下次检查索引手册只是解决症状。我认为您缺少可复制的版本，但是为什么呢？缺少知识？为什么？
响应被延迟了，但是为什么呢？额外的测试是否可以解决真正的原因？还是我们可以在开发周期的早期阶段阻止它？
所以回答您的实际问题。是的，质量保证也应该参与根本原因的解决。不，质量保证不应仅定义根本原因。是的，我想在我们的Bug跟踪器中保留一个额外的字段，以包含根本原因分析的结果。每当发生缺陷时，我都会吸引开发人员，质量检查人员和业务利益相关者，并绘制根本原因思维图，并对问题进行更深入的分析。一起做，共享知识，在正确的水平上解决实际问题。排定时间吧，大多数RCA只需几分钟，除非它是公司的关键问题。
#3 楼
在谈论黑匣子测试时，我当然相信根本原因应该由开发团队输入。黑匣子测试人员对要测试的要求和整体功能有很好的了解。但是，因为他们将系统视为黑匣子；仅仅依靠需求。因为按照定义，黑匣子测试不需要测试人员从编码的角度深入了解实现。因此，通常情况下，项目团队会指派对要求非常透彻的测试人员，在思考可能的测试方案时会很聪明，但是这些候选人通常技术性较低（如果我们与深入研究代码的白盒测试人员进行比较）当黑盒测试人员遇到以下情况之一时，很难确定缺陷的根本原因：
设计缺陷
技术方法中的问题
/>知识不足
监督
部署问题
此外，缺陷根本原因在进行根本原因分析时是一个非常重要的领域，对确定改进的领域很有帮助。开发团队。
因此，最好是正确报告错误而不是错误报告缺陷。因为对缺陷进行RCA时会显示误导性结果。因此，为避免这种情况，最好由开发人员输入缺陷原因。
#4 楼
是的，一旦明确知道，请进行质量检查，但如果不知道，请开发人员在弄清楚后再进行质量检查。测试人员能否真正分辨出根本原因是什么？
测试人员可以访问所需资源（例如源代码）吗？
测试人员是否具有诊断故障的技术经验？问题？
是有关代码还是有关配置，数据，依赖项等的错误吗？通过QA记录当时的事实来捕捉当时的知识真是太好了。如果只有开发人员以后才知道，那么请开发人员在弄清楚后再输入。
鼓励将此作为团队合作的一部分。不管是谁找到的，都要输入信息。
回顾过去的错误和分类，向他们学习是一个好主意。您可以根据知识提出新的有用的测试。我只是将其与谁为给定票证输入详细信息的问题区分开来。将该信息传达给团队，以便他们知道捕获信息的重要性。如果您不能清楚地定义捕获它的原因以及它所带来的直接价值，那么您将遇到另一个问题。
评论
谢谢。我认为鼓励测试人员在适当的时候提出细节很重要。这很模糊，给他们留出了懒惰/冷漠的空间。我想知道有什么动机足以阻止这种情况。
– MasterJoe
17年6月23日在1:55
请参阅刚刚添加的最后一段。显示它增加的价值。
–迈克尔·杜兰特（Michael Durrant）
17年6月23日在1:56
#5 楼
我认为，对于QE来说，出于您提到的学习目的，调查根本原因非常好。学习是好的。但是，我将RCA视为一项团队运动，而不仅仅是QE责任。对于泄漏到生产中的问题，团队犯了导致该错误的错误，并且该团队错过了发布前的查找/修复。因此，团队应该回答以下两个问题：1）错误是如何引入的，2）它是如何逃逸的？
评论
只做黑匣子测试是愚蠢的。它是测试人员工具箱中的工具。如果您要求我，测试人员应在整个开发生命周期中告知质量问题。还可以帮助RCA，甚至可以触发RCA的启动。
– Niels van Reijmersdal
17年6月23日9:00
同意（从总体质量的角度来看），但是这里的问题仍然是质量保证是否应填补根本原因。上面提到的要点只是讨论为什么黑盒测试人员在填补错误的根本原因时可能会遇到问题。是的，如果团队中的测试人员对代码和设计有深入的了解，那么他们绝对可以填补错误的根本原因，甚至可以启动RCA。但是，如果对代码和设计的了解有限的人拥有分析根本原因并启动RCA的所有权，我将担心RCA的结果。
–阿拉克
17-6-23在12:16
我明白你的意思:)
– Niels van Reijmersdal
17年6月23日在13:09