先来一则故事：
夜晚路上，一个醉汉的钥匙掉了，但这里黑漆漆的，他望见最近的地方有盏灯，于是跑到灯下去找钥匙。
想一想，我们应该如何解读这则故事？
小酋的上篇文章提到了CMMI的ATM培训《CMMI2.2之ATM培训总结》，在培训过程中有提到结合GOV和II实践域，大家希望公司给予什么样的支持？在意料之外，又在情理之中，绝大部分参与者（参与培训的大多是开发经理、产品经理、或PMO这样的角色）都认为需要改进所在公司的测试流程，如降低漏测率、减少上线bug数，提高需求覆盖率……
这种情况与开头“灯下找钥匙”的故事有相似之处。
1、线上bug
没有测试人员能保证上线后的产品不出现bug。每次出现bug，尤其被客户识别，大家都咬牙切齿。而作为最后一道关卡的测试，无论如何都摆脱不了干系。于是，顺理成章，“为什么bug会溜到线上？”，测试人员往往会被上面要求写一堆分析报告，往往为了好做人做事难免有“自身”原因在里面。至于源头，反而被需要认真看报告的人有意识地忽略了，为什么呢？因为源头“黑漆漆”啊，你知道里面有多少“大爷”在里面，水有多深？
2、测试不事生产，更听话
测试人员不事生产，做的事情难以衡量价值，而测试人员作为研发团队的服务型人员，大多是出名的“好人”。好人好说话，所以要保证产品质量，理当找“好人”。就出现了这样一种情况，流程规范再混乱的研发团队，往往测试的流程都是相对最规范的。
甚至有朋友的公司出现一种情况，测试流程已经很规范了，但上面仍然不满意，需要测试把整个团队的用例颗粒度精确到一致，原因是方便度量用例发现bug率等指标，从而长篇大论讲了模块、子模块、功能、测试点的定义及划分，最终把写用例这件事，写成近三十页的公司层面执行规范。
我们不谈这事的好坏，想一想这真的能落实吗？花大力落实了，对产品质量起到多大的作用？
3、误解：测试＝质量
测试人员不停地声明“测试不能提高产品质量，甚至难以保证质量”，但人们仍然认为“测试＝质量”。为什么？从很多公司对测试团队的部门命令就可以窥见一二——质量部门。
如何做个质量守关者？
在不同的环境下，有不同的风格。有“好人”型，有冷酷型，有放任型。哪种最好？每种都好，存在即合理。脱离环境，我行我素，撞得头破血流，无非成为团队的“烈士”，是否值得，每个人心中有自己的答案。
最后，当我们的团队为达成某个目标，花大力气做了一些事而没有什么效果后，不妨给团队讲一下“醉汉灯下找钥匙”的故事。
-- End --
文末寄语：人人都有三个桶，一桶财富，一桶健康，一桶家庭，总有人更看重第一个桶，最后又什么都没守住。