本节书摘来自华章出版社《软件测试价值提升之路》一书中的第1章，第1.1节，作者：杨晓慧编著，更多章节内容可以访问云栖社区“华章计算机”公众号查看。
第1部分
引 子
测试工作是否有价值，这似乎是一个不值得讨论的问题，因为几乎所有的软件公司都有测试团队，既然一个以盈利为目的的组织，舍得为了测试进行投资，那么测试工作就一定是有价值的。
但是另一方面，无论是从业界了解的情况，还是从我们测试团队自身看，测试工程师转行的比例都高于同级别的开发工程师和系统工程师，这些转行的测试工程师在新的职业道路上大多获得了更高职位、更好的发展。这说明他们在测试岗位上的发展受阻，并非由于自身的素质和能力造成的，很可能是由于工作的价值没有得到肯定。
测试的工作大多数是属于破坏性的，通过对产品的各种攻击操作，检验产品是否符合需要。而软件设计、开发工作是建设性的，主导了产品从无到有的生产过程。公司的盈利最直接的原因就是建设性的工作成果—产品，能成功销售。因此，由于这种工作性质，测试确实是一个相对难以做出价值的职业。
一方面研发对测试的投资期望得到价值回报，另一方面测试已经做出的工作价值没有得到充分认可。这个局如何破？这就是本书接下来将要讨论的内容。
第1章
Chapter 1
他山之石
测试这个职业从诞生之日起，对于其价值的探索就从未停止过，随着软件技术的发展和软件应用范围的扩展，一方面，测试实现传统的价值遇到了新的挑战；另一方面，研发对测试价值也有了新的期望。
他山之石可以攻玉，在讨论测试存在的价值之前，先看看测试价值走过的路，以及在优秀的软件公司里，测试人员都承担哪些职责，他们的做法可以给接下来的价值讨论带来哪些启示。
1.1 测试困局
在我的工作中，经常会听到测试经理诉苦说工作难做。测试经理经常面对来自客户、产品经理、研发经理，甚至测试内部的质疑：
产品在客户那里出了问题，客户问：测试究竟能不能保证质量？
产品上市延迟了，研发经理问：究竟要花多少时间做测试？
产品架构优化、改变开发模式、采用新技术提升了开发效率，系统工程师问：测试难道就没有新方法同步提高效率？
项目做完了，发现项目中打杂的事情多数是测试顶上，决策的时候测试没有话语权？
职位评定时，测试工程师问：好像每年递交的任职申请中改变的只有项目清单，难道这些年就是不断的重复？
测试工作看上去就是：看不到产出、说不清投入、显不出能力（或者说是能力没有进化）。
测试面对来自各方的对工作价值的质疑时，常常这样“反击”：
测试不是产出bug吗？对不起，测试产出的bug已经改掉了，我曾经和几个测试的同事合作开发过自动化工具，我负责开发的模块中有一个是通信模块，有一次一位同事说：hi，你做的通信模块好牛啊，从来没有出过问题。当我回忆起这个场景时，我理解了为什么发现bug不容易被记住。如果开发工程师写的代码被调用、被拷贝，做的功能被使用时，他们在设计、实现上精心的考虑，是会被人反复看到、赞叹的。bug呢？如果发现的bug是考虑了新的要素，并且和一些陈年顽疾有关；或者发现的一个特别的bug，在后来的特性中又出现了，那么测试工程师对测试设计的精心考虑才会被赞叹。但是这样的机会显然不多。
这个版本发现了1452个缺陷？对不起，这个数字意味着什么？是表示产品质量差？测试水平高？测试做得太多了？或者其他什么意思？
那测试提升了质量啊？其实现在针对质量的提升，通常的共识是，因为有更好的开发工具、更好的编程语言、更好的软件重启和恢复机制、更好的分层隔离架构、更好的测试工具……而在这一路上，测试工程师本身的贡献少得可怜。说到开发工具，测试工程师很少使用这些工具，与这些工具的开发和测试就更没有关系了；说到开发语言，大部分测试工程师甚至做不到精通一门编程语言，更不要说开发过一款语言了；说到更好的软件重启和恢复机制，这主要是架构和设计模式的演进，跟测试关系很小；说到测试工具，大部分测试工程师在使用这些工具，但是并不参与工具的开发和推广。所以很少有公司把质量的改善归功于测试的价值。
为什么要测试有产出？测试不是蓝军吗？不是把红军攻下来就是成绩吗？随着软件架构的演进、软件应用的普及，对开发和测试的这个红蓝军的隐喻已经过时了，过去主流的软件是用于军工、航天、通信核心层、工业设计（autoCAD）、管理、财务等，这些软件是针对企业的需要，一旦出问题影响也比较大，常常伴随无法承担的经济或人身损失。现在的软件已经渗透到各行各业，渗透到日常生活，用户也是老幼妇孺都有，由于基础架构的改变以及产品成本结构的变化，软件中的很多缺陷不再会造成无法挽回的损失。这时候测试还死守蓝军的定位已经不合时宜。
不仅仅是对于bug价值的理解和红蓝军的隐喻不合时宜，一些测试领域认为理所当然的“准则”也一样不合时宜：
能证明有问题，不能证明没问题。测试可以显示缺陷的存在，可以减少产品中存在未被发现缺陷的可能性，但由于穷尽测试是不可能的，因此即使在测试中没有发现缺陷，也不能证明产品已经没有缺陷。这是一句完全正确的“废话”，即使客户同意这个观点，他也会质疑：为什么这个缺陷没有被发现，明明是在正常使用情况下就暴露出的缺陷，并不需要“穷尽”测试。
质量是设计出来的，不是测试出来的：产品能够达到什么样的质量，在架构、设计方案确定后，就已经决定了，不可能通过测试活动，让产品质量有本质的提升。这句话虽然道出了一个事实，但是听起来更像一个逃避责任的借口。测试之所以存在，就是因为人是会犯错的，研发团队更希望测试能够在错误发生的时候就被发现并证实这个错误，而不是到了最后一切都已经定型了才说这个产品不行。
所以，测试之所以遭遇到当下的困境和质疑，很大一部分原因，就是测试的价值定位，以及在这个价值之下的思维逻辑需要跟上软件发展的步伐。
为解决这个困局人们采取的做法大概有2类：
1）老板说什么我做什么。研发经理说客户缺陷太多了，你们要加强测试设计能力啊，于是测试工程师把测试方案越写越细，用例越积越多，尽管知道这些手段根本就没法保证缺陷必然被发现，但是多走点路大概踩到牛屎的几率高一些吧。研发经理说测试周期太长了，要搞自动化啊，于是测试工程师引进工具，把自动化率越做越高，尽管早已发现，自动化对测试效率其实没啥贡献。研发经理说为啥缺陷那么晚发现，你们要参与到前端去啊 ，于是测试工程师参与需求和设计评审，尽管大部分人是打着评审的旗号提前学习了一下特性。测试只知道按研发经理支的招去做了，却根本没有关心研发经理想解决什么问题。这种思路会是什么结果呢？问题依旧，因为这些意见根本就是外行指挥内行，最后在困局中越陷越深。
2）主动寻求新的测试价值。通过在产品测试过程中获得的数据，利用对产品的深入掌握，对测试的深入理解，来拓展新的职能，例如：主导产品的指标改进，在代码管理和发布平台（CI、沙箱、灰度）中内建质量标准，主导产品集成，主导用户体验分析，用验收用例实例化客户需求，主管验收测试活动等。
我认为后者是更有前途的思路，但是现在走在这条路上的还是一些先锋，属于个别人的英雄主义冒险。我希望用我的绵薄之力，使这方面的创见越来越多，最后实现对测试这个职业的新的价值定位。
