AIMA:如何通过质量指标提高QA的绩效(译)

2021-09-09   出处:BY林子  作/译者:BY林子  

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

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

        ● 分析 Análise

        ● 影响 Impacto

        ● 度量 Metrificação

        ● 演示 Apresentação

        英文原文:AIMA: How to increase the performance of QA Analysts through indicators (https://www.thoughtworks.com/insights/blog/aima-how-increase-performance-qa-analysts-through-indicators )

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

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

        ● “你将如何为团队增加价值?”

        ● “你将要开展什么活动?”

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

1. AIMA 方法

        为了支持这个改进过程,下面将介绍 AIMA(分析、影响、度量和演示)方法:

分析

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

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

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

影响

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

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

        ● 与团队建立信任关系;

        ● 基于最终用户的体验来制定决策;

        ● 讨论选定的 KPI;

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

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

度量

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

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

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

演示

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

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

2. AIMA 方法实践

背景:

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

第一步:分析

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

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

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

第二步:影响

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

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

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

第三步:度量

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

第四步:演示

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

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

3. 最后

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

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

        


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
129°|1290 人阅读|0 条评论

登录 后发表评论