Jira 对问题发表评论或创建新错误？
在 Jira 中，如果 QA 测试人员发现开发人员实现未发布功能的方式存在问题，他们是否应该将其记录为新错误？或者他们最好将问题记为评论并重新打开问题？
如果他们将其输入为对现有问题的评论，那么在使用时间跟踪功能时，我相信您会对该问题实际实施所需的时间有更准确的印象。另一方面，如果您创建了新的错误，那么您可以跟踪开发人员为提高质量而正在处理的问题数量所产生的错误数量。
每种方法的优点和缺点是什么？有没有办法同时实现我上面概述的两个好处？
In Jira, if a Q.A. tester finds a problem with the way a developer has implemented an unreleased feature, should they be logging that as a new bug? Or is it better for them to note the problems as a comment and re-open the issue?
If they enter it as a comment on the existing issue, then when using the time-tracking features I believe you would have a more accurate impression of how long that issue actually took to implement. On the other hand, if you create new bugs then you can track how many bugs developers are generating for the number of issues they're working on for quality improvement purposes.
What are the pros and cons to each approach? Is there a way to achieve both of the benefits I outlined above?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我赞成创建一个新问题。
在许多情况下，由于根本原因已经改变，因此需要重新打开错误。开发人员可能做出了许多假设，但在新版本中这些假设不再正确，因此原始问题的描述不再 100% 正确。
（如果由于修复完全错误而需要重新打开错误，则必须修改测试策略。）
我见过重新打开 17 次的错误。如果你打印出围绕这个 bug 所做的评论，你最终会得到一份超过 20 页的文档。
能够重新打开错误的另一个缺点是，它使工作流程变得不必要的复杂，具有“重新打开”状态和额外的转换......
使用 JCALP 或 JCLP 等插件，测试人员可以轻松地创建新的错误上一个。
不重新开放的一个优点是您将能够更清楚地报告
特定版本
Francis
I'm in favor of creating a new issue.
In many cases a bug needs to be reopened cause the root cause has changed. Probably the developer made a number of assumptions which aren't true anymore in a new version, so the description of the original issue is not 100% correct anymore.
(If the bug needs to be reopened cause the fix is plain wrong, test strategy must be revised.)
I've seen bugs that were reopened 17 times. If you print out the comments made around this bug, you would end up with a document of more than 20 pages.
Another drawback of being able to reopen a bug is that it makes the workflow unnecessary complex, with a 'Reopened' state and additional transitions ...
Using plugins like JCALP or JCLP, it is straightforward for the tester to create a new bug out of the previous one.
An advantage of not reopening is that you will be able to report more clearly on
a certain build
Francis
作为开发人员，我的偏好是让测试工程师发表评论，然后尝试与我就该功能进行讨论。缺陷将是发布有效负载上的一项又一项，以及需要在测试验证计划和结果中解决的另一项票证。
在 Jira 中，您可以添加工单中的工作时间，这样即使在工单标记为关闭之前可能在多个构建/版本中查看工单，也可以跟踪时间。
My preference as a developer is to have the test engineer had a comment and then attempt to open a discussion with me about the feature. A defect would be one more item on the payload for the release and one more ticket that will require to be addressed in testing verification plan and results.
In Jira, you can add time worked in a ticket so the time can be tracked even when the ticket maybe be looked in several builds/releases before it is marked closed.
我更喜欢为每个发现的问题创建一个新问题，并将创建的问题与原始功能相关联。在这种情况下，开发人员不会失去问题的背景，并且有机会单独处理错误。当然，这取决于您所遵循的流程，但通常情况下，在测试新功能时，QA 人员会发现不止 1 个错误，我想说，更多。根据 bug 优先级，该功能可以被接受或重新开放。另外，查看该功能，您会看到与之相关的一大堆错误。有时，甚至在该功能投入生产之前，并非所有发现的错误都得到修复。当然，如果发现的问题很严重，并且新功能被破坏，这意味着该功能没有完全实现，则应该重新打开它，甚至不需要创建新问题。
I prefer to create a new issue for each problem found, and relate the issues created to original feature. In this case, developer is not loosing the context of the problem and has a chance to work on the bugs separately. Of course, it depends on the process you're following, but normally, while testing new feature QA person finds more than 1 bug, I would say, much more. According to the bug Priority, the feature can be accepted or reopened. Plus, looking at the feature, you see the whole bunch of bugs related to it.Sometimes, even not all found bugs are fixed before the feature goes to production. Of course, if the found problem is critical, and new functionality is broken, which means that the feature is not implemented completely, it should be reopened, without even creating a new issue.