再谈问题单价值多少

本文所要讨论的价值仅限于经济方面的价值或者收益，它的反面是损失，那么如何衡量问题单的价值就要先看问题导致的损失，即在研发阶段没有发现的软件缺陷在现网使用过程中被触发而导致了问题，该问题导致功能失效、用户投诉、赔偿等负面效应所带来的损失。

为了更好的讨论损失，我们必须先区分清楚损失的类型。第一种是非预期的损失，就是现网问题导致的损失；第二种是预期的损失，例如：要开拓新的领域，该领域内已经有几个顶级的玩家了，要进去很难，甚至已经做好了失败的准备已经先期投入的损失，这种情况下的损失被认为是正常的；第三种情况是没有被人意识到的损失，例如研发过程中由于修复bug导致的损失是不被人注意的，这种损失单个看是比较小，但是累计起来是巨大的。

从上述关于损失的分析来看，测试发现的问题确实没有什么价值（因为这个价值识别忽视的，属于第三种情况），现网问题才有价值（因为影响面大，属于第一种情况），何解？

关键是要让第三种损失变成可见的损失。需要度量研发阶段的问题单导致的损失。具体来讲，计算因修复问题导致的研发各个环节的成本增加。开发有问题单修改代码合入记录，并由对应的代码产出基线。测试有手工执行用例及自动化脚本提交记录，也有对应的基线。流水线有流水线的执行时长记录，可以对应研发基础设施的损耗。这里还没有考虑因为问题导致多方反复沟通的成本。这个过程下来，研发阶段的问题就有对应的损失了。

从另一个角度来讲，测试的部分职责是发现问题，可以认为问题的损失就是发现的价值，这样测试的价值就被部分的量化出来了。测试发现的研发阶段的问题单的价值也就显示出来了。

而现网问题，对于开发来说要修改，所以肯定是损失；对于测试来说没有发现，所以也是损失，但很可能这种损失不如研发阶段的累计损失来得大。