本文首发于「BY林子」，转载请参考版权声明。
测试部门的存在是传统企业普遍存在的一种组织架构形式，在数字化转型的浪潮下，有不少企业在往业技融合方向转变，但测试部门完全融合到业技融合团队还是任重而道远。在这种新形势下，测试部门该如何跟业务、开发更有效的协作，是需要系统性思考的问题。
本文围绕这一问题展开，尝试对测试部门的职责进行定义，内容不仅适用于传统企业中独立的测试部门或者测试团队，也适用于敏捷团队里的QA（测试角色）。
01 组织架构
为了更好地聊职责定位，有必要先捋一下测试部门的组织架构。测试相关的组织架构常见的有以下几种情况：
- 测试是一个独立的部门，跟开发中心或者开发部是平级的关系：这种组织架构下，测试跟开发是非常独立的，两者之间通常会有比较厚重的部门墙，沟通和协作会比较吃力。
- 测试和开发同属于某个开发中心，但是测试自己是一个独立的团队，对应的还有多个开发团队：这种组织架构跟前一种是非常类似的，测试和开发还是比较独立，有着团队墙，同样沟通和协作的难度较大。
- 根据不同的产品线，测试和开发融合在一起成为开发团队：这种开发和测试间的沟通和协作会相对顺畅，比较利于质量实践的开展。
- 在前一种测试和开发融合的基础上，按职能成立的跨团队社区型组织，比如测试社区或质量社区：这种组织主要是解决测试人员分散在不同的开发团队不方便共享专业领域知识和经验的问题。
每种组织形式都有它存在的原因，至于哪一种比较理想，需要从价值目标的角度来考虑，具体可参考书籍《高效能团队模式》里介绍的团队拓扑内容。
02 职责定位
除了前面列举的典型组织架构之外，肯定还有其他的情况。不过，不管是哪一种组织架构，测试部门的职责可以分为两大类：测试管理类和测试实施类。
- 对于独立的测试部门或团队，一般会有一部分人承担测试管理类职责，另一部分承担测试实施类职责；
- 对于测试开发融合的团队，可能每个测试人员都需要同时承担测试管理和实施的职责；
- 对于测试社区，其构成就会同时包括前面两类职责的人员，同时在社区的角度来讲，还需要承担社区建设、活动组织等相关职责。
2.1 测试管理类职责
【说明】后面几项管理类职责，我会从组织级层面介绍，其实这里的组织可以是整个企业，也可以是某个团队或者团队的某个测试人员，虽然介绍的是组织级的管理职责，对应到团队或个人都是适用的，同样可以参考。
测试管理类职责主要是组织级质量/测试体系构建、组织级质量相关策略的制定、以及质量/测试实践标准规范的定义。
2.1.1 构建组织级质量/测试体系框架
结合企业文化、业务指标等确定质量目标，由目标驱动，构建相应的体系框架，涵盖流程、策略规范、实践指南等内容。
关于组织级质量/测试体系构建框架，我之前有分享过如下图示的组织级测试体系图谱：
该图谱由“一个中心，四个方向”构成，要构建完备的组织级测试体系，建议围绕“一个中心”、向四个方向发力：
- 一个中心：核心价值观
- 四个方向：高效率协同、标准化指导、规范化实施、自动化支撑
2.1.2 制定组织级质量策略
组织级质量策略比通常说的测试策略范围更广，是指在组织质量体系框架下具体的能够指导团队质量/测试实践落地的策略，是全组织通用的质量保障的方向性指导。具体到每个团队还需要根据团队的具体情况进行调整，基于组织级策略定制化自己团队适配的策略。
1. 测试流程
这里的测试流程不是指执行某项测试需要哪些步骤，而是指软件开发生命周期中需要在哪些环节实施测试相关活动。测试流程的定义就是将这些内容固化下来，形成规范，让团队全体成员基于这些规范来执行相应的测试实践。
没有流程规范，大家随意开展测试工作，将会混乱。测试流程，相当于测试活动开展的框架，跟编程框架类似。可以用来培训批量人员，让大家按照统一的方式来实施测试，规范每个人的测试行为，减少犯错的可能性，尽可能提高测试的效率和有效性。
测试流程通常跟软件开发流程紧密相关，需要基于开发流程来定义。基于企业不同的开发模式，测试流程常见的有以下几种情况：
- 传统瀑布开发模式下的独立测试阶段，发生在开发完成之后；
- 基于V模型开发模式下的测试，同样是发生在开发完成之后的阶段；
- 基于W模型开发模式下的测试，更早进入到开发阶段，测试与开发并行，但是顺序性的，过程不可逆；
- 基于敏捷开发模式的测试，左移到需求阶段，在软件开发全生命周期进行持续的测试，并且右移到生产环境，给软件开发提供全流程的质量反馈，做到缺陷预防，降低成本，提高软件交付质量。
关于这几种开发模型，博客《软件开发常见模型（瀑布模型、V模型、W模型、敏捷开发模型）》中有非常详细的介绍。
测试流程规范业界目前主要有以下三种管理形式：
- 人为制定流程，编写流程规范文档，团队依据文档执行；
- 文档定义流程，同时配套工具平台来规范执行，如流水线、看板等；
- 将流程全部固化到工具平台，利用工具平台实现全流程的标准化和自动化，如Google等。
2. 测试策略
测试策略是在既定测试流程的基础上，定义不同产品需要测试的内容，每个环节的测试活动、测试方法。
组织级的测试策略具备较高层次的方向性指导意义，而团队级的测试策略更能指导落地，两者所涵盖的内容是类似的，只是抽象层次不太一样。
比如组织级的测试策略需要定义不同产品对应的测试内容是功能为主，还是性能、安全等同样重要；需要定义对于不同类型的系统和不同的技术架构所采用的自动化分层策略有何差异，以及对应的测试四象限里包括的测试方法有哪些……而团队级就是根据自己的产品类型、系统和团队特点来基于组织级策略定制化自己的测试策略。
传统测试策略文档通常是篇幅较长、文字为主的形式，编写成本较高，并且写完了很少有人去看，形存实亡。为了让测试策略真正能发挥指导价值，推荐采用一页纸测试策略的思路来制定。
3. 质量度量与治理策略
1）质量度量
质量度量需要从定性和定量两个维度进行，组织级的质量度量策略主要包括度量指标和度量方式的定义。其中度量指标既有过程指标，也包括成效指标；度量方式主要是指标对应数据的获取方式。
下图为度量指标示例：
Thoughtworks同事于晓南的《质量度量文集》有质量度量的系列详细分享，感兴趣的同学请移步参阅。
2）质量治理
根据质量度量的结果，通常需要进行相应的质量治理，从组织级角度来讲需要有相应的治理策略指导，包括治理周期/频率、治理举措建议等内容。推荐定期的质量治理会议来帮助组织持续改进质量。
定期的质量治理会议是一项非常有价值的活动，类似于回顾会议，只不过是主题主要是讨论质量治理相关内容。参与者为质量相关干系人，会议内容主要为回顾前一阶段质量方面做的好的和需要改进的，对于好的方面继续保持，而对于不好的方面，大家头脑风暴改进举措，并指定举措负责人负责执行情况跟踪。同时，将有代表性的改进举措固化下来，作为后续类似问题的参考。
2.1.3 定义组织级质量实践规范
1）实践标准规范
在质量策略的指导下，定义每个实践活动的标准规范，供团队落地实施参考。质量实践的标准规范通常包括但不限于以下几个方面的内容：
- 目标：目标的清晰定义，能够帮助团队理解实践的价值，更好地实施；
- 负责人/角色：明确实践的负责人，有利于实践如期开展；
- 参与者：与实践相关的人员都需要参与；
- 实施方式：实践实施的步骤、方法等，可能需要举例说明；
- 达标要求：实践的成功评判标准；
- 输出输出：实践的前提条件，以及实践完成后的产出；
- ……
软件全生命周期的典型质量实践通常有且不限于下图这些：
2）质量成熟度模型
质量成熟度模型是评估质量实践实施情况，并牵引团队持续改进的重要工具之一。
需要测试部门定义组织级的质量实践成熟度评估维度，团队可以根据自身特点进行定制化微调，以实现对团队质量实践活动实施情况进行评估，并且指导团队持续改进。
2.1.4 规划组织级工具平台
工具平台方面，根据前面策略和实践需要工具平台支撑的情况，有测试部门跟平台开发/采购负责人提出相应的支撑需求，将工具平台与实践落地更紧密地联系起来，在提高交付质量和效能的同时，发挥工具平台的最大价值。比如：
- 对于测试流程的管理，需要流水线或看板提供的功能需求；
- 根据分层策略，对于需要编写自动化测试的工具的需求；
- 对于质量度量指标获取的工具支撑需求；
- ……
2.1.5 人员能力建设
人员能力建设包括对测试角色的能力建设，也包括对团队非测试角色的质量赋能，这两部分需要采取不同的策略。
1）测试人员的能力建设
测试人员的能力建设建议下面三个方面的内容：
- 构建测试胜任力模型
- 建立不同的人员梯队
- 构建测试社区
我之前有对测试人员能力提升做过详细的分享，包括组织级测试能力建设和个人角度的测试能力提升两个部分，感兴趣的朋友请移步参阅。
2）非测试角色的质量赋能
前面对流程、策略、实践的标准化定义，以及工具平台提供的自动化支撑，其实就是对团队各个角色的一种质量赋能。除此之外，通过测试全生命周期的介入，以及很多多个角色共同参与的质量实践活动，测试可以对其他非测试角色进行质量赋能。
2.2 测试实施类职责
测试实施类职责就是执行质量相关实践活动，我在早期一篇写给毕业生的文章《神圣的QA》中将其定为五个基本职责：
- 理解和澄清业务需求
- 制定策略并设计测试
- 实现和执行测试
- 缺陷管理与分析
- 质量反馈与风险识别
在另一篇文章《构建测试的体系化思维（基础篇）》中，对这五个基本职责以及对应职责的相关实践都有详细的介绍。
2.3 测试社区职责
测试社区是一类虚拟性的跨团队组织，相对传统部门或团队来说比较特殊。社区的职责我想从两个角度来看：
- 社区运行相关的职责——构建和运行社区需要相关人员履行的职责
- 社区对质量的职责——对整个组织的软件交付质量、团队质量赋能等需要承担的质量相关的职责
2.3.1 社区运行相关的职责
测试社区本身运行相关的职责需要社区所有人共同来承担，包括社区的建立、发展规划和活动组织等。
可以成立社区核心小组，负责社区建立，发起社区发展规划、活动内容、活动形式的讨论，推动具体的规划和活动的落地。对于每次活动的组织可以由核心小组出人负责，或者从社区其他人员里出人负责。社区所有人员尽量参与每次活动或讨论。
2.3.2 社区对质量的职责
成立测试社区的一种情况是没有独立测试部门，测试人员分散到各个项目团队。这种情况下，测试管理相关的大部分职责需要社区来承担，一般建议核心小组主要负责，如质量策略制定、质量实践标准化、工具平台建议、测试人员能力建设、团队质量赋能相关等。职责的详细内容建议参考前面介绍。
03 写在最后
测试部门作为组织内质量实践专家组成的团队，需要承担起质量倡导者职责，需要从系统化的角度来看待质量，在整个软件开发生命周期关注软件内外部质量，并且对团队实现质量赋能。
最后，推荐阅读相关文章系列：
- 《神圣的QA——写给应届毕业生》
- 《构建测试的体系化思维（基础篇）》
- 《构建测试的体系化思维（进阶篇）》
- 《构建测试的体系化思维（高级篇）》
- 《数字化转型背景下的测试转型》
- 《软件测试人员该何去何从》
- 《一页纸测试策略》
- 《团队质量赋能》
- 《质量度量文集》
- 《质量成熟度评估》
本文首发于「BY林子」，转载请参考版权声明。