敏捷测试：留住客户的最佳方式

引言

敏捷测试是一种不断发展的方法，我们过去 3 到 5 年一直在关注。这种方法之所以受欢迎，主要归功于几个原因，例如产品开发生命周期和进入市场周期（GTM）在不断变化的业务动态下正在缩短。每个人都希望尽快将产品推向市场，尽快抢占客户份额，以控制不断变化的业务动态。敏捷性似乎正在为这种短期的 GTM 带来红利，并提供快速的投资回报。

在本文中，我将讨论敏捷测试与传统的测试方法有何不同。为此，让我们看一下敏捷测试的简单定义和敏捷测试背后的原则。

“敏捷”这个词本身就意味着“快速行动”，测试也是如此。在敏捷测试中，传统的测试实践不适用于等待整个开发周期活动完成，而测试与开发紧密相连，并与代码开发并行进行。

敏捷测试背后的一些原则 [参考：敏捷宣言] 是

• 通过快速敏捷 scrum (sprint) 流程、持续交付有用的软件来满足客户的需求
• 经常交付可运行的软件（几周而不是几个月）
• 可运行的软件是衡量进度的主要标准
• 即使是测试需求的后期变更也欢迎
• 业务人员和开发人员之间密切的日常合作
• 面对面的交流是最好的沟通方式
• 项目围绕积极进取、应该受到信任的个人而构建
• 持续关注技术卓越和良好的设计
• 简单
• 自组织团队
• 定期适应不断变化的情况

现在让我们从这个定义和原则中得出敏捷测试的优势

• 从定义中得出的要点#1： “敏捷”这个词本身就意味着“快速行动”

  在当今匆忙的世界中，利益相关者和客户希望快速获得投资回报。他们不想等待更长的时间来获得一个功能齐全的产品。因此，如今一种新的软件测试范式正在获得动力，即 Scrum 方法。在敏捷 scrum (sprint) 流程中，项目被分解成要开发的小组件，然后在称为 sprint（小周期）的特定时间片中进行测试。每个功能都应该在指定的小时间片中开发和测试。

• 从定义中得出的要点#2：在敏捷测试中，不适用传统的测试实践

  在基于阶段的传统开发过程中，每个阶段都会经过彻底而冗长的验证，然后再触发下一个阶段，而敏捷测试并不强调严格定义的测试程序，而是侧重于根据新开发的程序进行迭代测试，直到从最终客户的角度实现质量。换句话说，重点从“测试人员作为质量警察”转移到更像“整个项目团队致力于展示质量”。

• 从原则中得出的要点#3：自组织团队

  跨职能团队合作是敏捷测试的核心。没有“我的工作”、“我完成了我的工作”和“你的工作”。在敏捷团队中，我们只发现“我们的工作”，“我们完成了我们的 Sprint”。个人将有分享技术知识的倾向。敏捷成员随时可供团队成员使用，而不是锁在密室里。团队负责人将始终激励团队并创造一个支持性的学习环境。团队将始终以 sprint 为导向，并经常讨论 sprint 的顺利运行。敏捷团队的工作是围绕挑战进行自组织，而管理层的工作是消除自组织的障碍。

• 从原则中得出的要点#4：业务人员和开发人员之间密切的日常互动与合作

  开发团队、测试团队、业务分析师和利益相关者之间的团队成员之间必须存在良好的沟通。客户和交付团队之间必须有高度协作的互动。这意味着更大的沟通带宽。

• 从原则中得出的要点#5：可运行的软件是衡量进度的主要标准

  衡量进度的基本标准是衡量已完成的事情。当软件成功测试并交付时，软件就完成了。软件进度不是“70% 的编码完成”。当软件经过测试并被（关键）最终用户接受时，软件就完成了。可运行的软件定义为经过测试并向最终用户提供价值的软件

当正确、充分地实施敏捷测试流程时，它有很多好处。通过提前为上述领域做好规划，获得这些好处，使您的软件获得成功。反过来，客户会欣赏结果或更新——并且可以快速响应任何潜在问题。该团队可以在短时间内交付高价值的软件功能，让每个人都掌握不断变化的业务状况。