每到年底的时候，不管是个人还是团队，总是避免不了要对这一年的工作进行总结和汇报。而对于测试开发岗位来说，通常会面临一个共性的问题：做了这么多事情，究竟产出了多大的业务价值？
在很长一段时间内，我对这个问题也是非常困惑。困惑的原因倒不是觉得工作内容没有价值，而是对于测试开发类的工作，通常没有明确的业务需求方，对于工作成果度量也没有统一的方式。
为什么测试开发岗位会面临这个问题呢？
这应该和测试岗位的职责和工作内容有很大的关系。关于测试开发工程师的定义，在《Google 测试之道》一书中已经有了很全面的解释，我也很是认同。测试开发工程师（SDET，Software Development Engineer in Testing）首先应该是开发角色，只是相比于业务开发工程师，他们的目标用户更多的是公司内部的测试人员（也包括其他岗位的项目组成员），而核心工作内容就是提供通用测试技术解决方案，开发实现测试工具或平台，协助测试人员更好地完成测试工作和项目交付，而效率和质量也是他们最为关注的方面。
从岗位职责和工作内容可以看出，测试开发通常不会直接参与业务交付，并且他们通常也不会隶属于具体的项目组，因此对于他们的工作到底产出了多少实际的价值收益，在上面的领导或老板看来就不是那么明确，最终他们面临价值产出度量的问题也就在所难免了。
本文就围绕测试开发价值产出度量的问题，谈下我的一些思考和建议。
何为业务价值？
我们总是在说业务价值，那业务价值究竟指的是什么？为什么同样是写代码开发系统平台，大家通常会觉得开发电商、售后平台是产出业务价值，而开发测试工具平台就不产生业务价值呢？这种想法是否正确？
其实当我们回归商业的本质，就会得知问题的答案了。对于商业公司来说，通常是以盈利为目标的，而为了达成这个目标，就需要通过业务手段，对用户提供价值，最终获得用户的买单。从这个角度来讲，决定是否对公司产生业务价值与岗位类型无关，也与开发实现了什么系统或平台无关。例如，对于提供测试类服务的公司或项目组来说，例如听云、WeTest，开发出的测试工具平台就直接面向客户，并以此获得盈利，那么参与该类项目的测试开发工程师就直接产出了业务价值。
而在绝大多数非测试服务类商业公司中，测试工具平台更多是提供一种辅助手段，帮助项目组更好更快地完成业务需求交付，而并不直接创造业务价值。当然，这个问题不仅在测试开发岗位上存在，对于某些开发岗位也是同样存在的，例如开发公司内部即时通讯工具、流程审批工具、消息网关、中间件等等。
因此，对于测试开发岗位来说，不必揪着“业务价值”不放，我们完全可以从其它角度来对工作成果产出进行度量和展现。
节省人天数？
那要使用什么度量指标呢？
在很多时候，大家可能会想到使用“节省人天数”这样一个指标。因为测试开发的主要职责之一就是提升测试效率，那如果能度量出在使用测试工具平台后减少了多少人力投入，那么就能很好地体现该工具平台的价值。
那么要怎么计算“节省人天数”呢？之前我们使用过的方式如下：
统计出项目的回归测试场景，以及在固定周期内的发版次数（假设为 N 次）；
估算出通过人工去执行这些测试场景的耗时（假设为 M 人天）；
统计出工具平台执行测试的耗时（通常该耗时可忽略不计）；
那么节省的人天数就为：N * M
乍一看，这个思路没啥问题，也能计算出具体的节省人天数。但在实际项目中尝试运作之后，我们发现该计算方式存在比较大的漏洞。
例如，某测试工具平台在 A 项目组投入使用后，通过计算，每月节省了人力 10 人天。可是，A 项目组的发版频率并没有改变，项目组人员编制也没有缩减，甚至根据招聘需求，人员编制还出现了增长的情况。那在这种情况下，通过计算得出节省的人力去哪儿了？
对此我们并不能给出很好的回答。事实上，测试人员借助测试工具平台从之前的重复手工工作解放出来后，他们可能花了更多的时间在需求分析上，也可能花了更多的时间在测试策略设计上。这都是我们所期望的结果，但问题在于，这些内容我们并不能很好地去统计和量化。这也就导致我们统计出的“节省人天数”缺乏说服力。
而且从更宏观的层面来看，度量项目组的质量情况时，更多是会关注交付效率和线上质量（漏测率）两个维度。交付效率，可以通过“交付需求数/投入人天数”进行计算，而线上质量（漏测率），可以通过“线上 bug 数/测试发现总 bug 数”得出。可以看出，线上质量（漏测率）与“节省人天数”基本没有关系，而交付效率方面，除非项目投入人天数真的减少了（通常不大可能），那么交付效率也很难通过“节省人天数”提升。
因此，“节省人天数”并不是一个可行的度量指标。
建议的方案
那有没有其它更合适的度量指标呢？其实我也没法给出绝对正确的答案。