应该对QA采取探索性测试方法发现的缺陷吗？

Question

“计划外”测试用例是否应该针对组织中QA的度量标准进行？

对于上下文:在开发生命周期中有一个既定的过程，开发团队和QA聚集在一起，讨论要执行的测试和基于工作项的开发方法。在这次会议期间，QA和开发成员创建了一组“预期”测试和针对它们的开发人员代码。其中许多都是“愉快路径”测试，偶尔会出现探索性/错误处理场景。

然而，在测试周中通常会发生的情况是，计划中的测试通常会通过，但是QA仍然能够找到许多具有探索性的bug。我认为这是正常的，因为探索性测试存在以帮助发现缺陷，但是通过非计划的方法发现bug是否是QA的错误呢？

管理层认为，QA应该能够在初次会议期间识别尽可能多的场景，但是，当只审查需求和实际使用系统时，我们可以提前规划多少方案也是有限度的。这也鼓励了对QA团队质量的过度依赖，并将责任归咎于QA进行探索性测试，而实际上，这应该是团队内部的一项共同责任。

有什么想法？

Answer 1

我认为这里的第一个大问题是试图把责任归咎于别人。在事故报告中，联邦航空局并不是从该责怪谁开始，而是从哪里出了问题和什么原因开始。将责任归咎于所有类型的意外后果。

在最坏的情况下，如果您指责/惩罚QA发现在设计阶段没有预见到的bug，您将鼓励QA在测试期间找不到它们。注意:这意味着是客户发现了这些bug。计算计划外错误的想法比惩罚KLOC下降的开发者更糟糕。

要解释KLOC下降，请理解IBM通过计数编写的代码行( KLOC是一千行代码)来跟踪开发人员的统计数据。这些数字只对新的绿地项目有意义。一旦代码到位，将现有代码更改为更好的代码将不会在度量中显示。将代码更改为更简单/更容易理解实际上可以减少您的数量。这是微软在OS/2上使用IBM时遇到的问题之一(微软没有测量KLOC，IBM有)。因此，微软希望修复/改进代码，IBM员工也会抵制，因为没有增加KLOC计数的更改是没有价值的。

在这个指责游戏中，开发人员会因为QA发现的每一个错误而受到惩罚吗？如果没有，那么你对指责和责任的看法是不一致的。

关于度量的另一件需要记住的事情是，计算什么是重要的，而不是你能度量什么。人们对度量所做的太多的事情就是数数他们能度量什么。并不是所有的指标都是有价值的(有些甚至降低了价值)。

Answer 2

在以后的探索性测试中发现错误的原因可能有几个，但在项目规划阶段没有被识别。

其中几个可能是，

1. 测试人员是人类。人非圣贤，孰能无过。人类会犯错。如果不是，我们会成为上帝吗？
2. 根据你所写的，你和整个团队一起做计划，而不是孤立的。如果是这样的话，为什么其他人没有及早发现这个案子呢？业务分析师到底在做什么？以及项目经理、开发人员等？如果这仅仅是因为责备，那么他们都应该因为错过它而受到指责。

为什么在开发之前没有确认和列出这些案例，这是一个值得关注的问题？

这个项目还没有启动。因此，事实上，当时的问题应该是一件好事。如果您忽略了探索性测试，而这些bug可能会泄漏到生产中，那该怎么办？

是否有人担心经理们没有考虑给计划外的问题、路障、灾难留出缓冲时间，因而没有在ETA中很好地考虑项目交付？

如果在一个项目中一切顺利，那么是否只有测试人员才能为在您的团队中出色完成的工作获得所有的荣誉呢？如果没有，那么在产品发布之前或之后，项目中发现的任何问题都不会同样适用吗？

Answer 3

首先，前面的答案是好的，并提出了不同的观点，以供考虑。

我同意管理层不应该为缺少bug而找出归咎于QA的方法，也不应该以意想不到的、计划外的方式发现bug。这对团队来说是一个巨大的好处，在进行测试时也是一个很好的技能。

我对此的看法是，为什么在进行测试规划时只考虑“愉快路径”测试用例？对我来说，这是QA应该做的最起码的事情。为什么不在计划或“悲伤的熊猫”路径/场景中计划消极的测试用例呢？这当然可以根据给定的特性/故事的要求来完成。

如果票证中的要求只提到预期的积极方面，您可以询问不同的负面方面或用户可以期望的不同状态。

例如，如果您有这样一个要求，即“用户应该能够创建一个具有特定字符集的密码。”然后，如果用户不遵守密码准则，您可以询问他们应该获得的错误条件或错误消息。您不应该等到测试正在进行时才说：“我找到了一个错误，当我输入非有效字符时，我没有看到错误消息。”你可以而且应该提前知道这一点！

虽然您不能期望提前了解所有的测试用例，但您应该能够使用正确的测试技术(如边值分析、等效类、状态管理等)、先前的应用程序知识以及先前使用的类似应用程序来发现更多的测试用例。

著名的测试人员Michael有一个名为很少HICCUPPS的启发式方法，可以用来指导测试用例的创建。这个缩略词代表：

熟悉程度--你对你的产品或类似产品有多熟悉？

你能解释或理解产品的行为吗？

世界-该项目/功能是否与您先前的观察和对类似软件产品的一般看法(熟悉程度)一致？

历史-需求是否与以前版本的软件相一致？

形象--这些要求是否与公司的品牌、市场营销、声誉相一致？

可比产品-类似于对类似软件产品的熟悉程度和知识。

索赔-这些要求是否符合先前的预期？

用户的愿望-需求是否与用户或利益相关者的要求一致？

产品--需求是否与产品的其他特性相一致，或与产品的其他特性很好地结合？

目的-类似于用户的愿望。

法规和标准-这些要求是否符合任何法律、标准、法规？

每个细节和定义都可能很长，所以我不想过多地讨论它们的细节。我强烈鼓励阅读链接。