AIMA：如何通过质量指标提高 QA 的绩效（译）

本文首发于【林子的空间】

译者按： QA 在团队的价值总是被质疑，本文利用简单的 AIMA（分析、影响、度量、演示）四个步骤，介绍如何将 QA 的工作重心放在跟团队/项目的质量指标关联的工作上，通过质量指标来提高 QA 的绩效，体现 QA 的价值。

原文为葡萄牙语，模型里的 AIMA 分别来自于四个步骤的葡萄牙语首字母：

• 分析 Análise

• 影响 Impacto

• 度量 Metrificação

• 演示 Apresentação

英文原文：AIMA: How to increase the performance of QA Analysts through indicators，作者：Jonas Davila

随着越来越多的公司使用 KPI 指标来衡量软件质量，质量分析师（QA）迎来了更多的机会。 QA 工作有很多的可能性，比如：被安排在实践定义不明确的团队或组织，或者是 QA 角色职责不清晰的团队。

QA 要开展的活动跟团队具体情况有关，但可以使用一种方法轻松地将改进点可视化，从而快速为公司和团队增加价值。 因此，当 QA 在质量流程没有明确定义的团队中工作时，需要思考以下两个问题：

• “你将如何为团队增加价值？”

• “你将要开展什么活动？”

答案通常是相同的：了解上下文并确定改进点。 通过这种方式，可以使得行动具有战略性，因为任何不基于事实和数据的声明，既不可能是团队决策，也很可能无法实现。

AIMA 方法

为了支持这个改进过程，下面将介绍 AIMA（分析、影响、度量和演示）方法：

分析

第一步，收集尽可能多的信息并做笔记。 通过有目的地观察，可以确定改进点，可以通过与团队的任何互动（例如会议或仪式）找到改进点。

此外，结对是一种很好的交流方式，能够加速对项目和公司中使用的技术的理解。

本步骤获取输入，以识别我们可以轻松增加价值的点。

影响

下一步将是通过解决需要频繁返工的最明显的日常问题来增加价值。 要改进的始终是那些重要而难以改进的地方，通常需要投入很多精力和时间，如果不完成，可能会影响产品或业务。

可以根据以下几点来指导你的行动：

• 与团队建立信任关系；

• 基于最终用户的体验来制定决策；

• 讨论选定的 KPI；

• 必要时与项目干系人保持一致。

通过这些实践，你将有更多空间提出变更和新的解决方案，为交付质量做出重大贡献。

度量

“没有被度量的东西是无法改进的。” 因此，当我们考虑软件质量时，度量影响对于了解我们是否走在正确的轨道上很重要。 如果偏离正轨，我们可以更改策略以与业务目标保持一致。

要映射的指标取决于要实现的目标，例如代码覆盖率、生产中发现的缺陷和圈复杂度。

通过指标，我们可以展示所开展工作的可靠性和一致性，并将其用作制定战略决策的输入。

演示

这是非常关键的一步。 通过演示，我们利用规划开始时列出的指标来展示成功率。 此时，我们必须呈现在时间范围内执行的目标，显示团队行动计划带来的影响和结果。

除了工作的要点之外，我们必须牢记我们从结果中学到的东西，以及在下一个周期中要开展的步骤。

AIMA 方法实践

背景：

伊莎贝尔被一家金融行业的公司聘用，将加入一个新成立的团队，负责为其核心系统开发新功能。 该功能需要在一个小时内清算 Boleto 银行单据的付款。

第一步：分析

加入团队后，伊莎贝尔开始观察，记录所有可能相关的内容。 在与团队互动时，她询问有关新功能、当前系统如何工作、更改原因是什么、实施截止日期是什么、以及项目架构如何工作等问题。

通过与团队的互动，她得知团队的任务是提高项目质量，第一个目标是实现 30% 的代码覆盖率。 在与团队交谈时，伊莎贝尔意识到目前没有在任何应用程序层上执行测试。 她认为团队管理层设定的 KPI 与团队实践之间存在偏差。

伊莎贝尔发现，在项目开始时，一位名叫费尔南达的开发人员开始写单元测试，但由于项目紧张的交付周期和缺少团队其他成员的参与而半途而废。

第二步：影响

伊莎贝尔与费尔南达进行沟通，并提出了基于 KPI 的测试策略，从一个高风险点开始，即负责在一个小时内清算 Boleto 付款的模块，之前完成这个最多需要 3 天。 在费尔南达的支持下，伊莎贝尔与团队讨论了进行测试的重要性，以及如果无法清算付款会产生什么影响。

这样，团队同意开始为负责清算支付的模块编写单元测试。 因此，伊莎贝尔和费尔南达负责在下一个开发周期中启动这个活动。

开始创建第一个测试时，她们就发现之前在夏令时开始和结束之间的时间段内进行测试时，系统的行为跟预期不符。 他们最终发现系统中存在不一致，代码逻辑仍在考虑夏令时。也就是说，他们的测试很快见效了，发现了问题。

第三步：度量

为了衡量测试所达到的代码覆盖水平，伊莎贝尔与费尔南达使用工具生成每个测试覆盖的行百分比报告。 这样，除了可以清晰地知道哪些没有测试覆盖外，团队可以通过识别测试较少覆盖的点来做策略性调整，并通过风险分析确定需要优先增加测试覆盖的模块。

第四步：演示

在开发周期结束后，伊莎贝尔与费尔南达使用收集到的信息给干系人演示，展示关于既定目标的改进。结果显示覆盖率增加了 8%，下一步将把这些测试集成到流水线上。

通过演示，更多的团队成员意识到测试在项目中的重要性，因此，他们估算的时候除了考虑开发时间，还会考虑测试。

最后

我们可以得出结论，为了使软件质量保障的结果与 KPI 和干系人的期望保持一致，需要曝光质量保障过程。通过这种方式，能够收到反馈以持续改进过程中的每个活动。

当我们知道我们要去哪里时，到达目的地只是时间问题。