本节书摘来自华章出版社《软件测试价值提升之路》一书中的第2章，第2.4节，作者：杨晓慧编著，更多章节内容可以访问云栖社区“华章计算机”公众号查看。
2.4 寻找价值的最佳人选是自己
企业调整测试投资的根本原因通常是：减少年度操作成本，加速上市，提高产品质量和服务，保证与法律、法规的一致。
但是以下内容经常以问题的形式抛给测试团队：
测试结果数据不完整，测试结果和客户使用的感知不一致。测试的结论是功能正确了，但是到客户那里有基本功能验收不通过；测试说性能能达到100，但客户说到60就不能用了。在这些情况下，最直接的反应就是，产品到底有没有经过测试！测试工程师就算有千百条理由去解释发生偏差的原因，都会显得苍白无力，如果发生的概率高，就会直接导致客户和研发团队对测试的不信任。
测试太贵。尽管测试人员认为自己没有充足的时间和资源，但是研发的设备投资大部分是给测试使用的，进行成本控制时就必然会考虑削减这部分开支。有一段时间，某产品深受兼容性的困扰，一个版本上线，总是会在几个客户那里出现原有功能出错的情况。于是我们找思科的专家咨询，他们说思科的测试不考虑成本，在实验室有所有大客户的1∶1镜像环境，产品上线前在镜像环境上全部验证一遍。能像思科这样采用土豪战术的公司极为有限，更多时候还是需要面对成本控制的压力的。
测试太花时间。版本到了计划的发布时间，测试还没有做完，这在我经历过的项目中并不少见。尽管测试经理都认为，并非测试这个环节太花时间，而是前面的环节延期；或者前面虽然卡住了时间点，但是留了一堆未闭环的问题，导致测试甚至无法写出确切的用例；或者测试所需要的环境、用户数据没有到位；或者缺陷太多、修改不及时，这些都会使测试无法维持正常的效率。但是，如果在版本已经延期的情况下，测试经理用这些理由说明延期的原因，就只能是徒劳的解释而无法解决了。
对于产品质量和风险，测试没有提供有价值的信息和建议。最常见的现象是，在版本发布的时候测试给出了一堆数据，比如发现了多少缺陷，花了多少人力，性能指标到达多少等，但是决定要不要发布的时候根本不看这些数据，因为这些数据根本没有告诉研发主管产品是不是能发布，有什么风险，还需要做哪些后续动作等。也就是说，测试给出的报告，既不能支撑结论的给出，也没有建议的措施，但研发经理实际上是期望测试给出有价值的数据和建议的。有一个研发经理说过，他最欣赏的一个测试经理，每次在发布的时候都直接告诉他，这个版本目前能满足哪个客户的要求，或者再给测试两周时间才能正常发布，可以想象这位测试经理在团队中会有相应分量和话语权。
测试没有在第一时间发现最重要的缺陷。某产品的一个版本，前面几轮测试的时候，一直没有进行性能验证，因为所有的模块都单独测试过性能，都完全满足性能要求。但是最后一轮发布之前，把负载加上后发现由于接口设计不合理导致系统整体性能极差，版本完全不可能发布。后来回溯时才发现，系统工程师一直在询问性能的测试情况，测试工程师由于太自信，一直答复不会有缺陷。通常基本操作流程、性能、安全等的缺陷会导致设计上做大的调整，但是在版本的前几轮开发中，通常也不具备进行这些测试的条件，如何把重要的内容尽早验证，这是对测试能力的一个很大挑战。
测试团队发展到一定的阶段，几乎都会面临这些问题，在解决这些问题的时候通常会发现，仅仅依靠测试团队根本无法解决问题，或者问题根源就不在测试这里。如果测试团队采取尽力而为、能解决多少算多少的策略，或者将问题直接推给自认为合适的部门，那将无法解决问题，更加无法达成研发经理心目中的那个目标。
但是换个角度思考，这些问题出现在研发过程中，测试往往是处在污染河流的下游，本身就是问题最直接的受害者，因而也是问题解决推动者的最佳人选。如果把问题的解决作为推动改进的契机，在解决问题的过程中探寻到问题对质量、成本、效率的影响方式和外在表征，进而促进多团队协作改进，这样也许会更有助于问题的解决和测试自身的提升。
从我的经验看，通常也只有这样，测试才能获得相应的资源来彻底解决问题。
测试技术发展到现在其实一直在进化。最初的几个先锋，使用乱打乱撞的方式进行验证，在这个过程中，先锋们发现某个思路、某种做法对于发现某类缺陷特别有效，于是逐渐发展出各种测试设计的工程方法，以及测试的标准流程模型，进而使测试变成了一门专业技术。这个进化实现了测试由一个个人行为向一个团队行为拓展所需的准备，但是也留下了一个尾巴，那就是，这些固化下来的东西没有考虑到对不同类别的软件、不同的团队文化、不同的研发流程的适应性。
测试的继续进化，测试设计、自动化、环境管理、流程管理技术仍是测试工作的基石，新一代的测试人需要站在这个基石上，寻求适合自己产品形态、研发流程的成功实践，进而总结出方法。
