目录
翻译内容
Summary(摘要)
When can a bug report be considered redundant because it is already reported in the bug management system? If you ask the developers, if two bugs are caused by the same mistake in the code, it’s enough to report one of them. But Michael Stahl has good arguments from a tester's perspective about why it's better to err on the side of over-reporting bugs.
何时可以将缺陷报告视为冗余，是因为它已在缺陷管理系统中了吗？ 如果你问开发人员，如果代码中出现同样的错误导致两个错误，那么报告其中一个错误就足够了。 但迈克尔斯塔尔从测试人员的观点中得到了很好的论据，即为什么在过度报告缺陷方面更好。
正文内容
I once asked an acquaintance, a math professor, what he did to get his PhD. 我曾经问过一位熟人，一位数学教授，他做了什么才能获得博士学位。
“They gave me a problem to solve,” he said. “他们给了我一个需要解决的问题，”他说。
“And?” I asked. “接着呢？”我问道。
His answer: “It is not a problem anymore.” 他的回答是：“这不再是问题了。”
In software testing, there are a good number of topics that can be considered solved when there is a well-known and commonly accepted way to deal with them. One such example is bug management.
在软件测试中，有许多主题可以考虑解决，并且存在众所周知且通常被接受的处理方式来处理它们。 一个这样的例子是bug管理。
In theory, it’s a clear-cut process: There is a triage meeting attended by development, the validation project manager, and other interested parties. Bug reports are checked to include a clear description, logs, screenshots as needed, and a reasonable description of how to reproduce the bug. Next, there is a discussion about the bug severity. Sometimes it’s an easy call, and sometimes it’s complicated and requires deep understanding of the underlying technology. It’s common to have arguments—possibly heated ones—about the severity of a certain bug. As the release date approaches, a fair amount of politics play a role as well. Once the severity is agreed upon, the priority is set: Do we fix the bug right away, or can it wait? Here, too, there is an opportunity for arguments. But generally speaking, the process is clear and mostly works.
从理论上讲，这是一个明确的过程：有一个由开发人员，验证项目经理和其他相关方参加的分类会议。 检查bug报告是否包括清晰的描述，日志，根据需要的屏幕截图以及如何重现bug的合理描述。 接下来，讨论bug的严重性。 有时这是一个简单的调用，有时它很复杂，需要深入了解底层技术。 关于某个bug的严重性，通常会有一些争论 - 可能是激烈的争论。 随着发布日期临近，相当数量的“政见”也发挥了作用。 一旦确定了严重性，就会设置优先级：我们是否立即修复bug，还是可以延期？ 在这里，也有机会争论。 但总的来说，这个过程很明确，而且大部分都有效。
Consequently, I am repeatedly surprised by how specific aspects of the process never seem to have been fully agreed on and are still a contentious point, even though they should have moved to the “not a problem anymore” category a long time ago.
因此，我一再感到惊讶的是，这个过程的具体方面似乎从来没有完全达成一致，并且仍然是一个有争议的问题，即使他们很久以前应该已经转移到“不再是问题”的类别了。
One such aspect is the question of duplicate bugs. Specifically, when can a bug report be considered redundant because it is already reported in the bug management system? In such a case, the new report is superfluous, does not merit any discussion, and can be closed right away.
一个这样的方面是重复bug的问题。 具体来说，什么时候可以将bug报告视为冗余，因为它已经在bug管理系统中报告了？ 在这种情况下，新报告是多余的，不值得任何讨论，可以立即关闭。
A bug marked as a duplicate is perceived as a black eye to validation (and it should be seen this way!). It means the validation team is unprofessional: The tester should check in the bug reporting system whether the bug is already reported and refrain from adding “noise” to the data by repeating the reporting of the same bug. That’s why validation opposes marking a bug as duplicate and looks for justification for the new bug. Development, on the other hand, wants to minimize the number of open bugs, so closing a bug without having to work on it is a good thing. Disagreement flourishes, and the bug triage meeting turns into an ineffective quarrel.
标记为重复的bug被视为验证的黑眼圈（应该以这种方式看待它！）。 这意味着验证团队不专业：测试人员应该检查bug报告系统是否已经报告了这个bug，并且不要通过重复报告相同的bug来向数据添加“噪音”。 这就是为什么验证人员反对将bug标记为重复并寻找新bug的证据。 另一方面，开发人员希望最大限度地减少未修复状态bug的数量，因此关闭bug而不必处理它是一件好事。 分歧越来越大，错误分析会议变成了无效的争吵。
When should we consider a bug a duplicate? 我们什么时候应该将bug视为重复？
It depends, of course, on whom you ask. If you ask the developers, if two bugs are caused by the same mistake in the code, it’s enough to report them once. The second bug will be fixed when the first bug is fixed. As the developers see it (and many times the project manager thinks so, as well), the claim that in this case both bugs are valid distorts the information we have about the quality of the code.
当然，这取决于你问谁。 如果您询问开发人员，如果代码中的同一个错误导致两个bug，则只需报告一次。 修复第一个bug时，第二个bug也会被修复。 正如开发人员所看到的那样（并且很多时候项目经理都这么认为），在这种情况下，两个bug都是有效的，会扭曲我们对代码质量的看法。
Here is a convincing example (if you are a developer): Assume you have an application for storing and reporting students’ grades. The code for extracting grades from the database uses the student’s Social Security number (SSN) to identify the student. The application allows the student to identify themselves using a variety of methods in addition to the SSN: full name, security PIN, cellphone number, and credit card number. In the first stage, the application uses the identifying information to extract the SSN from the student’s personal record. Then the SSN is used to extract the grades. (All you database experts out there who are actively pulling your hair out, crying, “This is not how it’s done!” Chill! I said assume.)
这是一个令人信服的例子（如果您是开发人员）：假设您有一个存储和报告学生成绩的应用程序。 从数据库中提取成绩的代码使用学生的社会安全号码（SSN）来识别学生。 该应用程序允许学生使用除SSN之外的各种方法来识别自己：全名，安全密码，手机号码和信用卡号。 在第一阶段，应用程序使用识别信息从学生的个人记录中提取SSN。 然后SSN用于提取成绩。 （所有你在那里的数据库专家都在积极地拔掉你的头发，哭了，“它不是这么做的！”寒冷！我说假设。）
Five test cases were defined at the system test level. Each test case checks the ability to extract grades using a different identification method. Now, what happens if there is regression in the code that extracts the grades from the second table? All five test cases will fail!
在系统测试级别定义了五个测试用例。 每个测试用例都使用不同的识别方法检查提取成绩的能力。 现在，如果代码中存在从第二个表中提取成绩的回归，会发生什么？ 所有五个测试用例都将失败！
What’s the quality level of the code in this case? If we report five bugs, we pass a message that the grade-extract module is in severe regression, and it may have a serious impact on the project. But this is obviously incorrect. There is only one error in the code, and the whole thing will probably be solved in half a day, including pre-check-in tests.
在这种情况下，代码的质量水平是多少？ 如果我们报告五个bug，我们会传递一个信息，即成绩提取模块处于严重回归问题，并且可能会对项目产生严重影响。 但这显然是不正确的。 代码中只有一个错误，整个过程可能会在半天内解决，包括预登记测试。
So there is a good argument why four out of the five bugs are duplicates. But here is the counter argument.
所以有一个很好的论据，为什么五个bug中有四个是重复的。 但这是反驳论点。
How confident can we be that the reason for all five failures is the same one? Indeed, in the example given here, it makes a lot of sense. But between us testers: If they messed up the grades extract code, maybe they also messed up the SSN extraction. I have full confidence in the developers. I am sure they know how to create two bugs in one release!
我们有多少信心，所有五次失败的原因都是一样的？ 实际上，在这里给出的例子中，它很有意义。 但是我们之间的测试者：如果他们搞砸了成绩提取代码，也许他们也搞砸了SSN提取。 我对开发人员充满信心。 我相信他们知道如何在一个版本中创建两个bug！
If we close four of the bugs as duplicate, it may be that only one error will be fixed. The other error will have to wait to be found until we run the tests again. Because no bug was opened against those test cases, we won’t be doing confirmation tests. If the grade-extraction tests are low-priority test cases, it may take quite a while until we run them again. For all we know, we may never run them again before the product is released (at which point, Murphy says, the bug will appear immediately).
如果我们将四个bug视为重复，并将其关闭，则可能只会修复一个错误。 另一个错误必须一直等待着，直到我们再次运行测试。 因为没有针对这些测试用例新建bug，所以我们不会进行确认测试。 如果成绩提取测试是低优先级的测试，则可能需要一段时间才能再次运行它们。 据我们所知，在产品发布之前，我们可能永远不会再次运行它们（此时，Murphy说，这个bug会立即出现）。
My position is that testers need to report what happened. Why it happened—the root cause—is irrelevant when we discuss bug reporting. The developer’s claim of duplicity relies on the assumption that what happened at the system level and why it happened at the code level are the same for all bugs. The counterclaim of the testers is that what we did at the system level is different.
我的立场是测试人员需要报告发生的事情。 当我们讨论bug报告时，为什么它会发生 - 根本原因 - 是不相关的。 开发人员声称的双重性依赖于这样的假设，即在系统级别发生的事情及其在代码级别发生的原因对于所有的bug都是相同的。 测试人员的反诉是关于我们在系统级别所做的不同行为。
I maintain that a bug should be considered a duplicate if and only if both the action done and the erroneous result are the same.
我认为，当且仅当完成的操作和错误的结果均是相同时，才应将bug视为是重复的。
ps: 个人比较认同作者的观点。 对bug的操作上，当且仅当完成的操作和错误的结果均是相同时， reopen一个bug；否则就新建一个bug。
Here’s another tell-tale sign when a bug is not a duplicate. Usually, a duplicate bug is reported when two testers identified the same problem and both reported it without first checking if it’s already in the system. It is therefore reasonable to say, with high level of confidence, that when both bugs were open by the same tester, it is not a duplicate. Why would the same tester report the same issue twice? It just adds extra work for the tester, who for sure remembers the first report. Clearly, the manifestation of the bug, either what we did or what happened, is not exactly the same—even if the developers think it is.
当bug不是重复bug时，这是另一个信号。 通常，这种情况下一个重复bug会被记录下来，即当两个测试人员发现相同问题，并且两者都没有先检查它是否已经在系统中时。 因此，有充分的信心可以说，当两个bug都是由同一个测试人员打开时，它不是重复的。 为什么同一个测试人员会报告两次相同的问题？ 它如果只是增加了测试人员额外的工作，那么测试人员肯定会记住第一份报告。 很明显，无论是我们做了什么还是发生了什么，这个bug的表现都不是完全相同的 - 即使开发人员认为它是如此。
It’s important to have a discussion about this topic, detached from a specific case, and arrive at an agreement with the involved parties about when a bug should be considered a duplicate. First, it will avoid repeating discussions in bug triage, but more than this, it will prevent negative phenomena that happen when there is a strong tendency to mark bugs as duplicates. I experienced two such phenomena:
重要的是讨论这个主题，脱离特定案例，与相关方达成协议，了解何时应将缺陷视为重复。 首先，它将避免在缺陷分类中重复讨论，但更重要的是，它将防止如将缺陷重复标记为的的负面现象。 我遇到过两种这样的现象：
- Testers decide not to report some incidents, because “it will be closed as a duplicate anyway” 测试人员决定不报告某些事情，因为“无论如何它都会被当做重复关闭”
- Testers take this attitude further: When they encounter a bug and think they understand its overall influence on the code behavior, they don’t open bugs on errors they conclude are a result of the first issue, even when the new bugs’ manifestation is totally different than in the first bug 测试人员进一步有这种态度：当他们遇到缺陷并认为他们理解其对代码行为的整体影响时，他们不会打开包含第一个问题结果的bug，即使新bug的表现完全是与第一个bug不同
It’s better to be skeptic and picky in tagging bugs as duplicates. The damage caused by a few duplicate bugs is lower than the damage caused by unreported bugs. It is better to err on the over-reporting side.
在将缺陷标记为重复时，最好抱着怀疑和挑剔的态度。 一些重复的缺陷造成的损害低于未报告的缺陷造成的损害。 最好在过度报告方面犯错。
Whenever a bug is encountered, if it is not exactly the same as a previously reported bug, create a new report. If indeed both are caused by one error, the developers got one for the price of two. What is important to do in such a case, though, is to link the bugs in the bug-reporting system (most systems support such linking). This will tell the developers you think these two bugs may be related or are possibly a different manifestation of the same error. But links are not enough—developers tend to miss them. Write clearly in the text description of both bugs, “It is possible that this bug is caused by the same root cause of bug X, linked to this bug.”
每当遇到bug时，如果它与之前报告的bug不完全相同，请创建一个新报告。 如果确实两者都是由一个错误引起的，那么开发人员解决了一个，也就同时解决了另一个。 但是，在这种情况下，重要的是在bug系统中链接bug（大多数系统支持这种链接）。 这将告诉开发人员，您认为这两个可能bug是相关的，或者可能是同一错误的不同表现形式。 但仅仅链接还是不够的 - 开发人员往往会错过它们。 在两个bug的文本描述中写清楚，“这个bug可能是由与之链接的bug X的根本原因相同。”
关于作者
Michael Stahl
Michael Stahl is a SW Validation Architect at Intel. In this role, he defines testing strategies and work methodologies for test teams, and sometimes even gets to test something himself - which he enjoys most. Michael presented papers in SIGiST Israel, STARWest, EuroStar and other international conferences, and is teaching SW Testing in the Hebrew University in Jerusalem. Before starting his career in testing in 2000, Michael worked at Intel’s manufacturing facility in Jerusalem, Israel, as a chip-level test engineer.
Michael is an executive board member of the Israeli Test Certification Board (ITCB), holds a full Advanced ISTQB Certification, and chairs ITCB’s advisory board. Some of Michael's presentations and papers are available on www.testprincipia.com.
Michael Stahl是英特尔的软件验证架构师。 在这个角色中，他为测试团队定义了测试策略和工作方法，有时甚至可以自己测试一些东西 - 这是他最喜欢的。 Michael在SIGiST Israel，STARWest，EuroStar和其他国际会议上发表论文，并在耶路撒冷的希伯来大学教授SW测试。 在2000年开始测试之前，Michael曾在以色列耶路撒冷的英特尔制造工厂担任芯片级测试工程师。
Michael是以色列测试认证委员会（ITCB）的执行董事会成员，拥有完整的ISTQB高级认证，并担任ITCB顾问委员会主席。 迈克尔的一些演讲和论文可在www.testprincipia.com上找到。
原链接
https://www.stickyminds.com/article/when-testers-should-consider-bug-duplicate
扫一扫
605
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
