现在回头看2016、2017年会发现那时候很多人热衷于写各种各样的技术文章（包括我关注的测试技术文章），写的也确实挺好，另外许多优秀的开源项目也是源至于那个时候，我是2016年进入现在的公司，现在细细品味公司的变化，我也发现了，2017年还真是互联网的巅峰时期，从那以后就开始走下坡路了，进入2019年几乎让很多人感到阵阵寒意，这时候你去搜索一些自动化测试、性能测试、DevOps的文章，你会发现少了很多（好的文章大部分是2017年及之前写的），因为很多公司和团队（包括QA、测试、运维团队）都在战略收缩，不再提什么雄心壮志了。但正因为这样，我们才需要关注和反思很多事情，需要花心思去解决很多的技术债，欠债就得还，对于测试行业也是如此。我们测试和整个研发团队，所面对一个最大的债，那就是产品质量。大家一路狂奔，造了那么多轮子，生产了那么多汽车，当面对去库存压力时，不应该重新想想什么是质量什么是口碑吗？所以2020年我们将重点关注什么是质量，关注如何提升质量，关注如何用最少的成本去提高质量，这可能也是来年大家的努力方向。而一个团队中，谁该为质量负责呢？很多人说是测试，而我接触的测试人员里不少会埋怨需求和开发，开发人员也同样没少怪到需求头上，所以值得反思。

       以下转载一篇有关质量的文章并做了点修改，原文：http://www.sohu.com/a/337468907_487103

-谁应该为质量负责？
-QA是负责测试把关，主要负责吧，DEV也要在设计和代码上对质量负责。
-那其他角色呢？
-BA还好吧，跟质量的关系没那么大。
-……

       在蓝鲸项目，似乎大家对质量的关注意识有些欠缺，于是在项目上的不同角色、不同工作年限的人之间采样做了一次访谈，上面这个问题就是其中访谈的问题之一。有同事曾提醒我说这种题就是送分题，肯定不会有人回答不出。可是，事实并非如此…
       为什么会这样呢？我猜想可能是大家对质量的理解不一致的缘故，在没有搞清楚什么是质量的前提下，当然也没有可能理解到底谁该为质量负责。
       因此，我们来看看质量到底是什么？

质量是什么？

产品质量不是检测出来的，从产品生产出来后质量就已经在那了。
——著名的质量管理专家戴明

       在讲什么是质量之前，我们有必要区分两个不同的概念：测试只能检测、发现缺陷，而质量要通过缺陷预防来实现。 测试与质量不可同日而语，以后再也不要说“上线这么多问题，测试是怎么测的”这种话了。

       那么，质量到底是什么？对于不同的角色、不同的利益相关者，质量有着不同的含义。总的来说，可以分为外部质量和内部质量两种。

1. 外部质量：

       顾名思义，外部质量就是软件呈现给用户的外部形态，是否有缺陷、是否稳定、是否有性能问题等。也就是最终用户在软件使用过程中的各种体验，包括软件可学习、高效、不易出错、有用、难忘等特性，都属于外部质量范畴。外部质量也可以称为使用质量，主要是从使用软件的用户角度来看的。

       外部质量能够被用户直接感知到，直接影响用户的使用，因而显得特别重要，客户/用户一般也比较容易为外部质量买单。

2. 内部质量：

       同样的，内部质量就是指软件系统内部的质量状态，包括代码的效率、结构、可读性、可扩展性、可靠性和可维护性等。内部质量主要从开发人员角度来看，也称为代码质量。衡量的5个标准包括Sourc Lines of Code (SLOC)、Bugs per code_section / module / time_period（Bug统计指标）、Code Coverage（代码测试覆盖率）、Design / Development Contraints（设计规则和代码规范标准）、Cyclomatic Complexity（环路复杂度），这些衡量软件质量的标准都是可自动化的。

       内部质量不会被最终用户感知到，不容易被客户/用户买单，也常容易被团队忽略。但是，内部质量会影响外部质量，需要团队引起重视，加强设计、开发等环节的质量把控。而且这部分通过自动化方式去检测和衡量，其投入产出比也是最高的。

3. 内建质量：

       质量不能被检测出来，要提高软件产品的内、外部质量，都需要通过质量内建（或质量内嵌）的方式，做好每个环节的质量保障工作。质量内建包含自动化测试和手动测试：

• 自动化测试：从多个层次（单元、组件、端到端等）写自动化测试，并将其作为部署流水线的一部分来执行，每次提交应用程序代码、配置或环境以及运行时所需要软件发生变化时，都要执行这些测试。同时，随着项目业务和技术架构的演进，自动化测试策略也需要随之调整、不断改进。
• 手动测试：手动测试也是很关键的部分，如需求验证、演示、可用性测试和探索式测试等，在整个项目过程中都应该持之以恒的做下去。

       另外，质量内建不仅要考虑功能测试，对于跨功能测试同样是需要做到内建的，比如安全内建、持续性能测试等。另外质量内建还要需关注软件部署质量（对安装包、部署说明书、自动化部署脚本、CI/CD或Pipeline质量、Docker质量等）。

       软件构建过程中多大程度上做到了质量内建，有多少缺陷做到了提前预防，这是“内建质量”。内建质量虽然跟内、外部质量不在一个维度，但也是体现质量好坏的一个方面，在此也把它作为衡量质量的一个维度，测试或使用过程中发现的缺陷数量可以作为度量指标。

       因此，我们可以从这三个维度来度量软件产品的质量，可以通过以下方式来度量：

外部质量：用户反馈、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要管理好团队的交付节奏、团队成员的工作状态、客户的满意度等，这些都是跟质量相关的。

写在最后

       质量不仅是某个角色的事情，团队每个成员都撇不开质量这个话题。团队为质量负责要求所有质量角色都将质量推向看板的左侧，从每个用户故事的开始就将质量融入其中。

       软件开发生命周期的每个环节、每个实践活动都不可轻视，只有在每个点上都做好质量的工作，才能实现真正的高质量交付，每个角色对此都有着非常重要的职责。

       而作为质量管理团队来说，软件质量标准的精细化与可自动化是我们绕不开的话题，最终的目的就是为了扫除人的障碍，让相关职责人员负起相应的质量责任。