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