大家好！我是Alexander，是Wrike的质量保证与测试(QAA)经理。2010年，我作为第一位QAA工程师加入了这个团队。在过去的12年中，我们组建了一支出色的QAA工程师团队；我们共同为我们可爱的项目管理平台Wrike开发了一个独特的质量控制系统，使我们能够更快地将产品代码部署到生产环境中，而且没有bug。
Wrike独特质量控制系统的发展历程
多年来，我们从一个小创业公司发展成为拥有逾1000名员工和1千万用户的全球大型产品公司。随着客户群体的增长，我们对确保高质量的产品代码负有更大的责任。自动化测试的数量也随之增长，增长速度之快，如果不对这些测试及其质量进行适当的管理，灾难可能随时发生。因此，我们决定有意识地思考如何控制这个过程，预测快速增长的测试代码库可能出现的问题，并明确测试开发过程、框架和测试基础设施中的当前问题和瓶颈。
为什么要“有意识地”进行思考呢？因为我们已经在这方面收集了指标和统计数据，但当时所有这些都只是为了交付而进行，匆忙进行，更严重的是，没有明确结构化的过程来回答以下问题：“我们为什么要这样做？我们要解决什么问题？这项工作的价值是什么？我们可以通过哪些指标来评估我们的改进带来的影响？”
衡量改进的重要性
明智地选择指标
如果无法衡量，就无法改进，这句话准确地描述了本文的前提，我们的QAA团队也遵循这一原则。指标可以评估我们工作和测试的质量。我们可以管理产品的质量，并能够精确定位并改进测试、测试框架和测试基础设施。是的，我们支持渐进式的方法，而不是革命性的方法。为了重建某物，打破或摧毁某物，这种方法在其他地方可能行之有效，但恐怕对我们来说行不通；在我们的情况下，重建可能需要一年甚至多年的时间。
QAA团队可以从专业自行车队中学到什么
几年前，我看到了一篇关于英国专业自行车队Sky（现在是INEOS Grenadiers）总经理David Brailsford的有趣文章。当他在2010年加入该队时，他的主要承诺是赢得环法自行车赛，这是一个崇高的目标，因为自1903年以来，还没有一位英国自行车手赢得过这个著名的自行车比赛。
Brailsford的方法非常简单。他支持逐渐积累最小改进的概念，然后至少将每个指标提高1%。最终，整体效果将是巨大的改进。团队的管理人员检查了几乎每个方面，如饮食、训练计划、自行车人体工学和正确的骑行姿势，以及特别选择的睡眠枕头和按摩凝胶等细节。
团队对所有可检查和改进至少1%的事物进行了全面审计。Brailsford相信，如果这一种策略可行，团队将在五年内赢得环法自行车赛。但他错了——Sky车队仅用了三年就取得了胜利。一年后的2013年，他们再次成功。作为Brailsford成功方法的进一步证据，他领导的英国自行车队在2012年奥运会上获得了八枚金牌、三枚银牌和两枚铜牌。
我也支持这样的方法——一种允许你渐进式、逐步实现里程碑的方法。是的，它可能不会那么快速，但总的来说，如果你回顾一下，这种方法将使你的团队积累定性和定量潜力，确定增长的焦点，并因此有信心实现他们设定的目标。
指标的作用
我想谈谈三个经验，这些经验将使我们能够论证，如果没有正确的指标，评估和管理对当前流程所做的改变将变得极为困难。正如我所说，关键在于选择合适的指标，因为仅仅因为这样随机收集统计数据，然后根据任何改进的实施建立假设，可能不是最有效的方法。同样重要的是要了解收集的指标的统计数据如何适用于特定的流程、算法等。
确定指标的两个原则
在Wrike，我们有两个原则来确定构建指标的方法。
第一个原则是基于我们想要解决的现有问题来收集统计数据的过程。例如，我们在处理代码合并请求到主分支的持续时间方面存在问题。换句话说，问题已经明确表述，对于解决这个问题，我们对哪个指标能够帮助我们评估所做工作的有用性有一定的理解。
第二个原则是为统计数据定义参考点或指标，并确定它们在实验过程中的评估方式。换句话说，如果我们将失败的测试的重试次数增加N次，它与总的构建运行时间和成功率之间的相关性如何？目标是找到最佳的重试次数。
故事一：指标在测试开发中的重要性
1）识别瓶颈：审查流程和QAA团队中指标的重要性
测试开发是一个相当复杂的过程，包括设计测试用例和测试、开发自动化测试以及进行代码审查等多个阶段。在产品或特定功能的开发过程中存在着子流程，对企业来说，能够快速将可用于生产的功能交付出去是非常重要的，最好是没有任何错误。
在我们季度计划会议中的反馈收集过程中，有几个产品团队引起了我们对测试开发过程时间过长的关注。很多时候，功能特性在没有自动化测试的情况下就被部署到生产环境中，因此我们开始思考问题所在，回顾了最近部署功能的过程。我们决定从最后一个阶段开始——代码审查，因为是人为干预的阶段，这可能被视为一个瓶颈。
我们根据合并请求的生命周期、发送代码进行审查和将审查过的代码合并到主干的时间间隔等统计数据，准备了“合并请求生命周期”这一指标。接下来的问题是如何评估这个指标——哪个数值是好的，哪个数值是坏的，或者审查代码可以花费多少小时。我们必须考虑到产品团队通常有两周的迭代周期，以及QAA工程师的工作能力。这就是我们得到48小时的原因。因此，80%的合并请求不能超过代码审查的时间，这意味者大部分的和并请求应该在48小时内完成。过去一个季度每月收集的统计数据显示，合并请求的生命周期远不及我们的设定。
2）引入 JiGit，加速 QAA 团队的代码审查
我们开始进一步思考如何加快审查流程。当我们从审查人员那里收集反馈时，他们提出了一个想法，即可能会有一个工具能够自动分配审查人员并发送提醒，以便他们审查代码。于是，一个名为JiGit的工具诞生了，它可以让我们指定一个被分配者并自动提醒他们进行审查。您可以在本文中了解这个工具的工作原理，以及它的内部细节。
我们完成了JiGit的第一个版本，并在2017年第四季度立即将其应用到我们的测试开发流程中。在2018年第一季度，我们看到了“合并请求生命周期”指标的统计数据有了很大的改善。
经过两个季度，我们实现了48小时的承诺。我们的产品团队给出了反馈，确认审查工具正常运行，并且自动化测试的开发加速了。我们在统计数据中也看到了同样的情况。这就是为什么采用JiGit让我们能够保持良好的开发速度。我们2022年第四季度的当前统计数据如下：
利用指标管理和评估QAA团队的绩效
由于这个指标，我们能够管理和评估自动化测试开发的时间，并在出现异常偏差的情况下，系统地分析这些偏差的原因。例如，我们注意到在夏季月份，位于80%分位数的合并请求生命周期指标超过了48小时的数值。经过审查最长的合并请求（当然会影响最终的统计数据），我们发现许多同事都在度假，而JiGit并不知道这一点。当我们在JiGit中纠正了这个问题后，合并请求生命周期的数值恢复到了可接受的水平。
简而言之，我们利用“合并请求生命周期”指标来加速代码审查流程，并评估在这个过程中应用改进措施的有效性。
故事二：利用指标识别瓶颈
1）通过模块合并提高测试速度
在我们的季度计划会议上，我们一直在寻找方法来加快测试速度，思考我们在基础设施和测试框架方面还有哪些机会和机制可以让我们更快地运行测试构建。我可以说，我们所有重大的发明都是在研究、观察和实验的过程中偶然发生的，但这些偶然事件也总是伴随着许多工作上的挑战，以及失败和错误。然而，如果你有信心和坚持不懈，你最终会达到你期望的结果，而且通常它们就在你眼前！
类似的情况也发生在我们的测试模块合并上。在我们的测试框架中，大约有55,000个测试用例。我们的产品团队很少需要运行所有55,000个测试用例，这些测试用例分布在100多个模块中，以检查它们的范围。我们有正确的测试标记，允许团队创建自己的测试包/构建。在大多数情况下，这些测试套件被放置在不同的模块中。然而，随着测试基础的增长，我们面临一个挑战。
2）挑战：管理多模块测试构建
挑战在于管理并行运行测试的线程数，以及在初始运行后重试失败的测试。当模块数量增加时，整个构建或测试包的运行时间增加了50%。在解决这个挑战之前，看一下运行多模块构建的流程图：
同样的情况，可以在下面的Allure报告时间轴中看到：
3）合并不同模块的测试用例
为了解决多模块测试构建的挑战，我们尝试实现一种机制，将不同模块的测试用例合并成一个，以避免不合理使用多线程和重新运行失败的测试的问题。对比一下我们改进之前和之后的流程图：
为了进一步证明我们的成功，看一下下面的Allure报告时间轴：
4）改进的测试：评估模块合并的实用性
为了评估这个实施机制的实用性，我们使用了多模块测试构建的运行时间指标。具体来说，我们使用了组件测试的测试构建，其中运行了来自138个模块的11,000个测试用例，我们看到速度提高了两倍，如下所示：
为了检查我们的改进效果，我们在9月9日关闭了模块合并器，这就解释了图表上这个特定日期的时间跳跃。模块合并通常可以节省多模块测试运行的总时间高达30%。
故事 #3：软件开发过程中持续改进的度量标准
1）如何通过重试机制提高成功率而不增加构建运行时间
除了优化测试运行时间之外，我们还在解决每个季度测试稳定性的问题。您是否同意在自动化测试中，特别是在 UI 测试中，假阳性对每个人都是一个痛点？在我们的情况下，解决不稳定测试的最有效方法之一是通过测试重试机制：我们在构建运行中重新启动失败的测试，从而显著提高成功率指标。
因此，在规划2022年第三季度的任务时，我们决定进行一项实验：“我们可以增加多少次重试，以便不将测试构建运行时间增加超过20%？以及通过增加重试次数来实现在可接受的构建运行时间内取得更高成功率的最佳比例是多少？”历史上，所有构建的默认重试次数为三次。
在上面的图表中，您可以看到将重试次数增加到五次将成功率提高约4%，将次数增加到六次将成功率提高6.4%（并将构建运行时间增加了23.8%），将次数从五次增加到十次将成功率提高了10.7%（但构建运行时间增加了36%）。
还应考虑到，这些数据是从正在开发的功能分支上进行测试运行中收集的。这意味着有许多外部因素影响成功率，如错误和基础设施问题。然而，这个实验使我们能够将所有带有测试的构建的默认重试次数提高到五次。
我们正在为我们最长构建之一的“工作空间回归测试”收集成功率度量标准。请看下面的图表：
我们在2022年第三季度将重试次数提高到五次后，这些度量标准趋于稳定。
2）利用收集的度量标准进行有针对性和高效的改进
因此，根据我们收集到的数据，即采用渐进的过程和编码中的最小改进策略，使我们能够进行更有针对性和高效的改进，并调整和评估这些改进对我们工作的影响。
老实说，很难想象没有度量标准的工作；我会将其比作驾驶一架现代飞机，具有许多设备可以简化和简化飞行员的工作，而不是驾驶20世纪初期的飞机，使用纸质地图、指南针和其他机械工具，需要整个团队更多的参与。
我们学到了什么？
总之，任何过程改进倡议的成功取决于用于衡量进展的度量标准。度量标准在识别瓶颈、评估变更影响以及进行持续改进中发挥着至关重要的作用。作为 Wrike 公司的质量保证与测试经理，我了解到正确的度量标准必须根据现有问题慎重选择，并且它们应该与团队的目标和价值观保持一致。相对于革命性的方法，采用渐进的改进方法使团队能够积累质量和数量潜力，并自信地实现设定的目标。
