每年 世界质量报告 Capgemini的一项调查显示，42%的受访者将“缺乏专业的测试专业知识”列为将测试应用于敏捷开发的挑战. 当 敏捷 为软件开发带来了迭代速度的提高, 在某些情况下, 这是以质量为代价的.

激烈的竞争迫使团队不断发布新产品更新, 但这有时是有代价的, 包括减少对测试的关注. 有些人，比如罗伯·梅森，甚至更进一步，认为 敏捷正在扼杀软件测试. 最近, Facebook已经将其口号从“快速行动，打破陈规”改为“快速行动，稳定基础设施”，试图解决牺牲质量的诱惑.

那么，如何将测试更好地集成到敏捷软件开发的新世界中呢? 敏捷测试过程.

传统的测试非常麻烦，并且依赖于大量的文档. 敏捷方法中的测试是一种测试过程的方法，它模仿了敏捷软件开发的原则:

• 测试要频繁得多，
• 测试较少地依赖于文档，而更多地依赖于团队成员的协作
• 一些测试活动不仅由测试人员承担，也由开发人员承担.

在过去的七年里, 我已经将许多团队过渡到敏捷测试方法，并与测试人员并肩工作，以帮助他们的流程适应新的方法. 在本文中, 我将分享一些我学到的关于如何在敏捷中改进测试过程的最有影响力的技巧. 在敏捷实践中，速度和质量之间的摩擦是很自然的, 本文将介绍一些可用于在不影响敏捷性的情况下提高测试质量的技术. 这里列出的大多数建议都需要团队的参与，所以让开发人员和测试人员都参与到计划中来是有益的.

形式化发布测试周期过程

测试的一个问题是缺乏发布测试周期, 无发布时间表, 或者不定期的测试要求. 按需测试请求生成 QA 过程困难，特别是当测试人员处理多个项目时.

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

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

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

测试中常见的摩擦点之一是将代码部署到登台环境中. 这个过程依赖于您的团队可能无法影响的技术基础设施. 然而, 如果有一定的灵活性, 可以为非技术人员(如测试人员或项目经理)创建工具，允许他们部署更新的代码库进行测试.

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

这种设置为开发人员节省了大量时间，同时减少了通信浪费和测试人员要求开发人员部署分支进行测试时的持续中断.

尝试TDD和ATDD

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

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

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

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

在我的一个团队中，我们有一个非常快的开发人员，特别是在小功能上. 在代码审查期间，他会得到很多评论, 但我们的Scrum管理员和我认为这是缺乏经验. 然而，当他开始编写更复杂的功能时，问题变得更加明显. 他开发了一种模式，即在代码完全准备好之前将其传递给测试. 这种模式通常是在开发过程缺乏透明度的情况下开发的.g.，不清楚不同的人在一项给定的任务上花了多少时间.

有时, 开发人员急于完成他们的工作，试图尽快获得功能，并将质量“外包”给测试人员. 这样的设置只会将瓶颈进一步推向冲刺阶段. 质量保证 (QA)是最重要的安全网 这个团队有, 但这也意味着QA的存在可以让开发者放弃对质量的考虑.

许多现代 项目管理工具 是否有能力跟踪Scrum或看板上任务卡的移动. 在我们的例子中, 我们使用Jira来分析问题开发人员的任务发生了什么，并与团队中的其他开发人员进行比较. 我们发现:

• 他的任务花费的时间几乎是我们电路板测试栏的两倍;
• 他的任务通常会被QA退回到第二轮或第三轮修复中.

所以除了测试人员必须在他的任务上花费更多时间外，他们还必须多次执行任务. Our opaque process made it seem like the developer was really fast; however, 当我们考虑到测试时间时，事实证明这是错误的. 来回移动用户故事显然不是一种精益方法.

为了解决这个问题，我们首先与这位开发者进行了坦诚的讨论. 在我们的案例中，他根本没有意识到他的工作模式有多么有害. 这只是他在以前的公司习惯的工作方式, 哪个具有较低的质量要求和较大的测试人员池. 在我们的谈话之后，在与我们的Scrum主管的结对编程会话的帮助下, 他逐渐转向更高质量的发展方式. 由于他的快速编码能力, 他仍然是一名优秀的演员, 但是消除了QA过程中的“浪费”使得整个测试过程更加敏捷.

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

非敏捷项目中的测试包括测试分析等活动, 测试设计, 测试执行. 这些活动是连续的，需要大量的文档. 当公司过渡到敏捷时, 通常, 这种转变主要关注于开发人员，而不是测试人员. 他们不再创建大量的文档(传统测试的支柱)，而是继续执行手动测试. 然而，手动测试是缓慢的，并且通常不能应付敏捷的快速反馈循环.

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

自动化测试是与被测试的代码库相似的软件代码片段. 这意味着编写自动化测试的人需要技术技能才能成功. 在不同的团队中实现自动化测试的方式有很多不同的变体. 有时开发人员自己承担测试人员的角色，并为每个新特性增加测试代码库. 在其他团队中, 手工测试人员学习使用测试自动化工具，或者聘请有经验的技术测试人员来自动化测试过程. 无论团队选择哪条路径，自动化都会导致更加敏捷的测试.

管理测试优先级

在非敏捷软件开发中，测试人员通常是按项目分配的. 然而, 随着敏捷和Scrum的出现, 同样的QA专业人员在多个项目中工作已经变得很常见. 当测试人员优先考虑一个团队的发布测试而不是另一个团队的冲刺计划会议时，这种重叠的责任会在时间表中产生冲突，并导致测试人员错过关键的仪式.

测试人员有时在多个项目中工作的原因是显而易见的——很少有一个固定的测试任务流来填补全职角色. 因此, 可能很难说服涉众为团队分配专门的测试资源. 然而, 当测试人员不参与测试活动时，他们可以做一些合理的任务来填补他们的停机时间.

客户端支持

一种可能的设置是让测试人员将他们的sprint停机时间用于帮助客户支持团队. 通过不断面对客户的问题, 测试人员对用户体验以及如何改进有更好的理解. 他们能够在规划会议期间为讨论做出贡献. 此外, 他们在测试过程中变得更加专注，因为他们更熟悉客户如何实际使用他们的软件.

产品管理

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

测试自动化

正如我们之前讨论过的，手动测试通常不如自动化测试. 在这种情况下, 自动化的推动可以与测试人员将他们的全部注意力投入到团队中并利用他们的业余时间学习使用测试自动化工具相结合 硒.

总结:质量敏捷测试

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

• 形式化发布测试周期过程.
• 授权测试人员使用部署工具.
• 试验测试驱动开发和验收测试驱动开发.
• 通过跟踪任务卡的移动来发现低效率.
• 将测试自动化添加到QA团队的技能集中.
• 管理测试人员优先级.

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