当用户反馈产品质量问题时，测试团队就会抱怨原型过于简单，需求不够完善，导致测试结果没有一个标准来衡量。表面上看，这话也没毛病，设计明确需求，开发实现，测试来验证交付物是否符合需求。就好比是一个生产车间，一环扣一环，最终实现交付。这种“车间”模式，并没有考虑到软件这种产品的特殊性，所以问题也会比较多。测试处于产品的最后一个环节，出了问题，背锅的几率更大些。我心里也明白，质量不是测试出来的。但作为测试团队，除了验证需求，是否能做的更多？或者说，测试的价值究竟如何来体现？

个人理解，按照原型和需求文档的要求完成测试，仅仅是实现了温饱水平，要达到小康，或者奔向财富自由，测试人员必须有更高的要求。上大学那会，有位微软副总裁来学校讲课，分享他在微软的工作历程。刚进微软的时候也是一个测试工程师，每天按照需求文档、测试用例文档来测试，并没有发现多少bug。他很郁闷，工作没有成就感。后来就干脆抛开所有的文档，按照自己的想法开始测试，结果发现了很多bug。   当根据需求测不出问题了，也就是温饱问题已经解决时，是安于当前现状，还是继续向小康奔进呢？微软副总裁给我们做了一个很好的示范，他开始转变思维，把自己当成一个真正的用户，开始“使用”系统，在“使用”过程中，bug也随之而来。他关注的焦点不再是“需求验证”，而是变成了“价值贡献”。通过测试，让产品的价值进一步提升。我认为这是测试的价值所在。

这周因为一直在考虑测试价值这个问题，所以也在网上翻了翻相关资料，无意中发现前华为高级测试专家杨晓慧写的一本书《软件测试价值提升之路》。杨总的见解比我深刻了不少，记录下来慢慢学习。

1. 测试的基本价值，也就是我说的温饱阶段，主要职责是测试产品，发现缺陷，报告结果，使每个版本的测试水准稳步提升。

2. 展露锋芒阶段，相当于“小康”阶段，引入“全流程质量保障”和“用户视角”实践，最终实现“代表客户测试”和“产品交付专家” 测试的目的不是“发现缺陷”，而是“参与质量管理，实现缺陷预防”。在研发的每个环节都有验证和质量反馈的工作，因此测试的工作是分布在整个产品研发过程中的，这就是全流程质量保障。 到了软件交付的最后阶段，测试人员是最了解系统功能和用户的想法的，相当于“设计人员”和“最终用户”的结合体。

3. 测试以外的价值，这个层次就更高了，测试价值不仅仅体现在产品本身，而是延伸到外部。杨总列举了2点：

   • 驱动研发改进：测试人员看到的问题比较全，同时又深受其害，因此，大部分测试团队都会从问题出发，驱动研发团队进行产品质量、研发能力或者研发流程的改进。
   • 独立第三方评估： 把测试做成一个服务，比如安全、性能、自动化等方面，可以成立独立的部门，对外提供服务。

周末把书的电子版发给了测试团队，后面计划开展一个专门的学习讨论会。思想的武装永远比工具重要。