QA? QC? 傻傻分不清

  有时候给客户介绍QA或者质量保证，一些客户会询问：QA就是指测试吧？我一般都会顿一下，然后肯定地说：是的，主要就是指测试。这样的回答，既没有驳了客户的面子，把讨论点聚焦在测试服务这个范畴，同时用“主要”这个词也维护了我们的专业严谨性。当然，也有碰上懂行的，他们会这样提问：你们的SQA和测试是分开的还是合在一起的？于是，我们知道彼此差不多在同一个频道了，比较有逼格的说法就是“on the same page”。

  关于软件质量保证和软件测试，应该是这个行业最经典的一对概念了，至少也是最经典之一。只是，能够真正讲明白两者区别的人可能并不多。至少我自己对于两者的理解也是在逐步加深，甚至现在都没有特别去强调和区分了。

  比较经典的解释，往往会引入工厂生产中质量控制(QC)的概念：

QC：检测产品的质量，保证其符合客户的需求或者需求规格，即我们通常的测试，工作对象侧重于软件产品；

SQA：审计产品生产过程，确保每个软件生命周期中的规定动作都被严格地执行了，即过程的审计者。其侧重点是项目的执行。

【注：文章后续章节，为避免歧义，我们用SQA表示过程审计、QA代表广义的软件质量保证活动】

  两者的意义在于测试是用来验证我们的产出是否符合产品的标准，同时寻找存在的缺陷；而SQA则是保证整个生产的过程符合既定的规则，从而可以保证生产工艺能够维持在一定的水准之上，以预防缺陷。

  从这个角度看，各类测试（功能测试、性能测试等等）无疑是属于QC，那么代码评审、需求评审等动作本身则也应该属于QC，毕竟他们都是对于产出物的检测。而有没有做代码评审、有没有做测试，则属于SQA的范畴了。

  另外，提交前做QA Sign-Off属于QC还是SQA呢？看似是一个流程性质的东西，但是却不是简简单单归为SQA的；应该是这么理解：有做QA Sign-Off应该是SQA，而做QA Sign-Off的时候需要判断提交物的质量是否达标，那么就必须引入QC了。

在早年做项目的时候，我们部门建立了一个基于提交物的记分卡模型，我和几位QA经理一起参与了模型的构建和实施。大致原理是通过定义每个流程环节的提交物作为项目监控的基准，有提交物就表明该项活动举行了（记1分），而提交物的好坏则表明该活动做得是否到位（到位的再加1分）；当把众多活动的记分统计汇总，就可以获知某个项目运行的健康状况了。“有”还是“没有”是非常容易判断的，而提交物的质量评价往往只能交由每个团队自己的QA来判断了。

  在经典的理论体系和不少大公司的实际执行中，SQA经常作为独立的岗位存在，这个在以前一直是作为是否专业的标志之一；不过最近几年倒是比较少听说了。也许是因为敏捷模式的推行、团队自我管理机制的强化，让流程执行可以多维度地被监督，而不用特定的第三方来监控，整个敏捷团队每个人都可以是SQA角色；也许是因为DevOps的深入，软件开发的流程已经自动嵌入到了开发和运维的每个环节，不符合流程的情况几乎无法流入到下一环，即系统自带SQA。

  如果我们回到质量保证(QA)这个事情本身，其内涵和外延则会远远超过我们理解的测试和过程审计的范畴。在软件行业有个说法：软件开发中的所有问题都可以归结为质量问题。那么，从这个说法说开去，QA要做的事情则会贯穿于所有软件开发和运维生命周期中，那么去区分QC或者SQA则显得意义不大了。

  大概在八、九年前，我有给每个入职的技术人员讲一门叫“质量意识”的课。其中，有一个环节是让大家启发式讨论，影响软件的主要因素有哪些？在两年多的课程中，一批又一批的工程师给出的答案其实非常集中，差不多有预算/成本、时间和人力资源、需求变更以及技术难度等外在客观因素以及意识薄弱、需求和目标的误解、业务知识不足、技能不到位等技术人员自身因素。看起来，所有的工程师都是明白人。但是颇具讽刺意味的是，每当提到质量保证和改进质量的时候，绝大部分人第一个冒出来的想法几乎都是要加强测试，而不是去消除某个影响软件质量的因素。

  回到QA的本质话题，QA就应该去做任何有助于保证和提升项目/软件质量的事情。所以，除了测试和过程审计外，上述的每个因素都应该是在其工作范围中。那是否又意味着QA变成了项目中的万能者，连项目经理的活都应该做掉呢？也对、也不对，质量从来都不是单一群体的责任，而是所有人的事情。QA未必需要也不应该亲力亲为做每件事，但是应该去关注、关心和推动每一件涉及到质量的事情。

  理解到了这一层，是不是对QA这个称呼有更强烈的使命感？从另一个角度看，对于有想法而且愿意折腾的人而言，QA的职业广度和提升空间会因此迅速打开。以我为例，作为公司整体QA的负责人，会被老板以这个理由加入到各种跨部门项目统筹和监管、公司管理系统的运维，甚至是这些体系支持的日常行政和业务运营事务中；借此，可以很轻易地切入到自己所感兴趣的领域中。而小到某个项目范畴也是如此，身边不少QA很容易转入到Scrum Master的岗位，也正是因为其原来的工作已经深入到了项目的各个环节了。

  最后，奉上当时质量意识课程中关于质量改进的最后一页，希望可以给读者们一些启发。