相信搞软件的平时听的最多的就是你们的产品质量不好，你的代码质量差，缺陷多。那么凭什么说我的质量不行呢？往往就是通过代码缺陷率来作为参考的依据。缺陷率一般指的是1000行代码有多少个bug。那么bug怎么算呢？测试说了算呗。开玩笑的，他给你提了问题单而你认了，那就算了。问题单的严重程度不一样，分提示、一般、严重和致命，然后有个加权算法，比如提示按0.1算，一般按1算，最后得到一个缺陷值。
那么再问一句，凭什么测试说是问题你就得认？那肯定得有你认同或者抵赖不了的东西是吧，这个往往就是设计方案、需求文档了。这两个东西相当于开发和测试都承认的合同了，两边都按这个合同来核对，对不上那只能自认倒霉。那要是合同本身有问题呢？找写合同的人呗，给他提单。测试可以给架构师提单，但给客户提单的是产品经理或者项目经理，由他们去跟客户沟通并发起需求变更。
不扯了，软件质量的控制点我个人觉得就两个：一个是评审，一个是测试。而评审先于测试，重于测试。瀑布开发模式的输出件就是各阶段的文档，而其中很重的就是评审文档。如果评审缺陷率不达标还得输出例外报告。敏捷是交付软件产品并通过迭代来推进，评审文档的输出可以由各项目自己决定。评审文档主要有需求、方案设计、代码、测试用例，方案设计对于瀑布模式来说包括概要和详细，敏捷的详细设计叫story设计。测试包括开发自测试，开发转测试后有单元测试集成测试和系统测试。checklist我认为也可以归结到测试范畴里去。前期评审充分可以减少返工。测试覆盖率高可以减少漏测。而这两个问题都是比较严重的，往往会把问题带到生产环境。
质量保证是监控过程中的质量动作，确保相应的动作做规范、做标准。比如敏捷提倡的测试驱动开发是一种很好的保证质量的手段，但开发不愿做，那么QA可以进行监督强制开发按要求做，确保该动作的实施。迭代回顾会议也是保证质量的做法，它会分析之前做的不规范的地方，总结经验，以史为鉴。