在敏捷中显示客户/涉众的系统测试覆盖率

Question

我在一家软件咨询公司工作，担任测试分析师，并寻求一些关于敏捷测试的建议。

自从我的公司移动敏捷之后，我认为测试已经变成了瀑布的小迭代，而不是真正的敏捷。

示例：

• 2周短跑开始
• 所有积压票都是按脚本编写的。
• 等待开发需求/功能
• 功能被发布到测试环境中。
• 针对SUT执行的测试脚本
• 返工/测试报告，直到sprint完成为止

我对这种方法的问题是，我们从来没有得到充分测试一切的时间。

我想转向一种更灵活的测试方式(例如轻量级脚本、探索性测试、映射需求的思维地图测试计划)，但我觉得我很难从这种方法中提取任何度量标准。

对于在敏捷环境中工作的测试人员，如何向客户提供度量？我通常通过测试套件对需求覆盖率进行细分，然后从测试用例结果中给出度量标准，以显示测试的需求百分比，有多少通过/失败了。

测试用例是否需要显示您将要测试的内容，还是更好地分析实际系统？

Answer 1

在我看来，围绕测试用例和需求的度量并不适合敏捷测试。很容易添加许多简单的测试用例，这些测试用例并没有增加那么多的价值，但可以积极地改变度量标准。

我个人认为以下指标在敏捷测试中最有用：

根源分析

根源分析展示了是什么导致了仍然存在于系统中的bug，以及它们为什么逃脱了测试。

就我个人而言，我更倾向于将逃脱的bug划分为如果更早发现它们，它是否会增加足够的价值和成本。一个只发生在一个客户身上的错误，因为如果它们的设置非常具体，那么只有在您测试所有客户的所有设置的所有奇怪之处时，才能更早地找到它们。这是不值得的，因为它的成本与效益(即由于额外测试而发现的bug)。这分为两类：

• 早该发现的Bugs
• 以前不应该发现的错误

在对这两个类别进行了根本原因分析之后，您可以显示测试过程是否发现了更多优先级最高的bug，而发现了优先级较低的bug(更倾向于发现功能问题而不是文本不一致)。请注意，错误未被及早发现的原因并不总是归咎于测试团队f.e。这可能是一个需求问题(客户期望的东西不是交付的)。

这表明您按照预期执行敏捷测试:在最少的时间内以最肯定的方式确保质量(因为时间几乎总是限制因素)。

数量的开放bug

您还可以随时保存打开的bug的图表。理想情况下，您可以将其度量为优先级类别。需要在几天内修复的关键错误比文本上的不一致更重要。注意，保持尽可能低的bug数量并不是测试团队的主要优先事项，但这是团队的努力(开发人员最终需要修复它们)。

Bugs每类

您还可以跟踪每个类别的bug数量，在那里可以根据您认为最合适的情况定义类别。您可以使用性能、安全性、功能等类别，或者基于产品组件(用于堆栈溢出:问题和答案、搜索、配置文件等)。这让我们很好地洞察了哪些类别需要更多的关注，无论是测试(如果出现了大量的安全漏洞，您应该尽早抽出时间，以减少逃离测试过程)或开发(修复bug)。

Answer 2

我不同意；度量和测试计划很重要。(我认为其中有一个关于测试在敏捷环境中应该如何工作的单独问题；如果您以前没有看过http://lisacrispin.com/2017/06/02/agile-testing-essentials-livelessons-video-course/，我建议您看它，并可能问一个单独的问题。)

然而，从客户的角度来看，我并不认为它们很重要。要么你已经完成了一个函数并准备好了交付它，要么你就没有了。告诉他们70%的测试用例已经通过，或者什么的，因为你必须解释哪些测试用例没有通过，以及他们是否需要担心等等。

至于为规划测试和跟踪测试而编写某种文档的问题，两者都是基本问题。这并不是因为您一定要向任何外部人员展示它，而是因为您在执行迭代计划/暂停时需要与您的开发人员和其他测试人员共享它。你可以和他们谈谈什么是最好的方式来记录/衡量事情是对每个参与的人。有一个测试层次结构可能很有帮助，所以您可以快速地显示影响；不能进行测试A意味着您也可以进行其他四种测试，而不能进行测试B只是阻止了特定的测试。

对于历史来说，测试计划也很重要；作为一个测试人员，当我测试一些类似的功能时，看看某人几年前做了什么非常有帮助，为我可能想做的事情提供想法。在进行回归/其他类型的测试时，它也是有帮助的。