问如果测试人员不能在产品中找到好的缺陷，他们应该做些什么？

EN

测试不再意味着测试混乱？我们可以想象！测试的目的过去是相当明确的--“测试是为了查找错误而执行程序的过程”。这在采用敏捷和精益开发时发生了变化。多读点...

我认为测试宣言的结尾是正确的。专注于防止缺陷，而不是发现缺陷。如果缺陷确实到达生产阶段，请执行根源分析并防止今后发生类似的缺陷。

读取

• https://less.works/less/technical-excellence/thinking-about-testing.html
• https://moreagiletestingmanifesto.wordpress.com/2015/08/02/agile-testing-manifesto/
• http://www.jamesshore.com/Agile-Book/root_原因_analysis.html
• http://moderntesting.org

我想谈谈问题的报告方面。你说..。

我只是继续编写优秀的测试用例并执行它们，但之后我没有任何东西可以向管理层展示。有时它让我觉得我没有为这个产品提供任何价值。

即使在完美的世界里，软件让开发人员的手100%免费并完成功能(作为开发人员："HAHAHAHAHAHAHAHAHAHAHA")，这是完全不正确的。是的，当你在第11小时发现一个关键任务错误的时候，那真是太棒了，你就是英雄。但是，当您执行所有优秀的测试用例并且没有发现任何缺陷时，您已经产生了同等或更有价值的东西。这是质量保证。

在我为"Tester“工作的公司里，”Tester“是个下流词。相反，我们有"QA“小组。这是因为企业并没有真正从测试和修复bug中获益。企业甚至没有从没有bug的代码中真正受益。不，企业需要知道它有无bug的代码。我曾在没有达到这一需求的环境中工作过，而且企业对其产品没有信心。在这种环境下，一切都会分崩离析。

• 您无法自信地估计新特性所涉及的工作。因为一个bug可能就隐藏在关键组件的表面下。
• 您无法有效地测试更改集。因为没有置信度的基线，每个测试都必须是完全回归测试。
• 你不能把你的产品卖给真正的买家，因为当他们问“它能做XYZ吗？”你的工程师说“理论上。”

我得到的是，在每个开发周期结束时，您向管理层提交的任何报告的头版不应该是关于软件失败的地方：

**Defects Found**
BUG-1: $0.01 of every transaction is transferred to Joe A.'s offshore account.
BUG-2: Rounding error when withdrawing from an ATM on Tuesday.

相反，真正重要的是你已经证明了软件能做什么。而且能做正确的事。公开的缺陷是本报告的一部分，是的。但它们并不是真正重要的东西。真正重要的是：

**Features Verified**
Can open a new account           [PASSED]
Can close an existing account    [PASSED]
Can issue a transaction          [FAILED, BUG-1]
Can withdraw from a bank         [PASSED]
Can withdraw from a ATM          [FAILED, BUG-2]

然后，在臭虫被解决之后。您发布的QA报告如下所示：

**Features Verified**
Can open a new account           [PASSED]
Can close an existing account    [PASSED]
Can issue a transaction          [PASSED]
Can withdraw from a bank         [PASSED]
Can withdraw from a ATM          [BACKLOGGED]

这是管理层应该想看到的文件。

我的测试座右铭一直是这样。“测试的目的是减少实施的风险。”我总是发现，当一个测试组织仅仅根据发现的bug数量进行分级时，它是非常不准确的。如果你发现了大量的bug，是因为你很棒，还是你的开发人员那么糟糕。或者在您的情况下，如果测试没有发现bug，是因为测试不好(在您的情况下不是这样)，或者您的开发人员是那么好(听起来像您的案例)。

当您需要担心的是，如果您在测试过程中没有发现任何问题，但是在生产过程中会发现问题。只要最终用户没有发现您的测试团队没有发现的缺陷，那么听起来您做得很好。

此时您可以做的另一件事是增强您的测试。您是否尝试过寻找可以改进应用程序的地方？