翻译内容

为了跟上采用敏捷软件开发所带来的更短的发布周期，许多开发团队都将测试自动化作为一种手段，不断确保每个软件版本都符合所需的质量水平。

这是传统软件开发实践的重大转变，在开发过程结束时，测试经常被停留在一起，被视为一个过程负担而不是一个好处。因此，在一个采用敏捷软件开发，转变为DevOps文化并采用持续集成和持续交付的组织中工作的测试人员必须至少基本了解如何有效地实施测试自动化作为日常活动的一部分。

不幸的是，敏捷软件开发中的许多测试自动化工作都失败了，或者至少没有最大化它们的潜力。

我想探讨一下我认为测试自动化无法满足敏捷软件开发过程中测试人员和其他利益相关者的期望的两个最重要原因。然后，让我们看看如何避免陷入这些陷阱的策略和策略，以便在敏捷环境中成功实现测试自动化。

不合理的期望

我看到如此多的自动化工作未能发挥其潜力的两个主要原因中的第一个是因为在实施之前存在不合理的期望。太多的团队负责人，开发和项目经理以及C级管理人员（尽管其他角色也不是无辜的）都将测试自动化视为解决所有测试瓶颈的一站式解决方案。

然而，现实已经一再表明：

1、实施测试自动化需要时间，精力和特定技能

2、自动化是一种支持测试人员的活动，而不是替代他们

3、与测试相关的每项活动不是都可以实现自动化

然而，仍然普遍认为测试自动化以某种方式神奇地按下按钮，将为您执行所有必需的测试。经过几个月的努力建立和运行测试后，这个概念变成了幻想，那些一直在努力使自动化工作的人往往是替罪羊，有时甚至被解雇。

在我看来，测试人员和自动化工程师处理这个问题的最佳方式是在行动之前进行思考和沟通。确保所有利益相关者在自动化方面可以合理期望的水平处于同一水平。看看您组织内部以及更广泛的软件测试和开发社区之前的努力，并从这些经验中学习。

应该怎么做？什么可能不会？不要指望自动化是解决所有测试问题的灵丹妙药。

缺乏专注于自动化的注意力

自动化失败的另一个主要原因是开发团队（以及更大规模的整个组织）缺乏时间来创建有用，可维护和有效的自动化解决方案。尽管实现自动化需要花费时间和精力并不令人意外，但是当时间变得稀疏时，自动化仍然是首先遇难的事情之一。

这适用于项目，但它也适用于在敏捷环境中工作的团队。尽管许多软件开发团队的愿望清单中的自动化程度很高，但当sprint结束时，交付功能几乎总是优先于自动化。

请注意，我认为这不一定是件坏事。最后，它是为最终用户提供价值的功能，而不是有助于保护他们正常工作的自动化测试。然而，从长远来看，允许释放功能优先于所有功能的团队可能只是在试图在截止日期之后设定截止日期时耗尽。几乎就好像他们忘记采用灵活的工作方式是以可持续的速度创建软件，同时尽早收到反馈，而不是以经常的速度提供功能。

不允许有足够的时间来创建可靠的自动化解决方案也会产生不必要的副作用：如果您没有将自动化授予其应得的优先级（并且可能不是最优先考虑的事项），那么您的团队成员不太可能拥有足够的优先级时间成为熟练的自动化工程师。我将自动化视为一种工艺，与任何其他工艺一样，它需要不断学习和磨练你的技能。

使自动化成为敏捷开发过程的一部分

既然我们已经详细说明了自动化失败的两个主要原因，我想提出一个分步指南，帮助您避免这些陷阱，并成功实施测试自动化，作为敏捷软件开发活动的一部分。这绝不是权威指南，并非所有步骤都适用于您的情况。但是，遵循它们可能只会帮助您在敏捷自动化工作中取得更大成功。

1.设定合理的期望

正如我之前所说，任何自动化工作的成功都始于合理的期望。我发现询问并同意“为什么”是设定这些期望的好方法。为什么我们首先要自动化？为什么我们认为我们需要测试自动化？

请注意，在我看来，这个问题有很好的答案。 “因为我们希望能够获得开发人员每次提交的快速反馈”是一个很好的理由，而“因为我们根本不想进行手动测试”是不合理期望来源的一个主要例子。

2.将测试自动化视为软件开发

确保所有相关方都意识到测试自动化的引入基本上等同于在软件开发项目中引入软件开发项目。

这适用于项目规划方面（您应该为其分配资源并允许花费在开发和维护自动化上的时间等）以及它的技术实现（您正在编写代码，因此请务必申请良好的开发模式和实践，并尊重测试自动化是一项需要特定技能的工艺。

3.为自动化分配专用资源

为了在敏捷软件开发工作中成功实现测试自动化，您需要确保负责创建和维护自动化的人员都具备合适的技能并有足够的时间来完成。
将自己的时间投入自动化的人数取决于许多因素，包括他们的技能，需要创建的自动化类型，以及与要开发的应用程序相关的复杂性和风险。如果您的组织目前没有雇用足够的人来满足您的自动化需求，或者人们缺乏必要的经验，那么临时雇用外部专家可能是一个值得考虑让您入门的选择。

4.选择一个起点

就像任何一个非常大的项目一样，决定从哪里开始测试自动化看起来似乎是一项艰巨的任务。我在这里有两条建议：
1）从一些悬而未决的成果开始（这有助于向利益相关者展示快速测试自动化的附加价值），或者与应用程序的一部分相关的风险最高或最高的影响。

2）尽量避免使用端到端测试自动化，例如使用Selenium。虽然当你想要编写自动化回归测试时，这似乎是一个明显的选择，但这种类型的测试是最难编写的，执行速度最慢，最容易失败，或者是由于测试中的应用程序的变化或由同步或环境（例如，测试数据）问题引起的误报。相反，看看您是否可以创建一组可靠的单元测试，或利用API级别的测试来验证关键业务逻辑。

5.使自动化成为您完成定义的一部分

当您在敏捷设置中工作时，将测试自动化作为给定特征的完成定义的一个组成部分是有意义的。尽管如此，尽量避免这两个陷阱：

1）包括诸如“所有测试应该是自动化的”或“我们应该为所提供的每个功能实现自动化”之类的声明 - 有时自动化没有意义，繁琐，甚至完全不可能创建。相反，请选择“现有自动化已更新以反映此功能带来的更改”或“在开发团队认为相关且有用的情况下创建了其他自动化”之类的语句。

2）依赖百分比 - “100％代码覆盖率”是一个空话。它没有说明测试的质量或相关性。同样，“80％的所有测试都是自动化的”也没有意义。首先，这依赖于对自动化测试执行的测试的一对一转换，这种方法一次又一次被证明是无效的。但更重要的是，您如何首先定义80％？ 80％的可自动化或所有测试都在执行吗？我想你在这里抓住我的漂移。

6.学习和调整

这不应该是一个惊喜：测试自动化是一个软件开发活动，当你以敏捷的工作方式这样做时，应用快速反馈，快速评估和学习的敏捷原则是完全合理的。去吧。

你不必从一开始就把它弄好！就像您正在测试的应用程序一样，花时间进行实验，尽早评估，经常学习任何错误，并坚持使用有效的方法。随着时间的推移，以及适量的培育，这将导致自动化方法与您的软件开发工作紧密相关。

请注意，每种情况都不同，对一个组织有效的方法可能在其他地方不起作用。话虽如此，我真诚地相信上述信息对大多数正在努力进行有效测试的组织都有所帮助，因此他们将自动化视为改进敏捷测试工作的一种手段。