之前曾写过《软件质量管理的困境与对策思考》，在其中谈到开发部门与质量管理部门（QA）应形成一个有“交集的双环”而非“哑铃型”组织，也指出软件质量管理应重实践轻量化，其目标应是帮助工程师改善工作习惯和提升开发环境的效率。那时并没有认真地思考过测试团队的核心价值，直到读到@段念-段文韬老师的《测试团队与咖啡店》。
通常，软件开发团队似乎几乎不谈论自己的“核心价值”，而针对测试团队总有对该问题的特有思考是不是折射出了现实的一些状况？因为但凡探寻“核心价值”时，往往意味着价值不够清晰或者找不准重点。
以我过去一直从事软件开发相关工作的经历来看，测试团队对于“核心价值”的特有思考的确存在其必然性。探讨其根源让我们从一个“游戏”开始。
“零和游戏”之困
多数软件企业都设立了开发与测试两个部门，且两个部门属于企业价值链中的两个有交互但又独立的节点。在企业中只要是个部门就大多存在绩效考核问题，似乎只有这样才能证明该部门存在的必要性。
软件测试部门的角色通常定位为“质量卫士”。自然地，他们所发现软件缺陷的数量和严重程度与其绩效潜移默化地有着紧密关联。于是乎，测试工程师为了体现其价值，希望尽可能在缺陷跟踪系统中新建缺陷记录。但开发工程师就不干了，因为缺陷数量同样可以作为考核指标以衡量其开发质量。进一步我们有了这样的工作场景：测试工程师发现问题后，首先与开发工程师进行沟通，在征得开发工程师的同意后再新建缺陷记录（这个过程有时变成了一种博弈，而非真正为了工作效率）；开发工程师对于测试工程师所发现的问题不是持感激态度，反而认为他们是在“找麻烦”。由于“质量卫士”的存在，开发工程师心安理得、堂而皇之地认为保证软件质量是测试部门的事。
不难发现，这样的体制下其实创造了一个“零和游戏”。这个游戏给我们带来的困境是：测试部门的“赢”（发现了更多的缺陷）意味着开发部门的“输”（开发质量不佳）；反之亦然。总而言之，两个部门很难达成共赢，有时甚至出现各自为政的极端状况。
软件质量的概念
估计没有人会质疑测试活动本身的价值，其背后的道理恐怕再简单不过了。但我们仍需先探讨一下什么是软件质量（后面简称为“质量”），不明晰这一概念会很难保证测试活动能有的放矢。
我在《专业嵌入式软件开发》一书中曾指出，质量是分级的，它包含用户和团队两个级别。简单说来，用户级的质量由软件缺陷去反映，而团队级的质量反映于开发团队能否按步就班地实施开发工作而非经常处于“救火”的“紧急状态”，团队级的质量是涵盖用户级的更高形式。我在该书中还指出，软件设计是质量之本，只有高质的软件设计才能保证团队级的质量，并最终长期给我们带来用户级的质量。这些主张很明确地表示，质量首先由软件开发工程师负责。
用户级的软件质量我们可以通过根据需求文档编写的测试用例来加以评估。但是团队级质量（即软件设计质量）则很难通过这些测试用例去评估，但软件缺陷数量却也能反映出一定的情况。如果某项目的软件缺陷数量在相当长的时间内出现幅度较大的波动，这大多意味着软件设计存在问题，也表明开发团队并没有从根源上解决问题，而是采取了“七修八补”的短期行为。另外，从开发团队是否时常处于“救火”状态也能很大程度地反映出软件的团队级质量水准。
我们需要测试工程师吗？
理想情况下，测试可以由开发工程师们去完成，因为“他们知道软件的所有实现细节”，但现实与理想总是存在差距。完全由开发工程师去完成测试工作存在以下可操作性问题：
1）对开发工程师的能力要求太高。这些家伙不仅要精通编程语言、熟悉业务，为了测试还得掌握测试理论、测试方法和实施测试所需的脚本语言。要求一旦太高，就容易出现资源稀缺的现象。另外，我们设想一下，工程师如何才能达到这么高的要求？学校里学？还是工作中学？如果在工作中学，那么在没有达到要求前他们在工作中承担的角色又是什么？
2）当开发时间很紧的情形下，要让开发工程师同时关注设计质量和测试质量几乎不大可能。现实中，能顾及前者就算是很出色的开发工程师了。此外，这种不可能不是单方面由开发工程师决定的，而是有太多的项目管理团队总有“压缩时间能促使开发团队不散漫”的错误认识，而没有意识这种认识驱使的行为所带来的副作用——影响了软件的设计质量。
3）开发工程师们通过采用软件模块化的方式实现协作，这种情形下一定需要有人从测试的角度去统领整个系统，靠开发工程师自己实在勉为其难。
面对这些可操作性问题，如果有人还一味地坚持测试工作应完全由开发工程师完成，那只能说他在否认社会分工的益处，也很可能是忘记了自己在成长为“全能选手”前所承担的角色。
综上所述，我们需要有测试工程师与开发工程师共同努力以实现质量目标，而这也意味着测试工程师是有价值的！
