客户满意度驱动的质量和测试

软件的质量到底意味着什么？我们从来都是靠SQAP中定义的几个metrics来度量，比如DTRC，SRE，Virtual Zero，等等。满足这些指标后，软件就可以发布给用户了。这不是问题，因为软件总是需要度量。问题是，为什么这些指标对于我们所有的产品线、对于全球所有地区的客户总是一成不变？这样的指标是否代表了客户需求？还是仅仅是工程师团队对质量问题孤立认识的简单结果？我们有许多产品线，投入了巨大的测试成本，投入市场后却多年没有见到意想中的客户反馈的问题。难道是我们的产品完美无缺了？显然不是，上百万行代码的软件产品几乎做不到零缺陷。如果客户不能发现问题，是否意味着我们的软件质量有可能已经Over Quality了？将那部分Over Quality的资源用在别的更需要资源的地方，岂不是对公司、对客户都是好事？

遗憾的是目前为止我还没有见到研究Over Quality的资料，因为Quality是红线。我们所有的教义都强调质量第一，不成文的规则指导人们尽量减少质量风险。一旦形成习惯，就再没人思考Why。为什么我们不能依照客户对于质量的认识来定义产品的质量要求而不是盲目地追求质量呢？我们都在强调满足客户对软件功能的需求，为什么不能从客户感受出发满足客户对质量的真实需求呢？琢磨了下，也许可以用这个模型：横坐标Staff.Month代表测试资源的投入，纵坐标Q代表质量，或者潜在缺陷（Latent Defect）被发现的比例。蓝线（E）代表工程师团队投入测试资源后软件质量的上升，可以理解为SRE（Software Reliability Engineering）。红线（C）代表客户满意度，可以理解为随着客户使用软件的增加，能发现软件中潜在缺陷的可能性。当E和C相交时，意味着工程师和客户共同发现了所有缺陷。E和C可能永远不相交吗？其实只要调整E和C各自的横坐标比例，E和C应该总是会相交的。我们总是试图提高a到u，对客户来说当然是好事，可是测试资源的投入将从A上升到U，这真的划算吗？也许客户觉得l的质量就不错了，我们是否就可以相应只投入L的测试资源？我们也许可以考虑一些安全区间，比如比客户期望高出5%的质量要求，像这样：客户要求u，我们要求u’（= u * 105%），客户要求l，我们要求l’（= l * 105%）。相应投入测试资源为U’和L’。

这个模型的难点在于如何建立准确的客户满意度的数学模型。说难也不难，我们在几乎所有产品线上，都有若干年积累起来的客户相关数据，包括客户发现的缺陷和客户对产品满意度的调查报告。这些也许足够建立一个相对准确的数学模型并且协助我们设定客户期望的Q了，进而指导我们安排合理的测试资源。

这里当然还有很多细节问题，比如SRE不适合自动测试，影响C的除了使用时间和用户数量之外，肯定还有别的因素，等等。不过，模型总是可以从简单到复杂，最重要的是模型背后的逻辑。而这，恐怕也是目前公司无法突破的现实。