在看过了一些有些的关于敏捷测试的文章（比如这篇），听了许多人在谈论敏捷测试后，我开始意识到敏捷测试跟自己一开始的理解并不太一致。
从一个问题问起
你认为什么样的团队适合打造成敏捷测试团队？
不知道你看到这样的问题时，会怎样去想？或者不妨你可以用几秒钟的时间来想一想这个问题。倒计时，5，4，3，2，1……
叮！时间到。笔者一开始接触到敏捷测试的概念的时候，其实是陷入了一个狭隘的误区（产生了一个误解），认为敏捷测试团队是为“测试（QA）”团队提出的概念，是为了改变现有测试团队的问题而诞生的。其实这是错误的。我们先来看一看敏捷团队的基本特征之一：
按照在采用敏捷软件开发方式的组织中，配合敏捷软件开发团队进行测试的整体方法。在这样的组织里，通常来说，都不会存在一个专职只做软件测试的部门，因为测试被内嵌入整体研发过程，并且“开发人员”、“测试人员”这些角色的概念和边界也被模糊化，你中有我、我中有你，有基本的分工，但更重视的是彼此合作以便达成团队（甚至部门、产品、组织）的整体目标。——徐毅
这是来自知乎的一个回答（的一部分），同样的，《敏捷软件测试：测试人员与敏捷团队的实践指南》（下称“指南”）也提出了这样的思想。即不存在所谓的“敏捷测试团队”（传统意义的测试），只存在“敏捷团队”。在这样的团队中，每一个人都参与到了“测试”这样的活动中。
这样的团队有什么样的特点呢？我们说几个团队文化上非常明显的。（详细可参考“指南”第3章）
首先，质量上，“以如何定义软件质量的可接受水平的角度来思考组织的质量哲学”。在传统的测试中，我们经常可能会出现这样的一些评估标准，例如“BUG修复率达到85+%，是达到上线的标准”，“所有的崩溃必须全部修复，才能上线”，“测试认为这个问题非常严重，不能带到线上”等。而在敏捷的思想里面，这些都是视具体情况而进行评估的。
其次，整个团队负责质量。当敏捷团队实际运转起来时，团队中的每一个人都参与了质量的保证，不论是产品、开发，还是测试。
第三，合适的节奏。敏捷团队中整体的团队速度是一致的，不存在传统测试中经常发生的场景：开发提测后，只剩下测试在拼命的加班完成后续任务。敏捷团队中依赖大家以最好的状态进行工作，高强度的工作并不是常态，加班只是特例。
第四，有效的沟通方式。传统测试中经常遇到一些实际的困难，例如开发团队在A地办公，而测试团队却在B地办公；或者与一些第三方的公司/团队配合的时候，也需要有效的沟通。敏捷的思路非常强调沟通的连续和有效。通过晨会，通过沟通工具改善，通过角色的转换来保证沟通的高效。
这样的团队中，难免也会出现文化的冲突，尤其当涉及到专家团队的利益时，或者第三方团队的文化产生冲突时。
那作为传统的测试团队，我们需要克服哪些障碍，才能更适应敏捷团队呢？
适应敏捷团队需要克服的障碍
1、丧失身份
由于众多的原因，测试人员坚持组织拥有独立的质量保证团队。经常会担心优先权被开发抢走，害怕缺乏敏捷所需的技能而失去竞争力，害怕在新的团队中迷失方向，害怕在开发团队中得不到支持等。这些是我们需要克服的第一个障碍。
2、缺乏培训
在敏捷团队中，如果没有经过有经验的人的良好培训，可能会发生一些遗憾的情况，例如会有人因为不理解或者不适应自己的新角色而放弃。这样的团队中，尤其是团队建设初期，有效的培训是必要的。
3、过去的经验/观点
当习惯、并乐于过去的经验、项目迭代、沟通方式、软件发布理念时，敏捷这样的新概念就难以理解，认为改变的成本高，看不到明显的意义。并且当敏捷推进产生困难时，这样的角色就会发出尖锐的疑问。甚至拒绝再给敏捷尝试的机会。
4、额外的角色
在敏捷团队创建之初的时候，需要思考的一个很重要的问题是，团队中需要什么样的角色。为了保证敏捷团队更好的运转，我们有可能需要再增加一名开发，或者一名性能测试工程师，或者一名敏捷测试的有经验指导人员等等。合理的规划和构想团队的组成，对团队的敏捷实施是重要的。
到目前为止，笔者对敏捷的思考和理解还存在于纸面，具体的实践经验不足。相信一定有不少的偏差，甚至谬解。还希望读者多多留言，不吝赐教。
