虽然一些关键领域的软件产品开发还在采用传统的瀑布模式，今天更多的研发团队在实施敏捷开发模式，开发和测试有更深的融合，独立的测试团队越来越少。例如，微软公司过去显得较为传统，开发人员:测试人员的比例1:1，甚至在Windows操作系统这样的团队，甚至高达1:2，成为软件测试的标杆，过去每当人们谈到软件测试的重要性，必搬出“微软”这块金子招牌。而从2014起微软公司开始转型，开发和测试进行融合，专职测试人员从之前的一万多人降到三百多人，测试团队就更没有理由存在下来。从这几年微软的营收和股价看，微软转型还是很成功的。
所以就没有必要讨论“测试团队”的测试能力，而是直接讨论研发团队的测试能力。每个研发团队所处的环境不一样，开发与测试融合的深度也不一样。如果团队质量文化很好，而且团队成员在多个方面（如智力、责任感、技术）表现优秀，没有专职的测试人员应该可以的。大家一起先分析、设计、编程和单元测试，然后一起再做系统测试，而且可以采用交叉测试（张三开发的代码/特性让李四测试）等方式，打破思维障碍和心理障碍。如果再进一步，实施ATDD、BDD和需求实例化等实践，测试在先，开发在后，测试驱动开发，更彻底的质量保障。在测试驱动开发模式下，每个人的测试能力是必须的，团队测试能力会逐渐在产品演化过程中建立起来。
一般情况下，研发团队可以保留专职的测试人员，而且对正在转型的研发团队，推荐设立测试责任人（Test Owner，TO），可以更好地做好项目的测试计划、测试架构设计、测试过程跟踪与协调等工作，帮助团队更有效地完成测试；同时，TO具体地或手把手地指导团队成员如何做好测试，帮助团队构建测试能力。特别是当一个产品的研发需要多个团队共同协作来完成，这时候各个团队测试范围之间容易形成空隙（覆盖不到的地方），需要有人统一协调与控制；针对系统的集成测试和整体测试策略、计划（相当于主计划，Master Test plan）等也需要有人负责和协调，这时候，TO的作用就很显著。
研发团队测试能力模型，其中一个就是《Google软件测试之道》中所描述的团队“测试认证（Test Certified）”，通过水平考核，从级别1开始，逐步提升，达到级别5，每一级别都有徽章。这个认证带有Google的特色，如：
将测试分为三级：小型测试（类似单元测试）、中型测试和大型测试。Google的团队测试能力认证，如下表所示，侧重要求了对测试的认知、冒烟测试、集成测试、单元测试等，但对TDD/ATDD没有要求，对团队测试要求也不算很高，到了级别5，单元测试覆盖率要求也只是“不低于40%”，整体测试覆盖率不低于60%，也就是说，中型测试、大型测试做得更多，不符合金字塔模式，这样的测试在敏捷模式下不是最有效的。而且这种覆盖率如何度量？是指代码行覆盖率吗？其次，持续交付的基础是持续集成，持续集成的基础是高质量的代码。除了研发人员的素质和能力、代码规范（可以认为Google这两方面都强），高质量的代码也依赖于充分有效的单元测试（包括代码的人工评审、工具的静态分析），“使用工具进行静态分析”的要求拖到级别5才做要求，也是这个模型的问题之一。
如何进一步构建研发团队的测试能力？可以基于上述Google测试能力认证的思路去提高，经过“守、破、离”这样一个过程，实现研发团队能力提升的突飞猛进。也可以基于传统的TPI进行剪裁（此处省略几千字…），选择适合敏捷测试所需的关键域（16个关键域中68%可用，具体内容可以参考我的《软件测试方法和技术（第3版）第4.5小节）、检查点和建议，为敏捷测试所用（此处省略几千字…），以提升团队的测试能力。
毕竟传统的软件研发几十年所积累的经验是有价值的，测试计划、分析、设计、沟通、度量、缺陷管理等测试基础能力的建设与改进路线图依旧值得敏捷团队的学习与吸收，获得启发性的思考，不仅知道做什么、如何做，而且要知道为什么要这样做。在掌握基础能力之后，可以挣脱束缚，抛弃自我的幻觉，寻求“突破”——局部创新和局部重构，逐步进行过程改进，如：
- 借助思维导图快速地完成测试分析；
- 让测试流程无缝地接入Scrum流程；
- 设定Test Owner角色；
- 采用BDD自动化测试框架Cucumber；
- 不写测试用例，大胆地采用探索式测试；
- 简化缺陷记录格式和及其声明周期的管理。
在这不断突破、创新的阶段，可以从下面二十个方面（如下图所示）去寻求改进（此处省略几千字…），建设敏捷测试的能力，特别是：
- 良好的敏捷测试思维，包括价值驱动思维、上下文驱动思维、批判性思维等；
- 快速迭代的适应力，例如推动持续集成、BDD和需求实例化等实施之后所带来的、快速构建高质量软件的能力；
- 领导整个团队开展测试活动的能力；
- 良好的面对面沟通、快速的质量反馈能力；
- 构建可测试性产品的能力，使之产品质量属性容易被验证；
- 能够构建准确的、稳定的、高效的基础设施或测试环境的能力；
- 自动化测试能力，含自动化测试框架、工具个脚本的设计开发能力；
- 每个成员个人的探索式测试和团队组织探索式测试的能力等。
- 良好的测试件和脚本的管理能力
敏捷测试关注的20项能力
慢慢地打下良好的敏捷测试能力基础，水到渠成，就可以寻求“离”——超越传统的测试能力，不仅测试自动化能力和探索式测试能力已经到了炉火纯青的地步，而且需求即测试、基础设施即代码，测试驱动开发已成习惯，沟通与反馈无处不在。手中无剑，心中有剑，一切都是那么自然地做测试，测试不仅和开发很好融合，测试的能力已经成为团队的内在能力。
参考：
