测试工作是否有价值，这似乎是一个不值得讨论的问题，因为几乎所有的我们耳熟能详的软件公司都有测试团队(编者注：这样的状态也在变化，测试团队可能在减少，其中微软变化最大。编者在文中加了一些注释，启发大家批判性思维，希望测试同仁、开发人员等参与讨论)，既然一个以盈利为目的的组织，舍得为了测试进行投资，那么测试工作就一定是有价值的。

但这个推论和大部分测试人的切身感受是不一致的，现实中，我们首先会遭遇这样的尴尬

吃瓜群众：“你是搞软件的啊!酷!做的的是哪个软件?”

我：“XXXX”

吃瓜群众：“啊，我用过，哪个功能是你做的?”

我：“(⊙o⊙)…”

学术界的同仁可以说，我出了论文，写了书，培养了学生。工业界的朋友呢?编写了测试设计方案，开发了工具，发现了……Bug?对，这是我们的产出，但是它们大多是paper work，而且都不能被用户感知，也不能直接和经济利益挂钩!所以，我们的工作产出和组织的价值的关联并不那么直接，不是说我们只要把该做的工作做了，价值就很明显了，剩下的，就只是用自己的智慧和勤奋产生更大的价值、更快的产生价值。

事实上，测试所面临的质疑远不止有没有产出，是不是paper work这么“温和”。在实际项目中，我们收到的质疑要尖锐的多：

产品经理会问你们测试究竟要花多少时间做测试，好像多点少点都行，又好像多少时间都不够?开发经理说你们测试怎么总是揪着小问题扯皮?怎么重现个问题那么麻烦?客户会抱怨这个最基本的功能都做错，你们究竟有没有测试?同样是验收，你看人家XXX来2个人就全部搞定了，你们来了10几个人还搞不定(通常这10几个有大半都是做测试的)

这些抱怨听的多了，测试自己(编者注：指的专职测试人员)都在怀疑：究竟有没有前途，有没有技术含量，怎么我每年递交的任职申请中改变的只有项目清单?为什么我的待遇和发展总是比不上XX?为什么我没有话语权，我的意见和建议没有人听?为什么明明是他们先忽悠我，最后网上问题却是我先背?

你会发现，测试工作的产出没有显而易见的经济价值(编者注：实际是有，需要我们去收集数据进行核算。同样，开发也很难算出每行代码的价值。而产品的价值是由开发和测试共同创造的)，还并不是测试价值面临质疑的最主要原因((编者注：最主要原因是什么?如前面所说，测试投入估算很困难?测试的充分性?测试总是有风险的?缺少科学理论?......)。

在出了质量问题的时候，测试当然会被质疑是否尽职。在年度成本审计、效率分析的时候，通常也是测试被质疑投入产出不划算的时候。在软件架构升级、研发过程能力提升时，测试也可能被拎出来看看，是不是有技术水平落后，观念过时的问题……。

很显然大家并不是在质疑测试本身的产出，而是在质疑测试的质量、效率、成本、能力积累没有匹配产品的需要。这些需要包括：交付满足客户需要的、质量刚刚好的产品;与研发团队一起通过技术更新、模式更新达成质量、效率、成本的改进目标;支持产品拓展新市场、新领域、新客户……

测试价值的问题就出在这里，在默默的、按部就班的完成一个个测试活动后，并不是总能够天然的、显而易见的将测试与上述需要挂上钩。(编者注：这里作者给出了答案)

大部分时候，测试人员如果只守好自己的一亩三分地，写写测试方案，报告产品缺陷，那么在这些问题袭来的时候，我们是真的不好应对的。

面对测试价值的质疑，我们几乎可以靠直觉反击：测试提升了质量!在某次STAR会议上，我听到的一个观点其实和我们研发团队的官感惊人的一致：

其实现在对质量的提升，更有共识的是因为有：更好的开发工具、更好的编程语言、更好的软件重启和恢复机制、更好的分层隔离架构、更好的测试工具(编者注：多数进步都是质量倒逼的，而且测试工具是测试的范畴)。

这中间，几乎没测试什么事!这个观点虽然可能有失偏颇，但至少说明一点，质量的成功很难完全归功于测试，测试的价值也不应该只有质量一个维度(编者注：质量总是测试考量的重要维度之一，虽然我们也坚信质量是构建的，开发人员对质量的贡献可能更大，但在多数场景，没有测试还是万万不可的，而且需要专职的测试/QA人员进行督促/监控/保证/预防，不是所有的研发团队/研发人员都有高度的责任感、高素质、很强的能力等，连Google也需要对开发团队进行测试能力的认证。另外，早期的质量还能大大提升生产力。从本质上看，一个研发团队永远的核心主题是“质量”和“生产力”，质量包括做对产品)。

在《软件测试价值提升之路》一书中，你还可以找到更多的，测试所面临的质疑和我们曾经做过的徒劳的“反击”。那么测试无路可走了吗?当然不是!不然我还码字出书干嘛呢!

我们常说：不要埋头拉车，要抬头看路;不要盯着剑，要盯着目标。

这个目标就是工作的价值。那么测试的价值究竟是什么呢?宽泛的说提升质量、提升研发效率、提升发布成功率，甚至提升客户满意度、创造产品新的利润点都有可能是测试的价值，但是这样宽泛的表述一定无法帮助你解决眼前的困难(编者注：是的，需要具体的数据，需要讲质量故事...)。那么，具体到每个测试工程师自己的上下文中，到底测试的价值是什么，这个只能“it depends. ”(视情况而定)——比前一句更没有用的废话。

在测试圈里讨论这个问题的时候，有个人说“测试的价值就是解决问题”，姑且不论这个观点是否正确，这倒是一个讨论测试具体价值的角度之一。不妨看看，测试可以着手解决的具体问题有些什么。

比如，彻底杜绝升级后基本功能无法完成;保障主流手机机型的基本安装、升级和主要功能使用不出错;避免因为VIP用户(有时他们是客户的领导)使用出错遭到投诉;解决实验室测试结果和客户验收结果不一致的问题;协助设计师解决新需求不满足客户需要的问题……

当然，解决问题只是一个方面，还应该看看，测试的工作中到底有什么我们没有发挥出来的价值。

比如，自动化只能让我们在发布前跑跑用例，求个安心吗?测试设计只是把设计规格翻译成用例吗?测试执行的终极目的是发现BUG吗?测试计划只是每个项目的例行公事吗?需求和设计评审测试只是没什么特别的评审者之一吗?重现问题只能是搭个环境重新操作一遍吗?……

(编者注： 看来没有拿到全部答案，等待作者下回分解)

今后一段时间将要继续分享的，关于测试价值的思考，基本上可以归为上面两类：解决问题，以及测试活动本身的价值。