如何建立对逃逸错误的更好跟踪？

#1 楼

这是与流程相关的-作为常规的质量检查测试人员您无法解决。 。
错误跟踪器只是其中一部分。但是作为质量检查人员，您不能让开发人员在跟踪程序中输入错误或执行任何操作-只有他们自己的经理才能做到这一点，并且只有当他/他将在改进的流程中看到任何价值时。要么与开发经理一起，要么由他们两个以上的高级老板来做。
您需要更好的论据，即“您只是想知道自己是否错过了什么”。您（或更好的是质量检查经理）需要说明建立这样的流程将如何使整个公司受益，如何提高产品质量和整体客户体验，而不仅仅是解决质量检查方面的问题。您要达到的目标是，您提出的建议被认为是行业标准的最佳做法：-)
关于客户对Bug跟踪器的访问权限：您应该跟踪客户的反馈，但不能在Bug跟踪器中跟踪。不要将跟踪错误，伪造，阻止程序等的内容分给客户。客户不会也不应在意您的内部流程。使用单独的反馈跟踪器。在与反馈相关的错误中（其描述比所提供的用户更好，这是您的研究结果），请提及相关反馈。或多次反馈（如果报告多次）。

#2 楼

理想情况下，当最终用户发现错误测试人员团队时，应先通知开发人员。然后交给开发人员，因为要归咎于测试人员留下的错误:-)。您应该做出一些安排，使用户不要直接向开发人员报告。他们首先向测试人员咨询开放的错误。然后测试人员显然会在开发人员之前得到通知。

#3 楼

有人需要将这些错误输入到错误跟踪系统中。如果用户不能/不可以，则必须由某人代表他们这样做。

在编写错误报告之前，开发人员不应该对问题采取行动。

如果有帮助台，则帮助台应代表用户输入错误报告。如果没有帮助台，则开发人员应输入这些错误报告。而且，如果其他所有操作均失败，则应将此问题传递给质量检查人员以撰写错误报告。

做任何事情都不是愚蠢的。管理层应该教育人们正确地报告错误。

#4 楼

在质量保证服务中，跟踪遗漏的需求和客户问题是确保团队内部未来流程改进的因素之一。此外，只有当团队拥有一个项目中所有QA / Dev / Product团队等都可以使用的缺陷报告工具时，才可以有效地跟踪缺陷。
软件质量保证公司通常遵循分析发布的标准并在实时环境中创建客户面临的问题列表，也称为发布后缺陷。
在发布后缺陷分析中，跟踪客户缺陷并与其他团队共享以进行进一步检查，以及基于发现过程的信息，可以改进以供将来发布。
可以轻松识别和跟踪需求遗漏或QA遗漏。
要管理需求遗漏问题：

在功能开发之前或期间，质量检查团队可以从最终用户的角度开始审查功能要求
，并相应地更新开发人员/产品团队。

对于质量检查遗漏问题：

质量检查小组可以采取协作措施避免发生这种情况。

P ost-release缺陷分析是团队的工作。它可以由开发团队或质量保证团队执行，然后在与团队进行回顾会议期间通过电子邮件或讨论共享报告。

#5 楼

因此，我们在客户中遇到了这个问题，但是我们有一个平台可以报告这些实时问题。然后将其转发给质量检查人员进行复制。完成后，他们将其登录到我们使用Kualitee的测试管理工具中，并将其分配给开发团队。它具有一个独立的问题跟踪模块。
然后无论发生什么通信，它都在工具上，并自动向缺陷查看者发送电子邮件通知。

#6 楼

用户不应直接与开发人员进行交互。应该有一个平台，用户可以在该平台上记录他们的投诉。这可以是基于Web的记录器或客户投诉代理。测试团队的人应该将该投诉从用户语言转换为正式的错误报告。
之后，可以将其视为普通的错误：修复，非错误等。
测试团队还应该对其进行审查，以查看测试团队是否应该抓住它。如果是，那么他们应该将其合并到测试用例存储库中以用于将来的测试。 TFS非常广泛，但有时可能会变得僵化。如果您遇到这样的挑战，可以尝试使用Kualitee。我们一直在使用该工具，并且对于此类用例非常有用。

#7 楼

其他答案似乎只有一半。
最大的改进是：

安装了公司同意的错误跟踪系统；
质量保证开始使用它并添加所有出现的错误和问题。

然后是每周工作报告，以促使开发人员采取行动并修复错误。否则，管理层将每周看到越来越多的老错误，而且前景并不光明。
如果开发人员由于质量检查未报告而没有修复这些错误，那完全是质量检查的错。因此，对于质量检查人员而言，开始使用错误跟踪软件至关重要。
换句话说，质量检查人员要么是问题的根源，要么是解决方案的根源-取决于他们是否隐藏问题或报告问题。

注意：理想情况下，在“逃逸”到生产环境之前，已发现并报告了错误。但是，即使在“转义”之后，也必须记录并跟踪错误。实际上，逃逸的bug应该具有更高的优先级，因为它们已经（潜在地）对客户可见。