缺陷管理:如果发现与所述测试用例无关的缺陷，我是否应该失败测试用例？

Question

我希望就处理缺陷管理时的最佳实践展开知情的讨论。作为一名测试人员，如果我正在测试一个网站并且有视觉缺陷，但是我正在测试的测试用例并不是将用户界面量化为测试的一部分。

一种选择是：

作为一名质量保证测试人员，我们忽略了我们所知道的不会被测试用例引起的缺陷就会失去完整性，仅仅因为它们没有被指定用于测试或需求的一部分。

另一种选择是：

上述元素/缺陷不在范围内，因此与我们的测试无关，从今以后票据应该通过而不是失败，因为它没有被指定。

我和我的团队正在讨论这个现实世界的问题，我很想听听其他案例和最佳实践的反馈。

Answer 1

不要忽视缺点。一定要以某种方式记录它们。

然而，从这里开始，很多事情都取决于您和您的组织是如何运作的，以及您在开发生命周期中发现这些缺陷的时间有多晚。在我的经验中，最重要的QA交付是对测试下的应用程序如何满足预期的精确描述。当我处于与您所描述的情况类似的情况时，我们通常会将不适合现有测试套件的缺陷分解为bug票。我们会将这些bug(除了通常的测试套件/结果)传达给业务和工程利益相关者。这有助于通知立即修复缺陷、最终修复或完全忽略缺陷的决定。

您还可能希望为该缺陷添加一个测试用例，如果或何时解决它！

Answer 2

对于不相关的问题(即不包括步骤)，测试不应失败。

如果您确实遇到了其他的问题，那么您需要找到一个适用的测试来覆盖它，然后失败。不过，我同意您可能会发现一些不会包含在任何测试中的内容，因此您可能需要为它编写一个非常具体的测试。

例如，假设您保存了一条记录，它成功地保存了一段时间，但是一条消息弹出了几秒钟"DEBUG1 - Saved as {GUID} to {Table}"，然后移动到正确的下一页。

您会立即想象它是由开发人员添加的，以便在检查某些内容时自己获取信息。这也绝对是个缺陷。

但是，您为该区域进行的任何测试都不太可能特别提到在保存的->下一个屏幕的状态变化之间应该没有消息。

接下来发生的事情将取决于公司和实践，就好像您是TDD一样，您可能需要为开发人员编写的测试才能工作。如果您是BDD，您可能会记录一个新的缺陷，然后意识到您还需要在工作完成后为它编写一个特定的测试用例。

无论功能如何，缺陷都应该在某个地方报告。

Answer 3

经验法则是，我们不应忽视在测试过程中发现的任何缺陷/观察。如果它与所述测试用例无关，则应在范围内找到与其相关的测试用例。与其限定测试用例，不如将重点放在限定测试周期上。

如果无法在范围中找到任何相关的测试用例，则根据测试期间的职责，选项可以是多个：

• 创建一个新的测试用例
• 更新测试用例以包括方案
• 记录意见并与利益攸关方分享

另外，感兴趣的是找到“所述元素/缺陷不在范围内，因此与我们的测试无关”的此类事件的实例，在出现多个实例时，应重新检查测试的范围。我们是在测试正确的特性集，还是需要对范围本身进行一些修改？