又一次，关于“敏捷测试”到底是什么的讨论热闹起来，小编自己经历过很长时间的实践，后来也开始辅导团队、企业实践敏捷测试，现在就跟大家分享一下这些经验。

敏捷软件测试领域的权威作品，无疑是名称最符合的《敏捷软件测试：测试人员与敏捷团队的实践指南》，原作名《Agile Testing: A Practical Guide for Testers and Agile Teams》，作者是Lisa Crispin和Janet Gregory，推荐大家阅读。

如下是小编的一些看法：

敏捷软件测试就是在敏捷方式下开展测试工作的方式，是一种方式，而不是测试的类型、范围或阶段。

所以敏捷测试的专家，一定是整个测试方式的专家，意味着要涵盖测试类型、测试范围、测试阶段这几个维度，那通常就是整体或全局的顾问了，可以看作是传统所说的“测试流程顾问”，但因为敏捷里面，测试跟开发和其他环节密不可分，所以这个“流程顾问”只懂测试是远远不够的。

通常业内把敏捷测试当作是一种类型，例如，把敏捷测试看作是功能测试之后、性能测试之前执行的一种类型的测试，这就是误解。

手工、自动的区分，测试出身的都不一定搞得清楚，更不要说非测试出身的了。涉及到探索式测试，就更容易混淆，手工、自动，通常是指执行的手段，探索，指的是测试的目的。这意味着手工的测试不一定就是探索式的，而探索式的测试也不一定就是手工的。

虽然敏捷到底意味着什么，业内也有争议，但较为广泛接受的是从需求到产品的全过程，更全的是从概念到现金（from concept to cash）的全过程。

让开发人员专注于开发，让测试工具（谷歌的工程生产力）人员专注于提供支持测试（和其他生产力活动）的工具，让测试人员专注于研究如何用工具快速高效地完成业务的验证，才是一个合理的模式

当然，取决于这三类人群的心智模式的距离，距离越近的，这三类人群的分隔越不清晰，也更容易一个人搞定所有。心智模式越远的，越需要清晰的界限，也即三类人员， 然后强调紧密合作。我这个理念，我觉得在《设计心理学》里是有共鸣的，我们能够做好工作，取决于我们每天所接触的东西，与我们要完成任务所需的概念模式，是容易建立关联、检测进度和获取反馈的。这就是我说的心智模式。

如果最终产品和代码或程序的理念很像，那么程序员搞定一切，一点问题没有，例如程序员开发给程序员用的工具，因为他们本身就是用户，所以程序员搞定从开发到测试的所有任务，一点问题都没有。

如果最终产品运行的概念模式和构成单元（代码）的心智模式差距很远，那么程序员就不可能搞定一切。例如，银行的对公业务，作为程序员，最熟悉的是代码和代码运行的概念模式，而对公业务的基础构造单元和概念模式，则与之有很大的差距，想要依靠程序员完成对最终产品的完美验证，几乎不可能，或者说，会带来分裂和效率问题，因为要想形成对代码或业务的高度理解，是试图同时追求知识的广度和深度，要么就是不可能做到，要么就是浪费，带来极大的心智切换成本。

尤其是当涉及人员很多的时候，必须考虑分工。开发专注编写代码，但从需求到设计（需要实现哪些代码）的过程的合理性就很重要；测试专注理解业务从而合理地验证产品功能，但从头介入防患于未然就很重要；而提高效率则需要靠提供工具，工具需要开发，属于代码的概念模式，而工具的使用者又是我们希望更侧重业务的测试人员，属于业务的概念模式，好在这两块都不需要非常深的理解，所以我们需要专门的工具开发人员。这种分隔，就在不同类型的专业（=专职，请注意理解）人士和知识的深度、广度之间找到了平衡，当然，最重要的是一定要紧密协作，才能够解决问题。

另一方面就是原来那么多级的测试，如何处理，敏捷的思路是要针对更小的需求颗粒度，在迭代内完成所有相关类型、范围的测试（阶段跟时间有关，敏捷方式跟传统不同，打破了时间安排，所以阶段是完全不同的）。

我们解决问题的突破口在于，是否一定要“一个人”完成所有这些测试，还是“多个人”协作完成所有这些测试？以及，是否是同一个人完成这些测试的“生产”（=设计编写）和“消费”（=执行检验），还是可以分工以及借助其他技术手段完成。找到这些问题的答案，就是实践敏捷测试的关键。

如下是这种人力分布方式的一个例子：

而这些答案的知识，是存储在人脑之外的外部世界的，也即是组织的相关环境。我们需要通过外部世界的知识，来唤起我们脑中的信息，消化之后，得出我们可以运用于这个组织的具体的敏捷测试模式或流程。（这段话也是借鉴了《设计心理学》里面的描述）。（徐毅原创）

又一次，关于“敏捷测试”到底是什么的讨论热闹起来，小编自己经历过很长时间的实践，后来也开始辅导团队、企业实践敏捷测试，现在就跟大家分享一下这些经验。

敏捷软件测试领域的权威作品，无疑是名称最符合的《敏捷软件测试：测试人员与敏捷团队的实践指南》，原作名《Agile Testing: A Practical Guide for Testers and Agile Teams》，作者是Lisa Crispin和Janet Gregory，推荐大家阅读。

如下是小编的一些看法：

敏捷软件测试就是在敏捷方式下开展测试工作的方式，是一种方式，而不是测试的类型、范围或阶段。

所以敏捷测试的专家，一定是整个测试方式的专家，意味着要涵盖测试类型、测试范围、测试阶段这几个维度，那通常就是整体或全局的顾问了，可以看作是传统所说的“测试流程顾问”，但因为敏捷里面，测试跟开发和其他环节密不可分，所以这个“流程顾问”只懂测试是远远不够的。

通常业内把敏捷测试当作是一种类型，例如，把敏捷测试看作是功能测试之后、性能测试之前执行的一种类型的测试，这就是误解。

手工、自动的区分，测试出身的都不一定搞得清楚，更不要说非测试出身的了。涉及到探索式测试，就更容易混淆，手工、自动，通常是指执行的手段，探索，指的是测试的目的。这意味着手工的测试不一定就是探索式的，而探索式的测试也不一定就是手工的。

虽然敏捷到底意味着什么，业内也有争议，但较为广泛接受的是从需求到产品的全过程，更全的是从概念到现金（from concept to cash）的全过程。

让开发人员专注于开发，让测试工具（谷歌的工程生产力）人员专注于提供支持测试（和其他生产力活动）的工具，让测试人员专注于研究如何用工具快速高效地完成业务的验证，才是一个合理的模式

当然，取决于这三类人群的心智模式的距离，距离越近的，这三类人群的分隔越不清晰，也更容易一个人搞定所有。心智模式越远的，越需要清晰的界限，也即三类人员， 然后强调紧密合作。我这个理念，我觉得在《设计心理学》里是有共鸣的，我们能够做好工作，取决于我们每天所接触的东西，与我们要完成任务所需的概念模式，是容易建立关联、检测进度和获取反馈的。这就是我说的心智模式。

如果最终产品和代码或程序的理念很像，那么程序员搞定一切，一点问题没有，例如程序员开发给程序员用的工具，因为他们本身就是用户，所以程序员搞定从开发到测试的所有任务，一点问题都没有。

如果最终产品运行的概念模式和构成单元（代码）的心智模式差距很远，那么程序员就不可能搞定一切。例如，银行的对公业务，作为程序员，最熟悉的是代码和代码运行的概念模式，而对公业务的基础构造单元和概念模式，则与之有很大的差距，想要依靠程序员完成对最终产品的完美验证，几乎不可能，或者说，会带来分裂和效率问题，因为要想形成对代码或业务的高度理解，是试图同时追求知识的广度和深度，要么就是不可能做到，要么就是浪费，带来极大的心智切换成本。

尤其是当涉及人员很多的时候，必须考虑分工。开发专注编写代码，但从需求到设计（需要实现哪些代码）的过程的合理性就很重要；测试专注理解业务从而合理地验证产品功能，但从头介入防患于未然就很重要；而提高效率则需要靠提供工具，工具需要开发，属于代码的概念模式，而工具的使用者又是我们希望更侧重业务的测试人员，属于业务的概念模式，好在这两块都不需要非常深的理解，所以我们需要专门的工具开发人员。这种分隔，就在不同类型的专业（=专职，请注意理解）人士和知识的深度、广度之间找到了平衡，当然，最重要的是一定要紧密协作，才能够解决问题。

另一方面就是原来那么多级的测试，如何处理，敏捷的思路是要针对更小的需求颗粒度，在迭代内完成所有相关类型、范围的测试（阶段跟时间有关，敏捷方式跟传统不同，打破了时间安排，所以阶段是完全不同的）。

我们解决问题的突破口在于，是否一定要“一个人”完成所有这些测试，还是“多个人”协作完成所有这些测试？以及，是否是同一个人完成这些测试的“生产”（=设计编写）和“消费”（=执行检验），还是可以分工以及借助其他技术手段完成。找到这些问题的答案，就是实践敏捷测试的关键。

如下是这种人力分布方式的一个例子：

而这些答案的知识，是存储在人脑之外的外部世界的，也即是组织的相关环境。我们需要通过外部世界的知识，来唤起我们脑中的信息，消化之后，得出我们可以运用于这个组织的具体的敏捷测试模式或流程。（这段话也是借鉴了《设计心理学》里面的描述）。（徐毅原创）