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

Fierce competition is pressuring teams to constantly deliver new product updates, 但这有时是有代价的, 包括减少对测试的关注. 有些人，比如罗伯·梅森，甚至更进一步，认为 敏捷正在扼杀软件测试. 最近, Facebook已经将其口号从“快速行动，打破陈规”改为“快速行动，稳定基础设施”，试图解决牺牲质量的诱惑.

So, how can testing be better integrated into the new world of 敏捷 software development? 敏捷测试过程.

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

• 测试要频繁得多，
• 测试 relies less on documentation and more on team member collaboration, and
• Some testing activities are undertaken not only by 测试人员 but also by developers.

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

形式化发布测试周期过程

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

Many teams only do a single build after each sprint, which is not ideal for 敏捷 projects. 转向每周一次的发布可能是有益的, 逐渐过渡到每周多次构建. 在理想的情况下, 开发构建和测试应该每天进行, 这意味着开发人员每天都将代码推送到存储库，并且构建计划在特定时间运行. To take this one step further, developers would be able to deploy new code on demand. 要实现这个, teams can employ a continuous integration and continuous deployment (CI/CD) process. CI/CD限制了在主要发布当天构建失败的可能性.

当CI/CD和 测试自动化 相结合, 早期发现关键错误是可能的, enabling developers to have enough time to fix critical bugs before the scheduled client release. One of the principles of 敏捷 states that working software is the primary measure of progress. 在这种情况下, a formalized release cycle makes the testing process more agile.

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

One of the common friction points for testing is having the code deployed to a staging environment. This process depends on technical infrastructure which your team might not be able to affect. 然而, 如果有一定的灵活性, 可以为非技术人员(如测试人员或项目经理)创建工具，允许他们部署更新的代码库进行测试.

For example, on one of my teams, we used Git for version control and Slack for communication. 开发人员创建了一个可以访问Git的Slackbot, 部署脚本, 一个虚拟机. 测试人员能够使用从GitHub或Jira获得的分支名称ping bot，并将其部署在暂存环境中.

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

尝试TDD和ATDD

测试驱动开发 (TDD) is a type of software development process that puts a lot of emphasis on quality. Traditionally, a developer writes code and then someone tests it and reports if any bugs were found. 在TDD中，开发人员 编写单元测试 首先，在编写任何完成用户故事的代码之前. The tests initially fail until the developer writes the minimal amount of code to pass the tests. After that, the code is refactored to meet the quality requirements of the team.

验收测试驱动开发 (ATDD) follows a similar logic as TDD but, as the name implies, focuses on acceptance tests. 在这种情况下, acceptance tests are created prior to development in collaboration with developers, 测试人员, 请求者(客户端), 产品负责人, 业务分析师, 等.). 这些测试帮助团队中的每个人在编写任何代码之前了解客户的需求.

像TDD和ATDD这样的技术通过将测试过程移到开发生命周期的早期阶段，使测试更加敏捷. When writing test scenarios early on, developers need to understand the requirements really well. 这最大限度地减少了不必要的代码创建，并解决了开发周期开始时的任何产品不确定性. 当产品问题或冲突只在后期出现时, 开发时间和成本增加.

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

On one of my teams, we had a developer who was extremely fast, especially with small features. 在代码审查期间，他会得到很多评论, 但我们的Scrum管理员和我认为这是缺乏经验. 然而, as he started coding more complex features, the problems became more apparent. 他开发了一种模式，即在代码完全准备好之前将其传递给测试. This pattern typically develops when there is a lack of transparency in the development process—e.g.，不清楚不同的人在一项给定的任务上花了多少时间.

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

许多现代 项目管理工具 have the capabilities to track the movement of task cards on a Scrum or Kanban board. 在我们的例子中, 我们使用Jira来分析问题开发人员的任务发生了什么，并与团队中的其他开发人员进行比较. 我们发现:

• His tasks spent almost twice the amount of time in the testing column of our board;
• His tasks would much more often be returned from QA for a second or third round of fixing.

So apart from 测试人员 having to spend more time on his tasks, they also had to do it multiple times. Our opaque process made it seem like the developer was really fast; however, 当我们考虑到测试时间时，事实证明这是错误的. 来回移动用户故事显然不是一种精益方法.

为了解决这个问题，我们首先与这位开发者进行了坦诚的讨论. 在我们的案例中，他根本没有意识到他的工作模式有多么有害. 这只是他在以前的公司习惯的工作方式, 哪个具有较低的质量要求和较大的测试人员池. After our conversation and with the help of a few pair programming sessions with our Scrum master, 他逐渐转向更高质量的发展方式. 由于他的快速编码能力, 他仍然是一名优秀的演员, but the removed “waste” of the QA process made the whole testing process much more agile.

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

非敏捷项目中的测试包括测试分析等活动, 测试设计, 测试执行. 这些活动是连续的，需要大量的文档. 当公司过渡到敏捷时, 通常, 这种转变主要关注于开发人员，而不是测试人员. 他们不再创建大量的文档(传统测试的支柱)，而是继续执行手动测试. 然而, manual testing is slow and typically cannot cope with the fast feedback loops of 敏捷.

测试自动化是这个问题的一个流行的解决方案. 自动化测试使测试新的和小的特性变得更加容易, as the testing code can run in the background while developers and 测试人员 focus on other tasks. 此外, 因为测试会自动运行, 与手工测试工作相比，测试覆盖范围要大得多.

Automated tests are pieces of software code similar to the codebase that is being tested. This means that people writing automated tests will need technical skills to be successful. There are many different variations of how automated testing is implemented across different teams. 有时开发人员自己承担测试人员的角色，并为每个新特性增加测试代码库. 在其他团队中, 手工测试人员学习使用测试自动化工具，或者聘请有经验的技术测试人员来自动化测试过程. 无论团队选择哪条路径，自动化都会导致更加敏捷的测试.

管理测试优先级

With non-敏捷 software development, 测试人员 are usually allocated on a per-project basis. 然而, 随着敏捷和Scrum的出现, it has become common for the same QA professionals to operate across multiple projects. 当测试人员优先考虑一个团队的发布测试而不是另一个团队的冲刺计划会议时，这种重叠的责任会在时间表中产生冲突，并导致测试人员错过关键的仪式.

测试人员有时在多个项目中工作的原因是显而易见的——很少有一个固定的测试任务流来填补全职角色. 因此, it might be hard to convince stakeholders to have a dedicated testing resource allocated to a team. 然而, 当测试人员不参与测试活动时，他们可以做一些合理的任务来填补他们的停机时间.

客户端支持

One possible setup is to have the tester spend their sprint downtime helping the client support team. 通过不断面对客户的问题, the tester has a better understanding of the user experience and how to improve it. 他们能够在规划会议期间为讨论做出贡献. 此外, 他们在测试过程中变得更加专注，因为他们更熟悉客户如何实际使用他们的软件.

产品管理

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

测试自动化

As we have previously discussed, manual testing is often inferior to automation. 在这种情况下, 自动化的推动可以与测试人员将他们的全部注意力投入到团队中并利用他们的业余时间学习使用测试自动化工具相结合 硒.

总结:质量敏捷测试

使测试更加敏捷是许多软件开发团队现在面临的必然问题. 然而, quality should not be compromised by adopting a “test as fast as you can” mindset. 敏捷过渡必须包括向敏捷测试的转变, 有几种方法可以做到这一点:

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

每年，软件都在变得更好，用户的期望也在提高. 此外, as clients get used to high-quality products of top software brands like Google, 苹果, 和Facebook, 这些期望也会转移到其他软件产品中. Thus, the emphasis on quality is likely to be even more important in the coming years. 这些测试和整体 开发过程改进 能否使测试更加敏捷，并确保高水平的产品质量.