敏捷BOB官方注册象限有了近20年的历史，但还是有很多在做敏捷项目的朋友也没听说过，或者听过但完全不知道是怎么回事。另外，知道敏捷BOB官方注册象限的业内同仁对它的评价也是褒贬不一。
最近听到几个稍感意外的说法，于是，想跟跟大家一起聊聊这个有名却又颇受争议的敏捷BOB官方注册象限。
01 敏捷BOB官方注册象限的演进史
深入了解一件事物，我们有必要了解它的历史演变过程。下文尽量按照时间先后顺序来分享敏捷BOB官方注册象限几个主流版本的演进，如有不准确的，烦请指出，先行感谢。
1. 原型：敏捷BOB官方注册矩阵（2003年）
Brian Marick于2003年最早提出“敏捷BOB官方注册矩阵”的概念，分四个象限，左右分别为支持编程和评价产品，上下分别为面向业务和面向技术。如下图所示：
这是一个专门针对敏捷BOB官方注册的矩阵，Brian指出左侧的BOB官方注册主要是为了支持编程所做的准备工作和确保一些问题的澄清，而右侧的BOB官方注册是关于验证和发现bug相关，左右两侧的“BOB官方注册”含义不同。
这个矩阵就是我们通常提到的敏捷BOB官方注册象限的原型。
2. Lisa和Janet的敏捷BOB官方注册象限第一版（2008年）
Lisa Crispin和Janet Gregory合著的第一本关于敏捷BOB官方注册的书《Agile Testing: A Practical Guide for Testers and Agile Teams》于2008年12月出版，中文版《敏捷软件BOB官方注册：BOB官方注册人员与敏捷团队的实践指南》出版于2010年10月。
基于Brian Marick的“敏捷BOB官方注册矩阵”，Lisa和Janet在书中正式提出了“敏捷BOB官方注册象限”，将其中左侧的“支持编程”改成了“支持团队”，将四个象限添加了编号Q1、Q2、Q3、Q4，在每个象限列出了不同的BOB官方注册类型，还标注了BOB官方注册是手动还是自动化等内容。如下图所示：
这个敏捷BOB官方注册象限版本是最为人熟知的版本，是《敏捷软件BOB官方注册》一书的核心，我们绝大多数人都是从该书中得知敏捷BOB官方注册象限的。
3. Michael Hüttermann的敏捷BOB官方注册象限（2011年）
Michael Hüttermann在敏捷BOB官方注册象限中心增加了“由外而内、无障碍协作”的内容，如下图所示：
其中“由外而内”的思想包括以下几个方面：
- 了解利益相关者和业务上下文
- 更有效地将项目预期与结果对应起来
- 构建更易使用的软件，使系统更易于部署和使用
- 不断加强与利益相关者目标的对齐
而“无障碍协作”主要指的是利用BDD（行为驱动开发）的方式来实现团队无障碍协作。
这部分内容可参考Michael的Agile Record文章查看详情。
4. Elisabeth Hendrickson的敏捷BOB官方注册象限（2012年）
Elisabeth Hendrickson 2012年在探讨“BOB官方注册人员思维”时也提出了一版敏捷BOB官方注册象限，如下图所示：
这个版本跟原来的敏捷BOB官方注册象限比，除了外观上不同以外，横轴也被修改了，变成了“确认”和“调查”，纵轴则还是“业务”和“技术”两个方向。
- 左上象限代表业务预期，可以是可执行（自动化）规范的形式，也可能由纸质原型或线框表示；
- 右上象限则是有助于调查产品外部质量风险的BOB官方注册，跟原始象限的探索式BOB官方注册、场景或易用性BOB官方注册类似；
- 右下象限突出了系统内部运行的风险。
5. Gojko Adzic的敏捷BOB官方注册象限（2013年）
Gojko Adzic对Lisa她们提出的敏捷BOB官方注册象限的有效性提出质疑，尤其是不同意横轴“支持团队”和“评价产品”这两个方向。于是，他提出了自己的敏捷BOB官方注册象限，左侧为“检查预期输出”，右侧是“分析未定义、未知和意外”，如下图所示：
这里不做过多解读，感兴趣的朋友请移步阅读Gojko的文章《Let's break the Agile Testing Quadrants》。
6. Lisa和Janet的敏捷BOB官方注册象限第二版（2014年）
Janet Gregory和Lisa Crispin合著的第二本敏捷BOB官方注册的书《More Agile Testing: Learning Journeys for the Whole Team》于2014年出版，中文版《深入敏捷BOB官方注册：整个敏捷团队的学习之旅》出版于2017年。书中介绍了新版的敏捷BOB官方注册象限。
这个版本的敏捷BOB官方注册象限在原版的基础上进行了修改，但整体的变化不是很大。改动部分主要有：
- 左侧由“支持团队”改成了“指导开发”；
- 去掉了各个象限的BOB官方注册是自动化、手动还是利用工具的描述
- 对各个象限的BOB官方注册活动也做了调整。
如下图所示：
在《深入敏捷BOB官方注册》一书中也有提到前面3、4、5个敏捷BOB官方注册象限的变种。
7. James Bach和Michael Bolton的敏捷BOB官方注册象限（2014年）
提出「快速软件BOB官方注册（RST，Rapid Software Testing）」的James Bach和Michael Bolton对敏捷BOB官方注册象限有很多的质疑，他们推出了RST的敏捷象限。如下图所示：
这个版本的象限主要是基于RST的理念，从外观上看跟原来的敏捷BOB官方注册象限很不一样，这里不做详细解读。感兴趣的朋友请自己研究两位作者的PPT去了解。
8. Lisa和Janet的敏捷BOB官方注册象限第三版（2019年）
2019年，Janet Gregory和Lisa Crispin合著的第三本敏捷BOB官方注册的书《Agile Testing Condensed》出版，书中再次对敏捷BOB官方注册象限进行了调整。
为了在DevOps文化领域应用敏捷BOB官方注册象限，这个版本主要针对DevOps理念对各个象限的BOB官方注册类型再次进行调整，比如在右上角添加了“生产环境下的BOB官方注册（Testing in Production）”等。如下图所示：
前面列举的是跟敏捷BOB官方注册象限相关的多个典型版本，肯定还会有很多其他的版本，这里就不一一调研阐述了。后面主要还是基于Lisa和Janet的敏捷BOB官方注册象限来探讨。
02 敏捷BOB官方注册象限的“不足”之处
敏捷BOB官方注册象限之所以出现这么多个版本，就是因为很多人都认为它是有很多不足之处的，从而搞出自己认为比较完美的BOB官方注册象限；另一方面，还有些人认为敏捷BOB官方注册象限没有那么大的价值，不会采用。
我是认可敏捷BOB官方注册象限的，并不认为真的有什么严重缺陷，也因此我给本节标题的“不足”加上引号。提出负面评价的多数情况是并没有真正理解清楚所致，同时，敏捷BOB官方注册象限提出者也是持开放态度，可以接受不同的人有不同的想法，模型框架并不是规定非黑即白的东西。
除了前面提到的各位大师的质疑之外，下面我们再来看看身边还有哪些对敏捷BOB官方注册象限的疑问或误解。
1. Q1-Q4是代表着BOB官方注册执行的某种顺序吗？感觉不太对啊？
对于这个顺序问题，有很多人对此产生疑问。其实，List他们的书中有明确指出，这四个象限的编号跟BOB官方注册执行顺序没有任何关系，完全是为了描述的方便。比如，Q1就是指面向技术的支持团队的BOB官方注册，用Q1来描述比那一长串文字要简单很多。
有意思的是，第三版象限中去掉了Q1-Q4的标识，其实我觉得继续保留挺好的。
2. 四个象限指出是自动化还是手动是有问题的
这里基于当时敏捷BOB官方注册象限里列出的BOB官方注册类型，在当时的环境下我们可以认为是问题不大的，只不过随着科技的发展，对不同BOB官方注册的执行发生了变化，几年后的确稍显过时。因此，我在给人讲这个象限的时候会说是需要自动化还是手动执行，不是死的规定，需要根据情况来看。
同样，第二版敏捷BOB官方注册象限中也去掉了这部分内容。保持开放，接受反馈，持续演进，这是很赞的。
3. 象限里提到的BOB官方注册有些根本不适用，没有参考价值
这一观点的误区在于认为四象限列了什么类型的BOB官方注册就有什么，没列的没有，列了的都有，不存在按需增减这种事情。
敏捷BOB官方注册象限的三个版本对于提到的BOB官方注册类型都有所不同，都是基于当时环境下列举的相对完整的集合，肯定不会适用于所有的团队，要真正使用需要做定制化裁剪或调整。现实世界太复杂了，不仅敏捷BOB官方注册象限如此，任何模型、框架都应该是如此，不可能是放之四海而皆准的。
4. 象限是不完整的，需要添加一些BOB官方注册类型，或者需要调整一些BOB官方注册所处象限
Lisa对此也有说明，原文链接在这里《Using the Agile Testing Quadrants》：
“The quadrants are merely a taxonomy to help teams plan their testing and make sure they have all the resources they need to accomplish it. There are no hard and fast rules about what goes in what quadrant. Think through them as you do your release, theme, and iteration planning, so your whole team starts out by thinking about testing first.（象限只是一种分类方法，用于帮助团队计划BOB官方注册，并确保获得完成BOB官方注册所需的所有资源。关于BOB官方注册活动进入哪个象限，没有硬性规定。需要在做发布和迭代计划时仔细考虑，以便整个团队对BOB官方注册引起重视。）”
当我们提到要持续性能BOB官方注册的时候，在左侧支持团队的BOB官方注册里可能就要开始考虑性能BOB官方注册了；同样，安全BOB官方注册也不仅是用工具来扫描的面向技术的BOB官方注册，我们需要考虑的更多的是跟业务相关的安全问题，我之前在“一页纸BOB官方注册策略”里提到的蓝鲸项目，就是把业务方向的安全BOB官方注册放在右上角的Q3里面。
并没有任何地方指出敏捷BOB官方注册象限列举的BOB官方注册类型是完备的，它给出的只是个参考。正因为这个原因，才会有三版不同的敏捷BOB官方注册象限，那是与时俱进不断完善的结果。
5. 我不会推荐敏捷BOB官方注册象限，那就像是一个字典，没什么大用
这个观点理解软件开发这个复杂环境下不能通过查字典的方式来确定需要采用的BOB官方注册，为啥就不能正确理解敏捷BOB官方注册象限的真正价值呢？
前面已经解释过了象限里的BOB官方注册类型不是死的，不是完备的，不是硬性规定，因此也就不是字典。
6. 敏捷BOB官方注册象限是乙方视角，其中有些BOB官方注册是要自证质量才会引入的实践
“四象限是乙方视角，那些UAT啊还有服务团队相关的一些BOB官方注册，是因为存在甲乙方的关系，我要自证我的质量，才会引入的实践……”
说实话，听到这个观点我挺意外的。这里存在两个方面的误解：
- 对某些BOB官方注册类型的误解
- 对象限的误解
6.1 对某些BOB官方注册类型的误解
认为某些BOB官方注册类型的命名是乙方视角，那是对BOB官方注册类型的误解，也是没理解相关BOB官方注册的真正价值，有必要说明一下。以UAT为例，先看看维基百科对UAT的定义：
我的理解跟维基百科定义是类似的：用户验收BOB官方注册主要是以用户的角度验收所开发的系统是否能够满足用户需求，这个BOB官方注册不一定是很严肃的一个BOB官方注册环节，根据不同团队以及产品的具体情况，会有不同；而且名称可以不叫UAT，但是事情的目的一样，比如betaBOB官方注册，也是验证用户的使用接受情况。
另外，这不存在甲方乙方视角问题，不管是甲方做还是乙方做，软件开发团队和用户（或业务方）基本都不会是一个团队，就算业技融合很好、且很难触及真实用户的团队，团队里边角色（帽子）还是会有不同，还是会需要那个所谓的SME（相对更精通业务领域的人）来从用户视角进行验收的，可能是PO、也可能是BOB官方注册人员，或团队其他角色。
当我们理解这个BOB官方注册实践背后的真正价值，认为这个事情是需要做的，就不会产生这样的误解了。
6.2 对象限的误解
另一个方面的误解跟前面的3、4、5的观点有些类似，同样也认为象限里列举的BOB官方注册类型就是固定不变的，前面已经解释过，这是没有理解象限的真正含义。
如果正确理解四象限的意义，也就不会有甲方或乙方视角问题了，事情很简单，如果觉得这些名称属于乙方视角，可以根据自己的语境来定义自己认为适合的BOB官方注册就好了。
03 敏捷BOB官方注册象限的正确使用方式
了解了敏捷BOB官方注册象限各个不同的版本的演进过程，下面来总结一下它的正确使用方式：
1. 敏捷BOB官方注册象限不是规则，而是BOB官方注册策略制定的指南
象限提供四个不同的思考维度，给团队制定BOB官方注册策略提供参考分类方法，这是象限的伟大之处，是核心所在。它能够帮助团队在制定策略的时候全面思考，从而制定出合适的策略。
推荐的使用方式是在制定BOB官方注册策略的时候，让团队讨论可能需要的所有类型的BOB官方注册活动，做到尽量的全面。通常可以在大白纸上画出空的象限图，团队一起头脑风暴，使用便签在各象限贴上相应的活动，如果发现某个BOB官方注册活动的位置不对，方便随时移动。
2. 敏捷BOB官方注册象限不是银弹，不能生搬硬套
就像BOB官方注册金字塔不是银弹一样，敏捷BOB官方注册象限也不是银弹，不能直接套用三个象限版本中的任何一个，也不能直接套用别的团队的象限。前面提到过象限的BOB官方注册类型不是全集，也不能当做字典来查询。
正确的使用方式是参考象限模型的分类法，需要根据自己项目团队的情况进行定制化，构建自己团队适配的象限。并且，定制化的象限图也不是一成不变的，而是需要根据不同时期团队的不同特点进行调整优化，持续演进。
另外，注意更新工具箱。虽然前两版在象限划分思路上没有什么问题，但最好参考第三版，毕竟它是比较新的。
3. 敏捷BOB官方注册象限不仅适用于敏捷开发模式
虽然叫做“敏捷”BOB官方注册象限，也是源于敏捷开发模式下对各种BOB官方注册类型的思考，但其实不限于敏捷，对瀑布等其他开发模式同样适用。
象限的精华是几个象限维度的划分，是指引策略的方向，不管什么开发模式，从这几个维度来思考都是没有问题的，只是不同维度下具体的BOB官方注册类型可能会稍有差异，根据团队实际情况考虑就行。
4. 敏捷BOB官方注册象限还可作为技能集参考
有人将敏捷BOB官方注册象限用作新人技能集的评估参考，这是很有意思的事情。其实，我们制定策略考虑到的不同BOB官方注册活动，就需要有相应的技能去实施，所以这么用也是完全没问题的。同样，除了评估新人，也可以当成能力模型，帮助指导团队人员的能力建设。
04 写在最后
任何框架、模型、工具都不是用来生搬硬套的，需要了解背后真正的逻辑，理解其真正的价值所在。
敏捷BOB官方注册象限的真正价值是四个象限的思考维度，不要过多关注每个象限里到底有哪些BOB官方注册活动。记住这一点至关重要！
05 推荐阅读
下面文章有关于敏捷BOB官方注册象限的更多详情，推荐阅读：