软件测试如何面对各种质疑？

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

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

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

我：“XXXX”

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

我：“(⊙o⊙)…”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

前面的文章发出来以后，一位前同事的评论相当精辟，就拿他来作为今天的结尾吧：

测试不像开发，销售等领域，在价值创造、价值呈现方面很难有实质的输出、量化展现（编者注：发现的缺陷是有价值的，无论是新的缺陷还是回归的缺陷，避免了大量的质量事故。而且还要看不同的软件，关键领域的软件更是这样，如航空航天、核工业、汽车、金融......,现在只是互联网声音太大,如facebook...还有许多没有成功但声音很大的starup公司，哈哈 ），所以可能会被上层忽视。好的产品就是一道美味佳肴，而测试就像菜肴里的调料，他不像菜中的高档食材被人关注，但又不可或缺，少则寡淡无味，多则过犹不及。