更好的敏捷测试之路

Capgemini 创建的年度世界质量报告显示，42% 的受访者将“缺乏专业测试专业知识”列为将测试应用于敏捷开发的挑战。 虽然敏捷的出现为软件开发带来了迭代速度的提高，但在某些情况下，这是以质量为代价的。

激烈的竞争迫使团队不断提供新产品更新，但这有时会带来自身的成本，包括对测试的关注减少。 有些人，比如 Rob Mason，走得更远，认为敏捷正在扼杀软件测试。 最近，Facebook 将其座右铭从“快速行动，打破常规”改为“快速行动，稳定的基础设施”，试图化解牺牲质量的诱惑。

那么，测试如何才能更好地融入敏捷软件开发的新世界呢？ 敏捷测试。

传统的测试非常繁琐，并且依赖于大量的文档。 敏捷测试是一种模拟敏捷软件开发原则的测试过程方法，其中：

• 测试进行得更频繁，
• 测试更少地依赖文档，更多地依赖团队成员的协作，并且
• 一些测试活动不仅由测试人员进行，也由开发人员进行。

在过去的七年里，我已经将许多团队转变为敏捷测试，并与测试人员并肩工作，以帮助他们的流程适应新的方法。 在本文中，我将分享一些我在实现更好的敏捷测试的过程中学到的最有影响力的技巧。 虽然敏捷实践中速度和质量之间存在摩擦是很自然的，但本文将介绍一些可用于在不影响敏捷性的情况下提高测试质量的技术。 此处列出的大多数建议都需要团队的参与，因此让开发人员和测试人员都参与规划将是有益的。

正式发布测试周期过程

测试的一个问题是缺少发布测试周期、没有发布时间表或不定期的测试请求。 按需测试请求使 QA 过程变得困难，尤其是在测试人员处理多个项目时。

许多团队在每个 sprint 之后只进行一次构建，这对于敏捷项目来说并不理想。 转向每周一次的发布可能是有益的，逐渐过渡到每周多次构建。 理想情况下，开发构建和测试应该每天进行，这意味着开发人员每天将代码推送到存储库，并且构建计划在特定时间运行。 为了更进一步，开发人员将能够按需部署新代码。 为了实现这一点，团队可以采用持续集成和持续部署 (CI/CD) 流程。 CI/CD 限制了在主要版本发布当天构建失败的可能性。

当 CI/CD 和测试自动化相结合时，早期发现关键错误是可能的，使开发人员有足够的时间在计划的客户端发布之前修复关键错误。 敏捷的一项原则指出，工作软件是衡量进度的主要标准。 在这种情况下，正式的发布周期使测试过程更加敏捷。

使用部署工具授权测试人员

测试的常见摩擦点之一是将代码部署到暂存环境。 此过程取决于您的团队可能无法影响的技术基础设施。 但是，如果有一定的灵活性，可以为测试人员或项目经理等非技术人员创建工具，允许他们部署更新的代码库以进行自己的测试。

例如，在我的一个团队中，我们使用 Git 进行版本控制，使用 Slack 进行通信。 开发人员创建了一个可以访问 Git、部署脚本和一个虚拟机的 Slackbot。 测试人员能够使用从 GitHub 或 Jira 获取的分支名称 ping 机器人，并将其部署在暂存环境中。

当测试人员不得不要求开发人员部署一个分支进行测试时，这种设置为开发人员腾出了大量时间，同时减少了通信浪费和持续中断。

试验 TDD 和 ATDD

测试驱动开发 (TDD) 是一种非常重视质量的软件开发过程。 传统上，开发人员编写代码，然后有人对其进行测试并报告是否发现了任何错误。 在 TDD 中，开发人员首先编写单元测试，然后再编写任何可以完成用户故事的代码。 测试最初会失败，直到开发人员编写了最少量的代码来通过测试。 之后，重构代码以满足团队的质量要求。

验收测试驱动开发 (ATDD) 遵循与 TDD 类似的逻辑，但顾名思义，它侧重于验收测试。 在这种情况下，验收测试是在开发之前与开发人员、测试人员和请求者（客户、产品所有者、业务分析师等）合作创建的。 这些测试帮助团队中的每个人在编写任何代码之前了解客户的需求。

TDD 和 ATDD 等技术通过将测试过程移至开发生命周期的早期阶段，使测试更加敏捷。 在早期编写测试场景时，开发人员需要非常了解需求。 这最大限度地减少了不必要的代码创建，并解决了开发周期开始时的任何产品不确定性。 当产品问题或冲突仅在后期出现时，开发时间和成本就会增加。

通过跟踪任务卡移动发现效率低下

在我的一个团队中，我们有一位开发人员非常快，尤其是在小功能方面。 他会在代码审查期间收到很多评论，但我们的 Scrum master 和我因为缺乏经验而把它写下来。 然而，随着他开始编写更复杂的功能，问题变得更加明显。 他开发了一种在完全准备好之前将代码传递给测试的模式。 这种模式通常在开发过程缺乏透明度时形成——例如，不清楚不同的人在给定任务上花费了多少时间。

有时，开发人员匆忙工作，试图尽快推出功能并将质量“外包”给测试人员。 这样的设置只会将瓶颈移到 sprint 的下方。 质量保证 (QA) 是团队拥有的最重要的安全网，但这可能意味着 QA 的存在使开发人员能够放弃质量考虑。

许多现代项目管理工具能够跟踪 Scrum 或看板上的任务卡的移动。 在我们的案例中，我们使用 Jira 分析了相关开发人员的任务发生了什么，并与团队中的其他开发人员进行了比较。 我们发现：

• 他的任务在我们板子的测试栏中花费了几乎两倍的时间；
• 他的任务通常会从 QA 中返回，以进行第二轮或第三轮修复。

因此，除了测试人员必须在他的任务上花费更多时间外，他们还必须多次执行。 我们不透明的过程使开发人员看起来非常快； 然而，当我们考虑到测试时间时，这被证明是错误的。 来回移动用户故事显然不是一种精益方法。

为了解决这个问题，我们首先与这位开发人员进行了坦诚的讨论。 在我们的案例中，他根本没有意识到他的工作模式是多么有害。 这只是他习惯了在他以前的公司工作的方式，这家公司对质量的要求较低，测试人员的数量较多。 经过我们的交谈，并在与我们的 Scrum master 进行了几次结对编程课程的帮助下，他逐渐转向了一种更高质量的开发方法。 由于他的快速编码能力，他仍然是一个高绩效者，但消除了 QA 过程的“浪费”，使整个测试过程更加敏捷。

将测试自动化添加到 QA 团队技能集中

非敏捷项目中的测试涉及测试分析、测试设计和测试执行等活动。 这些活动是连续的，需要大量文档。 当一家公司过渡到敏捷时，通常情况下，过渡主要集中在开发人员身上，而不是测试人员身上。 他们停止创建大量文档（传统测试的支柱），但继续执行手动测试。 但是，手动测试速度很慢，通常无法应对敏捷的快速反馈循环。

测试自动化是这个问题的流行解决方案。 自动化测试使测试新功能和小功能变得更加容易，因为测试代码可以在后台运行，而开发人员和测试人员则专注于其他任务。 此外，由于测试是自动运行的，因此与手动测试工作相比，测试覆盖范围可能要大得多。

自动化测试是类似于正在测试的代码库的软件代码片段。 这意味着编写自动化测试的人需要技术技能才能成功。 不同团队之间实施自动化测试的方式有很多不同的变化。 有时，开发人员自己扮演测试人员的角色，并通过每个新功能增加测试代码库。 在其他团队中，手动测试人员学习使用测试自动化工具或聘请经验丰富的技术测试人员来自动化测试过程。 无论团队采取哪种方式，自动化都会带来更加敏捷的测试。

管理测试优先级

对于非敏捷软件开发，测试人员通常是按项目分配的。 然而，随着敏捷和 Scrum 的出现，相同的 QA 专业人员跨多个项目进行操作已变得很普遍。 当测试人员将一个团队的发布测试优先于另一个团队的 sprint 计划会议时，这种重叠的职责可能会在计划中产生冲突并导致测试人员错过关键仪式。

测试人员有时在多个项目上工作的原因是显而易见的——很少有稳定的测试任务流来填补全职角色。 因此，可能很难说服利益相关者将专门的测试资源分配给团队。 但是，在不参与测试活动时，测试人员可以执行一些合理的任务来填补停机时间。

客户支持

一种可能的设置是让测试人员花费他们的冲刺停机时间来帮助客户支持团队。 通过不断面对客户遇到的问题，测试人员可以更好地了解用户体验以及如何改进它。 他们能够在规划会议期间为讨论做出贡献。 此外，他们在测试活动中变得更加专心，因为他们更好地熟悉了客户如何实际使用他们的软件。

产品管理

管理测试人员优先级的另一种技术基本上是让他们成为执行手动测试的初级产品经理。 这也是填补测试人员下班时间的可行解决方案，因为初级产品经理花费大量时间为用户故事创建需求，因此对大多数任务都有深入的了解。

测试自动化

正如我们之前所讨论的，手动测试通常不如自动化。 在这种情况下，自动化的推动可以与让测试人员全神贯注于团队并利用他们的业余时间学习使用像 Selenium 这样的测试自动化工具一起工作。

总结：质量敏捷测试

使测试更加敏捷是许多软件开发团队现在面临的必然。 然而，质量不应因采用“尽可能快地测试”的心态而受到影响。 敏捷过渡必须包括向敏捷测试的转变，有几种方法可以实现这一点：

• 正式确定发布测试周期过程。
• 为测试人员提供部署工具。
• 试验测试驱动开发和验收测试驱动开发。
• 通过跟踪任务卡移动发现效率低下。
• 将测试自动化添加到 QA 团队技能集中。
• 管理测试人员的优先级。

每年，软件都在变得更好，用户的期望也在提高。 此外，随着客户习惯于谷歌、苹果和 Facebook 等顶级软件品牌的高质量产品，这些期望也会转移到其他软件产品上。 因此，在未来几年中，对质量的重视可能会更加重要。 这些测试和整体开发过程的改进可以使测试更加敏捷并确保高水平的产品质量。