分享到社交媒体:

译者按: 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(分析、影响、度量和演示)方法:

AIMA

分析

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

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

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

影响

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

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

  • 与团队建立信任关系;
  • 基于最终用户的体验来制定决策;
  • 讨论选定的 KPI;
  • 必要时与项目干系人保持一致。

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

度量

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

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

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

演示

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

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

AIMA方法实践

背景:

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

第一步:分析

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

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

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

第二步:影响

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

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

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

第三步:度量

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

第四步:演示

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

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

最后

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

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

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注