敏捷测试宣言与原则解读
读完需要
6分钟速读仅需 2 分钟
ThoughtWorks 几位资深同事根据多年敏捷团队的实战经验总结出来敏捷测试宣言和敏捷测试的 10 条原则，在此与大家作一下解读。
👀
敏捷测试宣言
解读
敏捷测试宣言表达的是我们对于敏捷测试的信仰和价值观，分别包括流程、团队合作、自动化和核心价值观四个维度。
在以往软件发布周期较长、需求变化频率较低、不同角色间的合作壁垒较高的环境下，传统的开发模式所采用的孤立的测试阶段、测试人员独立把关质量、回归式的全量自动化测试和质量检测，是有其价值的。但是，在敏捷开发模式下，敏捷测试则更强调左侧的价值观。
全程的测试介入
敏捷测试提倡测试左移和右移，从软件生命周期的早期（左侧）一直到产品发布上线后的生产环境，都需要有测试的介入和测试活动的开展。
左移是为了更好的理解和澄清需求，以减少需求理解不一致导致的浪费；而右移是充分利用生产环境的数据来优化开发和测试流程，以增强软件系统应对各种不可预测性的能力。
左移和右移并不仅仅是将测试活动移到两侧端点，更强调的是每个环节的参与，也就是全程测试介入，这是从流程上保障高质量软件交付的关键。
团队整体对质量负责
敏捷提倡全功能团队，团队的角色之间分工不再那么明确，不同角色间的协作更加密切，团队一起为质量负责，是敏捷测试需要遵循的指导性原则。
团队需要对质量目标有统一认识，在敏捷软件生命周期的每个环节有不同角色的共同参与，实现质量目标是每个角色的职责。
持续性的精准自动化测试
自动化测试是敏捷测试的基础，是快速反馈的必要手段。自动化测试不能一味的追求覆盖率，而是要追求有目的的精准覆盖。也就是说，自动化测试首先必须是有效的，是基于业务风险考虑的，才能真正实现快速反馈。
自动化测试需要能够在持续集成流水线上持续的运行，为每次代码提交提供反馈，以确保系统功能不会因为新代码的提交而被破坏；同时，随着功能的不断迭代，自动化测试需要相应的更新、增加，确保新功能是有有效自动化测试覆盖的。
质量内建
质量内建是敏捷测试的核心，需要将测试全程介入、团队为质量负责和持续精准的自动化测试结合起来，在敏捷软件生命周期的每个环节做好缺陷的预防，把质量融入到产品的开发构建中。
👀
敏捷测试原则
我们的目标在于和团队一起尽快地交付高质量软件。
测试人员尽早参与软件早期阶段，与所有团队角色合作，通过实例化需求，确保对业务价值理解的一致性。
测试人员关注生产环境状态，收集数据，指导和优化前期的分析、开发和测试。
测试人员和开发人员同处一个产品项目团队，而不是独立的测试团队或部门。
测试人员负责探索性测试，和开发人员结对，设计、实现和维护自动化测试。
自动化测试在流水线中持续精准执行，快速发现每次代码提交对于已有功能的影响。
测试数据对于自动化测试是充分的，并能按需获得。
测试活文档化，和代码一起，作为知识资产进行版本化管理。
自动化测试需要有效的分层。
预防缺陷，而不是关注缺陷的数量。
解读
敏捷测试需要遵循如下 10 条原则：
1. 我们的目标在于和团队一起尽快地交付高质量软件。
敏捷测试的目标，所有的测试活动都围绕这一目标开展。敏捷测试人员要有思维上的转变，不再是关注于发现更多的缺陷，而是思考和采取相应的措施以帮助团队更快、更高质量的交付软件。
2. 测试人员尽早参与软件早期阶段，与所有团队角色合作，通过实例化需求，确保对业务价值理解的一致性。
测试左移，团队合作，需求的清晰表达，确保团队在做对的事情，拥抱变化的同时能够少走弯路。
3. 测试人员关注生产环境状态，收集数据，指导和优化前期的分析、开发和测试。
测试右移，由于生产环境的特殊性，并不能将测试活动简单右移到生产环境，只能通过收集和分析生产环境的数据，利用这些数据来优化开发、测试和业务价值，让生产环境和开发过程形成良性环路。
4. 测试人员和开发人员同处一个产品项目团队，而不是独立的测试团队或部门。
测试人员属于开发团队的一员，推倒角色之间的沟通壁垒，测试人员与开发人员进行密切的合作。
5. 测试人员负责探索性测试，和开发人员结对，设计、实现和维护自动化测试。
自动化测试不只是测试人员的职责，单元测试和接口测试主要由开发人员负责，而界面层自动化测试同样需要开发人员一起参与设计、实现和维护，这样才更高效；同时，可以让测试人员抽离出来去做更有价值的事情——探索性测试。
6. 自动化测试在流水线中持续精准执行，快速发现每次代码提交对于已有功能的影响。
自动化测试需要在持续集成流水线中运行，并且做到能够按需精准执行，在追求完备覆盖的同时还能高效运行，快速提供反馈。
7. 测试数据对于自动化测试是充分的，并能按需获得。
自动化测试应该有完备的数据集，包括正常和异常情况的覆盖、满足不同环境或不同平台的执行要求等；同时，需要有完善的数据创建和管理方案，确保不同需求下的自动化测试能够获得相应的测试数据。
8. 测试活文档化，和代码一起，作为知识资产进行版本化管理。
需求文档要跟自动化测试关联，变成可执行的活文档，并且要跟产品代码一起作为知识资产进行版本化管理。
9. 自动化测试需要有效的分层。
自动化测试要根据不同的测试对象进行有效分层。越往底层的测试实现成本更低、执行更高效、定位更准确，但覆盖范围有限，不能跟业务很好的关联；越往顶层的测试越接近业务、更能体现业务价值，但是执行速度、稳定性较差、定位问题较难。需要根据系统要求、技术架构等项目具体情况规划每层测试的合理占比，不能盲目的追求多而全的覆盖。
10. 预防缺陷，而不是关注缺陷的数量。
质量内建是敏捷测试追求的核心价值观，而质量内建本质上就是缺陷预防。敏捷测试需要团队把重心放在预防缺陷上，提高软件的内建质量，而只关注缺陷数量、甚至把缺陷数量当做考核指标的情况是违背这一核心价值观的。当然，对缺陷数量趋势的正确跟踪和对缺陷根因的深入分析，是帮助预防缺陷的有效手段，是值得推荐的。
欢迎关注我的《ThoughtWorks的敏捷测试》系列直播课程的文字总结：