在 Jira 中,如果 QA 测试人员发现开发人员实现未发布功能的方式存在问题,他们是否应该将其记录为新错误?还是让他们将问题记录为评论并重新打开问题会更好?
如果他们将其作为对现有问题的评论输入,那么在使用时间跟踪功能时,我相信您会对实际实施该问题需要多长时间有更准确的印象。另一方面,如果您创建了新的错误,那么您可以跟踪开发人员出于质量改进目的而正在处理的问题数量中生成了多少错误。
每种方法的优缺点是什么?有没有办法实现我上面概述的两个好处?
在 Jira 中,如果 QA 测试人员发现开发人员实现未发布功能的方式存在问题,他们是否应该将其记录为新错误?还是让他们将问题记录为评论并重新打开问题会更好?
如果他们将其作为对现有问题的评论输入,那么在使用时间跟踪功能时,我相信您会对实际实施该问题需要多长时间有更准确的印象。另一方面,如果您创建了新的错误,那么您可以跟踪开发人员出于质量改进目的而正在处理的问题数量中生成了多少错误。
每种方法的优缺点是什么?有没有办法实现我上面概述的两个好处?
作为开发人员,我的偏好是让测试工程师发表评论,然后尝试与我就该功能展开讨论。缺陷将是发布的有效负载上的另一项,以及需要在测试验证计划和结果中解决的另一张票。
在 Jira 中,您可以在工单中添加工作时间,以便即使在工单被标记为关闭之前可能在多个构建/发布中查看工单时也可以跟踪时间。
我赞成创建一个新问题。在许多情况下,需要重新打开错误,因为根本原因已经改变。可能开发人员做了一些假设,这些假设在新版本中不再正确,因此对原始问题的描述不再是 100% 正确。
(如果由于修复完全错误而需要重新打开错误,则必须修改测试策略。)
我已经看到了 17 次重新打开的错误。如果你打印出围绕这个 bug 的评论,你最终会得到一个超过 20 页的文档。
能够重新打开错误的另一个缺点是它使工作流程变得不必要的复杂,具有“重新打开”状态和额外的转换......
使用 JCALP 或 JCLP 之类的插件,测试人员可以直接从前一个错误中创建一个新错误。
不重新打开的一个优点是您将能够更清楚地报告某个构建
弗朗西斯
我更喜欢为发现的每个问题创建一个新问题,并将创建的问题与原始功能相关联。在这种情况下,开发人员不会丢失问题的上下文,并且有机会单独处理错误。当然,这取决于您遵循的流程,但通常情况下,在测试新功能时,QA 人员会发现不止 1 个错误,我会说更多。根据错误优先级,可以接受或重新打开该功能。另外,查看该功能,您会看到与其相关的一大堆错误。有时,即使不是所有发现的错误都在该功能投入生产之前得到修复。当然,如果发现的问题很严重,并且新功能被破坏,这意味着该功能没有完全实现,则应该重新打开它,甚至不创建新问题。