测试的权威性

njugui

做测试快3年了。
    刚入道时是手机开发，那时候非常迷信“设计模式”，非常崇拜“敏捷开发”，那时候觉得测试没啥技术含量。
    后来“不幸”做了测试，摸爬滚打了1年多，虽然涨薪比同时来的开发兄弟快，还是迷信开发，觉得测试没啥技术含量，就想着转行。面试过开发的职位，薪水总是不尽如意。后来索性死了做开发的心。
    后来渐渐地入了门，越来越感觉到开发的不足。开发对一个特性的了解程度明显不如测试，对整体的把握常常让人担忧。很多同事总是站在自己的角度去看问题，而不是用户的角度。常常为了新增一个功能而破坏了本来清晰的设计；为了省几行代码而增加程序的耦合性，把不同类型的东西杂糅在一起；有时候甚至把层次关系搞错。很多开发同事还为自己的小聪明沾沾自喜，“看，随便一搞就实现了”，别人提一下意见，就说“实现功能就可以了”、“现在只有这个需求”、“以后再说”、“用户不可能用到“、”外场不可能这样配置“进行推托。事实总是证明，刚开始图省事做的事情，后来要费事的多。
    软件企业可能都要经历这样的过程：
    起初开发很强，测试很弱，测试什么都听开发的，遇到争议最终开发说”无法实现“就搞定；这个阶段的产品质量可想而知，只能是实验室产品。
    后来测试实力逐渐增强，当然开发也在增强，很多资深的开发人员变成了SE（系统工程师）。遇到争议测试终于说上话了，开发”无法实现“现在已经蒙不了测试了。只好请第三方的SE裁决，测试往往失败。为什么呢？因为现在的SE还是原来的开发，他们的思维是差不多的，他们往往说”需求文档上没有写“，而所谓的”需求文档“就是SE写的。这样会造成什么情况呢？很明显的，SE写的需求并不等同于客户需求。这个阶段虽然能满足部分商用，但往往有这样的情况：客户会不断的提新的需求，SE不断的做新需求设计，开发疲于改代码、加补丁，产品质量很不稳定。QA虽然作为第三方，但这个阶段的企业，QA往往没有真正的技术实力，只是一个摆设。
    聪明的管理者迟早会发现上述的问题。SE虽然是精英，但并不代表着客户，客户的代表应该是测试。一个产品做的好，测试应该有很高的地位。优秀的测试人员除了保证产品的质量，而且关系产品的前途；测试除了想客户之所想，更应该想客户想不到的地方。现在有些公司也到了这个阶段，它们有很成熟很稳定的产品。

wangjingying

基本非常同意LZ的观点，不过还是觉得有些地方值得讨论，特别是“客户的代表应该是测试”

fengyajingling

支持楼主···不过我想一个产品的成功与否···不是简简单单的由哪个部门可以左右的···