问题单价值多少

一个版本都有大量的问题单，其中总有一部分是非问题或撤销的问题，非问题会占一定的比重，这些问题同样会花费开发较多的时间进行问题定位和确认，对效率确实存在影响。不可否认这确实是一个问题，但随之而来的质疑更是一个大问题，即问题单价值的问题。为什么有价值问题的争论？有以下几个方面：

分层测试的偏差：即使是影响重大的问题，归根到底是代码实现上的问题（也许修改一行代码就可以解决）。现在在分层条件下看：假设在单元测试阶段就发现此处代码有问题，但很有可能会认为根本走不到这个分支或变量不可能出现这样的值而放过了。在低层次发现的问题根本很难评估影响——即分层影响问题的评估。试想一个问题在线网出现并解决的花费是在需求分析阶段发现并解决的花费的100倍，那么一个问题在需求阶段被发现，它的影响是不是被低估了100倍。所以分层测试本身没有问题，是我们的思维没有跟上。在讲测试策略的时候我们往往会条件反射似的想到分层，但在讲问题的时候往往又陷入问题本身而看不到全貌。这也是测试大佬们经常提到的测试思维，在面对问题时要有批判性思维和系统性思维，要跳出条条框框。同时，测试要讲常识：测试无法穷举覆盖，无法发现所有的问题；也要讲覆盖：知道自己做了什么，哪些没有做。最后将这些情况和周边沟通清楚，让别人了解测试做了什么、也了解别人做了什么以及希望别人做什么以给予帮助。

场景理解偏差：开发认为“某某场景极少，所以无需修改”。这个时候测试刨根问底的素质就要体现出来了。问题的本质是什么？是否存在其它触发条件，这些触发条件中哪些是用户更常见的情形？风险和影响有多大？问题或场景是否存在演进的可能，如何规避？价值是挖掘出来的！

视角偏差：对于一个问题的争论往往是这样的情形：开发站在功能实现的角度给出导致问题现象的解释；而测试是站在使用者的角度希望得到当前的问题现象不会导致严重问题的论证。解释和论证是有很大却别的，所有两者很难有交集。相信大家都有这样的体会。测试只有向利益干系人不断的解释测试才会有共识，才会产生价值。

事后之明：往往是在问题导致了严重的后果后才意识到它的价值。套用一个经典的对白：曾经有个平台问题别和谐了，等到被产品提单时才追悔莫及……一个实实在在的例子是关于安全的：问题本身并不复杂，关键是这个问题平台测试发现过，但SE经过评审认为非问题。结果被产品提单，而且是致命问题，同步所有版本。

谁是谁的客户：如果说测试提供专业的测试技术服务，那么开发就是测试的客户，这样测试就放在另一个相对弱势的地位。换一个角度看，如果某个时候开发必须交付版本给测试，测试完成后再交付下游，这时角色和地位发生了变化。公司是为用户服务的，具体来讲，下一道工序就是用户，就是您的上帝，您必须认真对待每一个用户。测试必须是开发的用户，不管如何提前介入。