对软件测试团队“核心价值”的思考

之前曾写过《软件质量管理的困境与对策思考》，在其中谈到开发部门与质量管理部门（QA）应形成一个有“交集的双环”而非“哑铃型”组织，也指出软件质量管理应重实践轻量化，其目标应是帮助工程师改善工作习惯和提升开发环境的效率。那时并没有认真地思考过测试团队的核心价值，直到读到老师的《》。

通常，软件开发团队似乎几乎不谈论自己的“核心价值”，而针对测试团队总有对该问题的特有思考是不是折射出了现实的一些状况？因为但凡探寻“核心价值”时，往往意味着价值不够清晰或者找不准重点。

以我过去一直从事软件开发相关工作的经历来看，测试团队对于“核心价值”的特有思考的确存在其必然性。探讨其根源让我们从一个“游戏”开始。

“零和游戏”之困

多数软件企业都设立了开发与测试两个部门，且两个部门属于企业价值链中的两个有交互但又独立的节点。在企业中只要是个部门就大多存在绩效考核问题，似乎只有这样才能证明该部门存在的必要性。

软件测试部门的角色通常定位为“质量卫士”。自然地，他们所发现软件缺陷的数量和严重程度与其绩效潜移默化地有着紧密关联。于是乎，测试工程师为了体现其价值，希望尽可能在缺陷跟踪系统中新建缺陷记录。但开发工程师就不干了，因为缺陷数量同样可以作为考核指标以衡量其开发质量。进一步我们有了这样的工作场景：测试工程师发现问题后，首先与开发工程师进行沟通，在征得开发工程师的同意后再新建缺陷记录（这个过程有时变成了一种博弈，而非真正为了工作效率）；开发工程师对于测试工程师所发现的问题不是持感激态度，反而认为他们是在“找麻烦”。由于“质量卫士”的存在，开发工程师心安理得、堂而皇之地认为保证软件质量是测试部门的事。

不难发现，这样的体制下其实创造了一个“零和游戏”。这个游戏给我们带来的困境是：测试部门的“赢”（发现了更多的缺陷）意味着开发部门的“输”（开发质量不佳）；反之亦然。总而言之，两个部门很难达成共赢，有时甚至出现各自为政的极端状况。

软件质量的概念

估计没有人会质疑测试活动本身的价值，其背后的道理恐怕再简单不过了。但我们仍需先探讨一下什么是软件质量（后面简称为“质量”），不明晰这一概念会很难保证测试活动能有的放矢。

我在《专业嵌入式软件开发》一书中曾指出，质量是分级的，它包含用户和团队两个级别。简单说来，用户级的质量由软件缺陷去反映，而团队级的质量反映于开发团队能否按步就班地实施开发工作而非经常处于“救火”的“紧急状态”，团队级的质量是涵盖用户级的更高形式。我在该书中还指出，软件设计是质量之本，只有高质的软件设计才能保证团队级的质量，并最终长期给我们带来用户级的质量。这些主张很明确地表示，质量首先由软件开发工程师负责。

用户级的软件质量我们可以通过根据需求文档编写的测试用例来加以评估。但是团队级质量（即软件设计质量）则很难通过这些测试用例去评估，但软件缺陷数量却也能反映出一定的情况。如果某项目的软件缺陷数量在相当长的时间内出现幅度较大的波动，这大多意味着软件设计存在问题，也表明开发团队并没有从根源上解决问题，而是采取了“七修八补”的短期行为。另外，从开发团队是否时常处于“救火”状态也能很大程度地反映出软件的团队级质量水准。

我们需要测试工程师吗？

理想情况下，测试可以由开发工程师们去完成，因为“他们知道软件的所有实现细节”，但现实与理想总是存在差距。完全由开发工程师去完成测试工作存在以下可操作性问题：

1）对开发工程师的能力要求太高。这些家伙不仅要精通编程语言、熟悉业务，为了测试还得掌握测试理论、测试方法和实施测试所需的脚本语言。要求一旦太高，就容易出现资源稀缺的现象。另外，我们设想一下，工程师如何才能达到这么高的要求？学校里学？还是工作中学？如果在工作中学，那么在没有达到要求前他们在工作中承担的角色又是什么？

2）当开发时间很紧的情形下，要让开发工程师同时关注设计质量和测试质量几乎不大可能。现实中，能顾及前者就算是很出色的开发工程师了。此外，这种不可能不是单方面由开发工程师决定的，而是有太多的项目管理团队总有“压缩时间能促使开发团队不散漫”的错误认识，而没有意识这种认识驱使的行为所带来的副作用——影响了软件的设计质量。

3）开发工程师们通过采用软件模块化的方式实现协作，这种情形下一定需要有人从测试的角度去统领整个系统，靠开发工程师自己实在勉为其难。

面对这些可操作性问题，如果有人还一味地坚持测试工作应完全由开发工程师完成，那只能说他在否认社会分工的益处，也很可能是忘记了自己在成长为“全能选手”前所承担的角色。

综上所述，我们需要有测试工程师与开发工程师共同努力以实现质量目标，而这也意味着测试工程师是有价值的！

测试工程师贡献价值的方向

测试工程师要很好地贡献价值，首先要与开发工程师有共同的目标。也就是说，开发与测试团队先要把质量目标变成“我们的”，而不是“你的”或“我的”，否则很难打破“零和游戏”所带来的困境。就这一点，我完全认同老师在他的《测试的双重目的性及理性质量观》一文中所倡导的“只有将开发和测试完全地混合在一起，不分彼此，才能够真正获得好的质量，不应试图去隔绝开发与测试团队”。换句话说，开发与测试团队在组织架构上的关系要做适当的修正以支撑这种主张，否则它是阻碍测试团队输出价值的第一个巨大障碍。

所制定的共同质量目标最好是团队级别的，因为从开发工程师的角度来看，只有这样才能保证开发工作按步就班，也意味着他们和公司能从中获得最大的收益。从这个角度说来，测试工程师可以考虑“我如何帮助改善软件的设计质量”。这个问题或许太大，对测试工程师的要求也太高（后面我们还会谈这方面的内容），但我们可以从“如何保证软件的可测试性”这种更具有指导性的问题入手。

退而求其次的是，测试团队与开发团队共享相同的用户级质量目标。在这个层面上，测试团队将发现巨大的发挥空间。比如，测试团队能否搭建或改善单元测试的平台，以帮助开发工程师更方便地实施单元测试；又或者能否帮助开发工程师构建持续集成的平台；等等。

请注意，我并非主张测试团队应对开发团队言听计从，而是主张测试团队应使用自己的测试专业知识帮助开发团队提高开发质量与效率，而非只充当检验员的角色。测试工程师一定需要建立团队的自信：测试是一个专业领域，在质量保证方面我们有自己独到的见解，能为开发工程师提供帮助。

总的说来，测试团队需要站在测试专业领域的高度为开发团队提供指导与帮助，也只有这样开发工程师才能感受到“我们拥有同一个质量目标”。这种观念我想也正是老师在《》一文中想强调的。另外，Google让测试团队隶属于Engineering Productivity这一FA（Focus Area）或许也正是出于这一考虑的吧！

现实的无奈

读者可以从网上搜索《Google是如何做测试的》这个系列翻译文章，其中谈到了Google是如何组织测试的，里面的内容很值得我们学习与思考。总体说来，我觉得Google对于测试工程师和测试开发工程师的要求相比国内我所见到的更高，且其中开发测试工程师的作用非常关键，他们review设计、审查代码的质量与风险、重构代码使之具备更好的可测试性、编写单元测试和自动化测试框架等。

回头看看国内，好象将测试当作比开发次要而非同级。对测试工程师的要求似乎也没有开发工程师高，这一点从招聘时碰到某位工程师不适合开发岗位时会考虑他是否适合做测试可以看出。以我的理解，测试工程师应当是开发工程师出身且水平更高，因为只有水平高了才能对软件质量有更深刻的认识，才有能力从质量层面贴心地指导和帮助开发工程师的日常工作。

测试团队对“核心价值”困惑的存在，很大程度上是由于国内对测试的重视不足，强行割裂开发与测试两个活动而导致的。其所带来的更大危害在于，测试人才缺乏一定的梯度。