问：谁应该为质量负责？
答：QA是负责测试把关，主要负责吧，DEV也要在设计和代码上对质量负责。
问：那其他角色呢？
答：BA还好吧，跟质量的关系没那么大。
……
在蓝鲸项目，似乎大家对质量的关注意识有些欠缺，于是在项目上的不同角色、不同工作年限的人之间采样做了一次访谈，上面这个问题就是其中访谈的问题之一。有同事曾提醒我说这种题就是送分题，肯定不会有人回答不出。可是，事实并非如此 …
为什么会这样呢？我猜想可能是大家对质量的理解不一致的缘故，在没有搞清楚什么是质量的前提下，当然也没有可能理解到底谁该为质量负责。
因此，我们来看看质量到底是什么？
质量是什么
产品质量不是检测出来的，从产品生产出来后质量就已经在那了。
——著名的质量管理专家戴明
在讲什么是质量之前，我们有必要区分两个不同的概念：测试只能检测、发现缺陷，而质量要通过缺陷预防来实现。 测试与质量不可同日而语，以后再也不要说“上线这么多问题，测试是怎么测的”这种话了。
那么，质量到底是什么？对于不同的角色、不同的利益相关者，质量有着不同的含义。总的来说，可以分为外部质量和内部质量两种。
1. 外部质量
顾名思义，外部质量就是软件呈现给用户的外部形态，是否有缺陷、是否稳定、是否有性能问题等。也就是最终用户在软件使用过程中的各种体验，包括软件可学习、高效、不易出错、有用、难忘等特性，都属于外部质量范畴。外部质量也可以称为使用质量，主要是从使用软件的用户角度来看的。
外部质量能够被用户直接感知到，直接影响用户的使用，因而显得特别重要，客户/用户一般也比较容易为外部质量买单。
2. 内部质量
同样的，内部质量就是指软件系统内部的质量状态，包括代码的效率、结构、可读性、可扩展性、可靠性和可维护性等。内部质量主要从开发人员角度来看，也称为代码质量。
内部质量不会被最终用户感知到，不容易被客户/用户买单，也常容易被团队忽略。但是，内部质量会影响外部质量，需要团队引起重视，加强设计、开发等环节的质量把控。
3. 内建质量
质量不能被检测出来，要提高软件产品的内、外部质量，都需要通过质量内建（或质量内嵌）的方式，做好每个环节的质量保障工作。质量内建包含自动化测试和手动测试：
- 自动化测试：从多个层次（单元、组件、端到端等）写自动化测试，并将其作为部署流水线的一部分来执行，每次提交应用程序代码、配置或环境以及运行时所需要软件发生变化时，都要执行这些测试。同时，随着项目业务和技术架构的演进，自动化测试策略也需要随之调整、不断改进。
- 手动测试：手动测试也是很关键的部分，如需求验证、演示、可用性测试和探索式测试等，在整个项目过程中都应该持之以恒的做下去。
另外，质量内建不仅要考虑功能测试，对于跨功能测试同样是需要做到内建的，比如安全内建、持续性能测试等。
软件构建过程中多大程度上做到了质量内建，有多少缺陷做到了提前预防，这是“内建质量”。内建质量虽然跟内、外部质量不在一个维度，但也是体现质量好坏的一个方面，在此也把它作为衡量质量的一个维度，测试或使用过程中发现的缺陷数量可以作为度量指标。
因此，我们可以从这三个维度来度量软件产品的质量，可以通过以下方式来度量：
外部质量：用户反馈、Support的问题数量
内部质量：code review、结对编程、静态代码质量检查
内建质量：测试环境、生产环境缺陷，Support的反馈
了解了三个维度质量的含义，我们不难理解：
❌质量不是零缺陷，不是百分百的测试覆盖率，也不是没有技术债；
✅质量是快速反馈，任何改变能够快速验证，并且快速修复；
✅质量是把精力都集中在正确的事情上；
✅质量是团队在代码、设计和交付上有信心做出改变；
✅质量是团队对任何改变负责。
容易忽视的质量
从前面对质量的定义，广义的质量其实包括软件产品交付流程中的方方面面，每个环节的一点疏忽都可能对软件质量造成不同程度的影响。下面列举一些从项目上经历的对质量关注有所欠缺的内容：
- 需求分析过程仓促，或者参与人员角色比较单一，导致业务上下文了解不够，关键场景缺乏考虑等；
- 忙于交付更多的feature，忽略了对代码质量的关注，该重构的没有重构，在原本不太健康的代码基础上继续增加更多的代码，导致混乱，筑起高高的技术债；
- 没有足够的测试覆盖，导致新增代码容易破坏已有功能；
- Dev提交代码后，就投入新代码的开发，对所提交代码缺乏关注，CI pipeline红了不能及时修复，可能影响后面QA的测试进度；
- 大面积的重构发生在release前夕，无法全面回归，带来很大的风险；
- 项目初期只考虑少量用户的场景，随着业务的发展，系统功能难以扩展，导致严重性能瓶颈；
- 技术选型失误，开发困难，没有及时改进，一错再错，最后问题严重到无法弥补；
- 第三方组件评估不够充分，导致线上环境无法承载等；
- 开发缺少对异常情况的处理，测试过程缺乏探索，只覆盖到主干路径，边角case可能引发问题；
- 开发或者测试都只考虑当前功能模块，缺乏更广范围的考虑；
- 缺乏跨功能需求的关注，导致严重的安全或者性能问题；
- 对线上环境了解不够，而且没有足够日志信息记录，线上问题难以定位，导致宕机时间过长；
- ……
这样的问题还有很多很多，无法一一枚举。每个角色，每个环节都有可能出现纰漏，导致产品质量问题。
那么，谁该为质量负责是不是已经很清楚了？
谁该为质量负责
前面已经讲到，质量是贯穿项目整个生命周期的非常关键的部分，质量保障工作也是需要在每个环节加强关注，每个角色都需要为质量负责。
上表列出的是敏捷开发流程中的各个实践活动，它们都与质量有关，每个活动都要求多个不同的角色同时参与。
下面从敏捷团队三个主力角色BA、QA和Dev的不同视角来看看各自怎么为质量负责。
BA：Busines Analyst，业务分析师
BA主要负责业务需求的分析工作，要理解客户的业务，并将业务分解成便于Dev和QA理解的功能点，同时，还要能够帮助用户验证开发完成的软件系统功能，并展示给客户。需求作为软件开发的源头，是极为关键的。
BA视角的质量，主要是需求分析的准确性和清晰度，要帮助团队对需求有一致的认识，从用户旅程的角度关注交付给最终用户的产品是否真的带来了价值。
Dev：Developer，开发人员
Dev作为软件系统实现的主力，对质量内建是至关重要的。从需求的理解、整洁的代码实现、测试覆盖率的保证、频繁的代码提交、持续的集成、对生产环境的关注、运维的支持等方面，都有着不可替代的职责，每个环节都不可忽略。
因此，Dev视角的质量不仅是按照需求实现功能的开发，还要把功能高效的交付给最终用户。
QA：Quality Analyst，质量分析师
QA作为软件质量的倡导者，是唯一一个全流程都要参与的角色，从需求到上线后的支持，每个环节都不可缺。清晰理解需求、制定质量保障策略、做好各个环节的测试工作（手动、自动化、探索式、跨功能、非功能测试，以及生产环境的QA等）、关注项目整体质量状态、及时反馈质量信息给团队、识别业务风险和优先级、帮助优化业务价值，这些都是QA的职责。
三个主力角色中的BA一般都会有从用户旅程的角度去考虑，其实Dev和QA也需要同样的思维模式，不能把story或者AC割裂来看，而是要从整体的用户旅程的角度、端到端的去考虑需求的实现和测试工作。
除了三个主力角色，团队还有其他角色也都是要对质量负责的，比如：架构师要负责项目架构的健康，基础设施负责人要管理和维护好基础设施以保障开发和运维工作的顺利开展，PM要管理好团队的交付节奏、团队成员的工作状态、客户的满意度等，这些都是跟质量相关的。
写在最后
质量不仅是某个角色的事情，团队每个成员都撇不开质量这个话题。团队为质量负责要求所有质量角色都将质量推向看板的左侧，从每个用户故事的开始就将质量融入其中。
软件开发生命周期的每个环节、每个实践活动都不可轻视，只有在每个点上都做好质量的工作，才能实现真正的高质量交付，每个角色对此都有着非常重要的职责。
