让我们区分质量保证与测试

概念与思辨深度

一个行业的发展似乎总伴随着更多的概念被塑造出来。拿测试来说，我们有单元测试、集成测试、系统测试、回归测试、冒烟测试，等等。我们缘何塑造如此多的概念来“为难”自己呢？答案可以用我从老师那学到的“概念越纯粹表示思辨深度越深”这句话加以解释，而这一切又为了提高同行间的沟通效率。需要特别指出的是，多个相似但不同的概念想表达的是各自的不同之处，而非共同之处。为此，如果人家在讨论单元测试时，你冒出一句“写好程序，编译完，跑一跑，看看写得对不对，这就是最简单的UT啊！”就不大合适，因为这说明你根本没有理解单元测试的概念（可以读一下我写的《明晰单元测试》一文）。如果你再加上一句“靠，都是测试，分那么清干什么？”，那还表明你逻辑不清。

我近期所写的《对软件测试团队“核心价值”的思考》一文引发了一些讨论。比如，老师（后面简称朱老师）指出：“‘（文中所述测试）帮助开发人员提高其开发质量和效率’是软件测试团队的价值取向之一，但还不是软件测试团队的主要核心价值“。于是我向朱老师请教他所理解的测试核心价值，得到的回复是“软件测试最核心的价值还是能够快速发现问题以提供产品的质量反馈，有能力提供准确的、客观的、完整的质量评估，并通过缺陷分析、用户行为分析等，确定缺陷模式和开发人员不良行为、习惯等，帮助开发人员预防缺陷（从设计到编程、单元测试，不仅仅是设计）”。

之后我的回复是，“我们应将QA（Quality Assurance，质量保证）与测试区分开来”，因为我认为朱老师将测试的范围定义得太大了。但朱老师却帮我指出“我这是地地道道的测试，看来你对QA理解不够。QA的主要对象是（包括开发、测试）流程，QA人员评审、审计和改进流程，以保证质量。测试的对象是产品，包括阶段性半成品。从严格意义看，测试就是对软件产品的质量评估”。

类似与QA和测试相关的讨论发生在老师写了《》一文之后。这些讨论又为我们带来了老师写的《测试QA的角色和分工》，以及老师写的《对《我们需要专职QA吗？》的回应》。在本文我想顺便谈一谈以前读这些文章的看法。

谁对谁错？

如果读过我所写的《软件开发：个人与团队是永远的核心》一文的话，知道我给出了高质高效软件开发的一个效能模型。从模型所涵盖的内容来看，其范围非常广，包括行为、能力和方法三大支柱。某种程度上，我们在软件行业的职场旅程有点象是“盲人摸象”（但我们能沟通），这个摸索的过程与我们从事的软件细分行业（如互联网、通讯、银行）、服务公司（如国企、外企、私企）、工种（如开发、测试）等都有着很直接的关系，所获得的一种成功经验很可能在另一种情形下根本行不通。摸索的过程很容易通过现实去理解书本上的东西，这不是坏事，但千万不要以为所“眼见的”就是“宇宙真理”，也千万别放弃自己的独立思考。

存在争议并不是坏事，我们之所以争议，是因为我们有着不同的成长途径和思考深度（年龄起着一定的作用）。争议的焦点不是为了“你死我活”地相互“拉黑”，而应最大可能地达成共识和完善自我认识。所达成的共识越多就越是知道“象的模样”，这对所有的从业人员都有意义。正因如此，作为技术人，我时常会告诫自己“多放下一点自大与自尊去接受别人的想法，这对于自己来说是一种很好的成长途径。”而且，我对于自己所不熟悉的技术领域更多持敬畏而非否定态度。总的说来，谁对谁错并非争论的关键，而是我们有哪些想法其实是相通或相同的、如何摆事实讲逻辑地让对方了解自己的想法。我希望每一位读者都能理性对待所碰到的争议，这算是一个小小的呼吁吧。

QA不包含测试

我认为引起QA与测试相关的很多争议出现在我们没有明晰概念，或者有的概念太泛了容易导致问题。QA这个词就是一个例子！

质量保证很容易让人想到与软件质量相关的方方面面，比如测试、流程、缺陷数据分析等。既然这样，开发工程师的水平是不是也影响着软件质量呢？那人员的招聘为什么不由QA部门管，而是由HR和开发部门管？这个问题问得是不是很无厘头？但这个问题也告诉我们，各种部门的职责定义其实并非由其名字表意所定，而是由公司根据组织架构的需要指派的。既然如此，我们在使用这些名词时，一定要根据职责加以展开，而不能依据名字意思本身，否则很容易因为不当言语而引发没有价值的争议。有些争议甚至影响到了他人的“饭碗”了，你叫人如何理性？这间接地指出，我们的言语应尽可能严谨。

如果QA不是测试，那它是干什么的？老实说，我不敢凭空给一个角色定义职责，加上我并不是QA（与测试）方面的专家，在此只能以我曾经服务过的Motorola公司为例说一说我的大致理解。简单说来，Motorola的QA是一个与测试部门完全独立的部门，她关注二大事务，一是缺陷数据分析与缺陷预防，二是流程规范与改善。QA会根据测试与开发两大部门所产生的缺陷数据进行数据分析（或叫数据挖掘吧），发现各产品的缺陷模型（常犯错误、缺陷数趋势等），通过模型去预测可能潜在的遗留缺陷，以帮助开发部门进行改进（最终作用于流程）。另外，QA会全程参与软件开发活动以跟踪公司所制定流程的执行情况。比如，以前我就职的Motorola杭州研发中心通过了TL9000认证，QA必须确保开发活动完全符合TL9000的要求，以免出现资质复审时无法通过的状况。

读者请注意，我以Motorola公司为例去定义QA的职责就一定对吗？未必！对于就职于一些测试隶属于QA部门的同仁可能很难接受以上的定义。在这种情况下，我们需要思考的是，这个定义是否有助于我们更方便地沟通？如果定义有助于我们的沟通，则这种定义就是可取的，否则值得商榷。理性思考不能忘！

我们需要QA吗？

如果问“我们需要测试吗？”答案很清楚，不是吗？那公司是依据什么决定是否需要一个工种的？很简单，不同的技能！

不少软件公司需要通过象CMMI、ISO9000系列、TL9000等这样的质量体系认证，并定期复审。这些质量体系主张“质量源于过程”，因此，一定需要有人为公司制定相应的开发流程并监督流程在公司的到位实施。流程驱动研发的质量意识是需要培养的，这就离不开象“Quality begins with me”这样的培训。缺陷数据通过挖掘能帮助发现其他有价值的东西，这就需要相应的数据建模与分析技能。

不难认同，以上知识与相关技能不能由开发或测试团队的人去兼顾，因此我们需要独立的QA部门。

QA部门的作用与重视程度在不同的行业完全不同。平均说来，互联网行业的产品因为对质量问题具有更高的容忍度（大多互联网产品直接上线，有问题可以直接回退），而非象通讯行业那样得交由象中国移动这样的运营商去运营，也不存在因质量事故引发的第三方惩罚性费用。另外，互联网产品的用户根本不关心产品开发过程是否遵循CMMI等质量体系，这与通讯行业运营商对之可能有要求完全不同。我在《离开通讯业入职互联网圈的一些感悟》一文中进一步谈到了两个行业的不同。

至此，我希望读者接受我将QA与测试两个概念区分开的建议。

一点重申

无论使用何种天花乱缀的技法和理论，探寻测试团队核心价值时一定要打破测试与开发团队之间的心理博弈防线，否则没有成功的可能。以我长期在开发一线的经历，测试的价值困惑首先源于缺乏开发工程师对之的认可，这是种心理感受问题，不是技术问题。《对软件测试团队“核心价值”的思考》虽没有直接给出核心价值的定义，但给出了探索方向，希望值得我们共同思考。

测试工程师思考从开发工程师的“痛点”寻找突破口，或许能找到出路。当然，要真从开发的“痛点”下手，测试团队必须有些“刷子”，否则只能游离在质量与效率的边缘。

对朱老师所言的回复

朱老师：软件测试最核心的价值还是能够快速发现问题以提供产品的质量反馈，有能力提供准确的、客观的、完整的质量评估，并通过缺陷分析、用户行为分析等，确定缺陷模式和开发人员不良行为、习惯等，帮助开发人员预防缺陷（从设计到编程、单元测试，不仅仅是设计）。

回复：这个定义存在将测试与QA混为一谈的问题。如果我是一名测试工程师，看到这样的定义真的会吓一跳，要求太高了。我认为质量度量很容易出现主观现象，难以做到“1+1=2”这样的真实。软件质量度量的目的不是为了“真实”了解软件的质量状况，因为团队级的质量无法直接度量，度量的目的是为了帮助开发团队找到改善点。软件质量管理应重实践、轻量化，以帮助工程师改善工作习惯和提升开发环境的效率为目标。我欣赏朱老师身兼QA与测试双重身份，但就测试核心价值的探讨上，我希望能采纳所提出的将QA与测试分开的建议。概念只有清晰了、轻量了，才不容易引起歧义，也更利于我们达成更多的共识和提高沟通效率。

朱老师：我这是地地道道的测试，看来你对QA理解不够。QA的主要对象是（包括开发、测试）流程，QA人员评审、审计和改进流程，以保证质量。测试的对象是产品，包括阶段性半成品。从严格意义看，测试就是对软件产品的质量评估。

回复：第一话既讲测试又讲QA，很容易引起误解。第二句与第三句的观点我认同。对于第四句，我的问题是“测试真能评估软件质量吗？”

对《我们需要专职的QA吗？》相关文章的看法

《》这篇文章的论点是QA，但内容其实谈的是测试，文不对题引发没有必要的争议属于情理之中。该文中还是有很多值得我们思考的观点，其中不足之处后面两篇文章对之加以反驳了。

《测试QA的角色和分工》一文同样存在将QA与测试混在一起讨论的问题，但其中还是能看出QA与测试的痕迹。比如，其中谈到了认证。其对于分工的论述我很欣赏，也阐述了为什么需要专职测试人员。

《对《我们需要专职QA吗？》的回应》一文明确区别了QA和测试，且只关注于测试的讨论。我与段老师有很多共识，虽没有听过他的演讲，但看过他一些分享主题的PPT，能从开发人员的角度找到共鸣点。注意文中的最后一句话，“测试和开发之间有更多配合，更多相亲相爱，把测试当成提高和推动质量的手段，不正应该是测试的方向吗？”