（来自“测试人员故事周期” ）大家好 您可能已经注意到，OTUS中开设课程的强度每个月都在增加，3月份特别多。 今天，我们希望与3月中旬开始的
“网络测试自动化”课程的启动相吻合。 好好阅读。
我仍然看到许多测试人员谈论发现的错误和漏洞的数量，以此来衡量测试是否成功。 最近，我看到了另一种观点，该观点指出，本质实际上是错误的质量，而不是错误的数量。 但是，采用此措施也值得谨慎。 现在，我们将讨论这一点。
主要思想是测试方法由您需要查找的错误类型决定。
在较早的
Bug搜寻对话中，我已经谈到了今天主题的某些方面。 我不想重复自己，所以我会尽量简短。 我将把我的思想论文以及与我工作的团队有关的思想形式化。
对我而言，重要的是测试对用户的影响，以便他们更快地做出正确的决策。 为此，您必须使用紧密的反馈循环来缩短开发人员犯错和纠正错误之间的时间。 这些错误是各种质量（行为，性能，安全性，可用性等）所在的区域。 -缺席或恶化。
绝对不能通过发现的错误数量来衡量，但是错误的性质起着作用。 我的任务是发现最威胁开发完整性和质量的错误。 这可能归因于错误的“质量”，也就是说，这些错误越威胁完整性，就越重要。
我认为，有效纠错的关键是尽快发现这些错误，最好是尽快发现它们。 尽管从我的角度来看，即使“错误质量”也离最高标准还差得远。
我们非常重视错误的质量，但实际上它们的数量通常微不足道吗？
实际上，如果您非常注重减少查找错误的时间，那么错误的数量就很重要。 假设系统有10个严重的错误。 我真的很快找到了其中两个，这真的很酷！ 在推出该产品之前，发现了两个严重错误。 但是我在部署之前没有找到其他人。 这意味着未发现8个严重错误。 在这种情况下，即使我们当时不了解，错误的数量也是一个关键指标。
以稍微不同的方式思考很重要。 错误的数量或其质量并不像错误发生的机制以及相应的搜索机制那么重要。 有很多可用的选项：
- 善于发现错误，但作用时间太长的机制；
- 发现错误的机制较差，但工作速度非常快；
- “倾向于”注意到某种错误，但同时又看不到其他错误的机制；
- 这些机制在测试人员中不是很流行，但是确实有效并且不使用它们，因为在团队中没人知道它们，这就是为什么仍然可以找到发现的原因；
- 这些机制可以快速有效地运行，能够发现许多错误，但是它们的响应非常模糊，以至于人们无法根据其输出做出决策。
重要的是，不仅要关注其他方面，而且要关注这些方面，因为它有助于避免一些传统上出现的问题。 例如，那些您进行了一百次测试但未发现任何错误的测试。 这可能很好，但前提是确实没有错误。 但是，如果它们确实存在，那么如果所应用的测试方法无法识别它们，那就不好了。 或者，当我运行一堆测试时，我发现较小的错误，而跳过了更困难的错误。
我和我的团队必须根据执行的测试做出某些决定。 这意味着我们必须相信所告知的测试结果，因此，我们必须首先信任在这些测试中实施的检测方法。
某些检测方法来自测试本身，大致来说，取决于它们的查找内容和外观。 其他检测方法必须是环境本身和可测试性所固有的，我们定义它们来确定原则上测试将导致错误（如果存在）的可能性和可能性。
最后，我想提出一个事实，即我无法通过任何特定因素来确定测试是否成功。 但是，如果您仍然想以某种方式自己确定此错误，则不应该根据发现的错误和漏洞的数量而不是由这些错误的质量来确定，而应由测试机制检测它们的特定能力来确定。
我发现，经验不足的测试人员在阅读了此说明后，不会发现检测能力的想法与突出显示这些功能后获得的结果之间有显着差异。 至于专家，他们应该与众不同。
测试人员能够理解和表述这种差异，可以超越“验证”和“测试”之间无用的（仅是作者的意见）差异，而是对人为和自动的检测方法建立建设性的理解，从而允许测试以帮助人们更快地做出更好的决策。
这是一个看似简单但非常有用的材料。 根据既定的惯例，我们正在等待您的评论，我们邀请您参加
开放式网络研讨会 ，该
研讨会将于3月11日由Group-IB领先的测试自动化工具
Mikhail Samoilov举行。