根据Capgemini的年度世界质量报告，42%的受访者认为“缺乏专业测试经验”导致实施敏捷开发的测试遭到障碍。虽然敏捷的引入可更快实施软件开发，但在某些情况下，可能会影响最终质量。
团队面临着定期提供新产品更新的压力，但这是有代价的，包括对测试的关注度减少。有些人，比如罗伯·梅森（Rob Mason），声称敏捷正在破坏软件测试。为了克服妥协质量的诱惑，面子书最近将其标语从“快速行动并不在意代价”改为“使用可靠的基础设施快速行动”。
那么，如何测试导入敏捷软件开发的新世界呢？敏捷的测试。
传统测试非常耗时，并且依赖于大量文档。敏捷测试是一种遵循敏捷软件开发概念的测试方法。
- 测试以更频繁的方式进行
- 测试较少依赖于文档，而更多地依赖于团队成员的参与，以及
- 某些测试任务不仅由测试人员执行，还由开发人员执行
在过去的七年里，我帮助许多公司迁移到敏捷测试，并与测试人员合作改进他们的程序，确保与新方法保持一致。在这篇文章中，我将提供我在更好的敏捷测试之旅中发现的一些最有用的东西。虽然敏捷方法中的速度和质量之间总是存在紧张关系，但本文将介绍一些可用于在不牺牲敏捷性的情况下提高测试质量的方法。此处列出的大多数建议都需要团队参与，因此让开发人员和测试人员都参与规划将是有利的。
创建正式的发布测试周期流程
缺乏发布测试周期、发布时间表或不规则的测试请求是测试的其中问题。按需测试请求使质量保证流程复杂化，尤其是在测试人员管理大量项目时。
许多团队在每次试验后只执行一次构建，这对于敏捷项目来说是低效的。从每周一次的版本并逐步切换到每周多个版本可能比较有效。理想情况下，开发构建和测试应该每天进行，这意味着开发人员每天都会将工作上传到存储库，并且在指定时间运行构建计划。开发人员从而更进一步按需发布新代码。团队可以使用持续集成和持续部署 （CI/CD） 方法来实现此目的。CI/CD 可降低在重要版本发布当天生成失败的可能性。
集成 CI/CD 和测试自动化后，可以及早检测到关键缺陷，从而使开发人员有足够的时间在把计划发布在客户端之前解决严重错误。根据敏捷原则之一，工作软件是进步的关键指标。固定的发布周期使测试过程在此环境中更加灵活。
为测试人员提供对部署工具的访问权限
将代码推送到过渡环境可能使测试人员互相争执。此过程取决与技术基础结构而您的团队无法将其影响。但是，如果有任何回旋余地，并为非技术人员（如测试人员或项目经理）开发解决方案，那就是让他们能够被分发到修订后的代码库以自行测试。
例如，在我的一个团队中，我们使用 Git 进行版本控制，及使用 Slack 进行通信。开发人员构建了一个包含 Git、部署脚本和一个虚拟机的 Slackbot。测试人员能够使用 GitHub 或 Jira 分支控制机器人，并将其部署在过渡环境中。
当测试人员不得不要求开发人员部署分支进行测试时，此解决方案避免了无效通信和中断，从而为开发人员节省了大量时间。
使用测试驱动开发和验收测试驱动开发进行测试
测试驱动开发 （TDD） 是一种优先考虑质量的软件开发方法。传统上，开发人员开发代码，然后有人对其进行测试并报告发现的任何问题。TDD要求开发人员在开发任何代码之前执行单元测试以完成用户叙述。测试最初会失败，直到开发人员编写通过测试所需的最少代码。之后，将代码重构以匹配团队的质量标准。
验收测试驱动开发（ATDD）采用与TDD类似的理念，但专注于验收测试。在这种情况下，验收测试是在开发之前与开发人员，测试人员和请求者（客户，产品所有者，业务分析师等）协调准备的。在生成任何代码之前，这些测试可帮助团队中的每个人了解客户的需求。
TDD 和 ATDD 技术通过在开发生命周期的早期引入测试流程，使测试更加敏捷。开发人员在开发测试用例之前必须彻底掌握需求。这减少了日后需要添加额外代码，同时也解决了开发周期开始时的任何产品不确定性。当产品问题或争议在开发过程的后期才出现时，开发时间和费用就会增加。
随时跟进工作计划进度可以帮助您发现效率低下的问题
我团队中有一个开发人员，他的速度非常快，特别是在处理小事情上。在代码审查期间，他会收到很多评论，但是我们的Scrum大师和我一开始把这归结为缺乏经验。然而，当他开始创建更复杂的功能时，问题变得更加明显。他已习惯在代码没完全准备好之前将代码发送测试。这种模式通常出现在缺乏开放性的开发过程中，例如当不清楚各种员工在特定工作上花费了多少时间时。
开发人员可以加快他们的工作速度，以便尽快推出功能，并将质量品质推卸给测试人员。像这样的设置只会将问题变得更严重。质量保证（QA）是团队最关键的安全网，但它的存在可能会使开发人员过度依赖并忽略质量问题。
许多当前的项目管理软件在Scrum或Kanban上跟进工作计划进度。而我们使用Jira来检查开发人员在任务中发生的情况，并将其与团队中的其他开发人员进行比较。我们发现：
- 他的任务在我们董事会的测试专栏上花费的时间几乎是我们的两倍;
- 他的任务更频繁地从质量保证返回进行第二轮或第三轮修复。
因此，除了在他的职责上花费额外的时间之外，测试人员还必须多次重复检测。我们的不透明方法使我们认为开发人员效率高;然而，当我们考虑测试时间时，这被证明是不准确的。来回不断的测试显然不是一种精益策略。
为了开始解决这个问题，我们与这位开发人员进行了公开对话。在此情况下，他只是没有意识到他的工作习惯是多么有害。这只是他在前雇主的工作方式，该雇主的质量标准较低且测试人员较多。在我们的聊天之后，他最终转向了更高质量的开发方法，并得到了与我们的Scrum大师进行几次编程会议的协助。由于他的快速编码能力，他仍然是一个高绩效者，但是避免浪费在质量保证过程中的时间使整个测试过程更加灵活。
应将测试自动化添加到质量保证团队的技能之一
在非敏捷项目中，测试包括测试分析、测试设计和测试执行等任务。这些是需要重要文档的任务。当一家公司转向敏捷时，这种转变通常集中在开发人员身上，而不是测试人员身上。他们停止生产综合文档（传统测试），但持续进行手动测试。另一方面，手动测试很慢，往往跟不上敏捷的反馈结果。
此问题的典型解决方案是测试自动化。由于测试脚本可以自行运行，开发人员和测试人员则专注于其他职责，因此自动化测试使测试新的和次要的改革变得更加容易。此外，由于测试是自动执行的，因此测试覆盖率可能明显大于手动测试工作。
自动测试相当于所测试代码库的软件代码块。这意味着那些编写自动化测试的人将需要技术能力才能成功。在各个团队中完成自动化测试的方式存在一些差异。对于每个新功能，开发人员可以承担测试人员的工作并扩展测试代码库。手动测试人员经过培训，可以在其他团队中使用测试自动化技术，或者招募专家技术测试人员来自动化测试过程。无论团队选择哪种选项，自动化都会带来明显更敏捷的测试。
管理测试优先级
在非敏捷软件开发中，测试人员通常是按项目分配的。然而，随着敏捷和Scrum的出现，同一个质量保证人员在许多项目上工作已经成为一种典型。当测试人员将一个团队的发布测试优先于另一个团队的测试计划时，这可能会导致日程问题，并导致测试人员错过关键仪式。
测试人员从事众多项目的明显原因是，很少有一致的测试流程以满足全职功能。因此，说服利益相关者为团队提供专用的测试资源可能很困难。但是，测试人员在不参与测试操作的情况下可以完成某些适当的工作。
对客户端的支持
一个可行的例子就是测试人员利用停机时间用于协助客户支持人员。通过反复面对客户端问题，测试人员可以更好地掌握用户体验以及如何增强用户体验。他们可以参加规划会议并作出贡献。此外，随着他们越来越熟悉客户如何使用他们的产品，他们在整个测试过程中变得更加专注。
产品管理
调节测试人员优先级的另一种方法是让他们成为进行手动测试的初级产品经理。由于初级产品经理花费大量时间了解用户的需求，因此对大多数工作都有广泛的了解，因此这也是填补测试人员以外的工作的一种潜在方法。
自动化测试
如前所述，手动测试通常不如自动化。在这种情况下，自动化的驱动力可使测试人员将全部注意力集中在团队上，并利用他们的空闲时间学习使用Selenium等测试自动化技术。
质量敏捷测试摘要
使测试更加敏捷是许多软件开发团队不可避免的需求。但是，采用“快速测试”的方法不应牺牲质量。敏捷过渡必须涉及对敏捷测试的更改，并且有很多方法可以做到这一点：
- 创建正式的发布测试周期流程
- 为测试人员提供对部署工具的访问权限
- 使用测试驱动开发和验收测试驱动开发进行测试
- 随时跟进工作计划进度可以帮助您发现效率低下的问题
- 应将测试自动化添加到质量保证团队的技能之一
- 管理测试优先级
该软件逐年改进，用户期望值不断提高。此外，当客户习惯于谷歌、苹果和面子书等领先软件公司的高质量商品时，他们的期望就会转向其他软件产品。因此，质量在未来几年可能会变得更加重要。这些对测试和更广泛的开发过程的更改可能会使测试更加敏捷，同时确保高水平的产品质量。
