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

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

一般，软件开发团队彷佛几乎不谈论本身的“核心价值”，而针对测试团队总有对该问题的特有思考是否是折射出了现实的一些情况？由于但凡探寻“核心价值”时，每每意味着价值不够清晰或者找不许重点。

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

“零和游戏”之困

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

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

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

软件质量的概念

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

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

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

咱们须要测试工程师吗？

理想状况下，测试能够由开发工程师们去完成，由于“他们知道软件的全部实现细节”，但现实与理想老是存在差距。彻底由开发工程师去完成测试工做存在如下可操做性问题：

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

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

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

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

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

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

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

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

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

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

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

现实的无奈

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

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

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