探索软件测试的核心价值

软件测试作为一个工作有很多的价值，因为大家的工作内容都会包含很多东西，而且对产品和项目都是有价值，这里只说说和测试直接相关的所谓的核心的价值吧。我把它人为的分为了三个层次。

　　第一个层次：职位本身带来的价值。

这个有点类似于工厂里的QC， 需要有专人来做检验的工作，这种价值和设立这个专门的职位有关。就像很多职业的分工，一旦设立了这个专门的职位，这个职位上的人就需要按照设定的要求去驱动某些事情会被做到，对测试而言就是产品在出去之前会被检验到，对项目经理而言就是会按照计划来驱动项目往前走。绝对的来讲是不需要通过这样的职位设定来驱动某些事情被落实的，因为开发人员也可以自测，产品集成好了之后也可以从用户的角度来完整的测试，但是实际上如果没有这样的分工和专职的安排，很多事情不会真的被做。还是那上面提到的项目经理来举例，理论上产品的开发者应该也可以按照几乎把事情做了，为什么要一个专职的人来把握项目的进度了（当然项目经理还要做很多别的事情）。

从这个角度，这有点像是通过分工来确保落实。而且因为设立了这样的专职的工作，那么自然就有job responsibility，需要对质量负责，而因为有这样的要求，测试人员会跳出来报出问题，提出不同的意见。一个是制度上的安排，一个是心理上的。反过来可以设想一下，如果在一个正式的商业产品中，没有测试人员或者类似的工种，很多时候对质量的要求会流于形式，质量很容易被进度的压力compromise掉，而且因为测得够不够本身就是个很模糊的概念，大家可能简单用一用觉得没有问题就出去了。

上面提到的其实是一个很基本的层次，有而且做了而已，至于做得怎么样，那是另一回事。

第二个层次：做得更专业，更好。

这里换一个例子，拿做饭为例，好的酒店里的厨师和那些只在家里做做饭的人区别是什么。当然，这里说的是通常的情况，个别另类除外。如果按照上面的层次，两者都能做出还可以的能吃的饭，可以达到这个工作的基本的要求。但是如果只停留在家庭主厨的要求，就不会有专业的厨师这个职业，还有什么几级认证之类的。那么专业的厨师的更进一步的价值在哪里？我想简单来说大概是做得更专业，更好吧。

同样，对于测试这个职业，也是一样，如果只是把功能都用到了，发现了bug，那和普通的用户有什么区别呢？

那什么是更专业，更好呢？我想用两个词来概括，效果和效率。

先说效果，下面列了两个方面：

a. 发现更多的bug，而且很多是简单用用无法发现的bug，甚至非常难以发现的bug。这也好比专业勘探和去山里玩的驴友，驴友可以发现奇怪有趣的露在外面的石头，而专业的勘探人员能找出埋在地下的有价值的东西。

b. 有些测试需要专业的技能，比如性能测试，稳定性测试，安全性测试等需要专业的技能和工具。

对于这类测试，普通用户是难以发现的，因为等他们发现那就不是找到bug，而是不幸遭遇到bug。这一部分是非常体现测试人员的技术和专业能力的地方，有很多地方值得深入的研究。

再说说效率，这个放在后面并不表示没有效果重要。很多时候我们的思考和努力都花在这上面，在现在这个对软件和服务的推出速度要求越来越高的年代，效率有时候显得更加重要。因为根据二八原则，很多时候大家宁愿花20%的时间发现80%的bug，然后就以beta的名义把产品推出去，然后再来改进，因为毕竟大部分的软件产品，特别是需要严格测试的产品都是有商业价值的，而time to market就是一个很重要的因素。

所以从这个角度来讲，对一个专业的测试人员的要求还包括更快的发现问题。这个可能是对工具和能力的要求，也有对测试方法和流程的要求，比如自动化测试，敏捷测试等等。举个例子来说，就好比大家可以在家里做手工，但是如果超市里卖的日常生活用品用这个效率做出来估计就没有什么商业竞争力，不是吗？

说了这么多，突然想到其实意思简单的就是，专业的就是要把事情做得又快又好。

如果能做到上面的两个层次，基本上已经是一个优秀的测试人员了，但是如果只是有这些显然不够，总要有些别的追求嘛。

现在说说我理解的第三个层次，那就是：提高整体产品的quality。

为什么这么说呢，因为的两层都是在找bug，这样有两个问题，一是事后才发现，二是很多东西已经晚了，甚至没法修补。

发现bug是一个事后的过程，是在代码已经写好了之后去测试，发现了问题需要修改原来的代码，其实可以做得更好。

a. 将发现bug变得更早，在单元测试（有时是developer来做）的时候就发现，或者产品的build一出来就发现，比如和auto build系统集成的测试。

b. defect prevention

再往前走，在有缺陷的代码被写出来之前就发现问题。比如detail design，requirement specification， 甚至产品的spec制定的时候就发现问题，这类问题有很多，比如很多场景可能没有被考虑到，有些可能和原来的客户或者产品的需求不一致，甚至有些地方不具有可测性。那么在这个时候，需要及时的讨论和调整。因为这个时候的调整可能比产品出来之后发现几个bug更有价值，因为早期的错误可能到后面很难改，或者改的代价很大。

c. 协助建立质量的文化。

之所以说协助，是因为觉得这个可能不只是靠测试人员就能做到，需要和开发人员以及产品的管理人员等等一起来创建。

garbage in，garbage out。越来越觉得quality本身是写出来的，是设计出来的，是规划出来的，而不是测出来的。产品的架构，设计，使用的模块，代码的质量都会，甚至深远的影响到质量，其实你会发现这个已经超出了测试人员最基本的工作的要求，但是却是能发挥更大价值的地方。

关于这方面怎么做，可能没有前面的两个层次那么清晰，但是是可以做的，比如a和b提到的，c的要求可能更高，需要更大的能力和影响力。