质量保证和质量控制的区别

　　从目前国内不太理想的情况来看，QA工作往往靠"意向性、模糊"的企业文化来代替， 我认为，完全依靠这种企业文化来造就合理成熟的工作套路，显得过于间接和不确定。因为在人员变动较快的软件行业，新入职的员工理解和认同企业文化并准确映射到具体工作中需要一个明显的滞后时间。这个弊端在小企业中不明显，但在大企业中会比较突出。所以，有必要建立起一套通用的QA工作标准模板，并在重要的大项目中指派专人担当QA人员。 QA人员要实时追踪了解、监督、评估项目中各种事件（现象）是否符合规范的流程？现有流程是否有效率？低效事件是因未被流程涵盖还是流程缺陷所致？就是说，QA人员要有"透过现象看本质"的抽象分析总结能力，项目中每个配合失误的"掉链子"现象，都会触发他的思考并提出改进建议。

　　经过这样的努力， QA人员能从一系列个性化项目中不断地抽取出有效的、有普遍意义的流程优化经验和建议，它们被项目管理办公室（PMO）确认后，会不断地 沉淀、纳入（归档）到企业的过程资产当中，成为今后企业的项目管理的通用工作指导。这样，具备成熟、可操作性的企业文化并不断进步的另一个"IBM"就会由此诞生，企业也就有能力把更多的项目做成"项目组合"（Portfolio）了。

　　QC是最后一关

　　QC工作是指测试人员检查开发人员的产品是否满足预期的品质要求，并给出改进建议。QC服务于开发工作，处于开发工作的控制之下。更贴切地说，QC并非直接"控制质量"，而是"需求印证/确认"（Requirement Validation）或产品测试。

　　由于QC是"用现实应用场景来评测开发人员理想化思路"的过程，所以项目经理必须重视这个依靠创造力、想象力的QC工作，投入足够资源保证QC工作。这是产品发布的最后一道关口。

　　QC工作，是要把程序员"纯真的技术理想"锤炼成鲁棒性极好的应用系统。测试人员需要站在软件技术和用户应用场景之间，反复、全面地检查验证二者的映射关系，还要分析"BUG越改越多"的成因并说服、帮助开发人员澄清和遵从产品版本的质量底线。测试人员不得不经常在很紧张的时间压力下，以清醒的探险性、逆反的批判性思维来全面细致地"围捕"程序员的疏忽。这就要求他要比程序员更快更准地理解用户需求、软件架构；并在接受新项目的时候，头脑迅速切换到不同的用户应用场景。即，他要有更强的跨行业学习的能力。这种能力，往往是程序员难以具备的。

　　理想的测试人员还应该具备"并发思维"的能力，以便捕捉多个程序员之间在多任务场景下极其容易发生的共享冲突。他还应该熟悉数据库建模和SQL，以便排查出隐患很大的、程序员和用户都难以察觉的垃圾数据并判断出成因。

　　由此可见，那种对测试人员常见的"编程能力不行的人，才去做测试"轻视观点是错误的。测试人员业务素质的提升空间很大，他的价值也应该得到更长远的推动和提升。

　　QA、QC是各不相同的重要工作，需要不同素质的人来担任。不应该认为"QA和QC可以合并"，也不应该忽略哪一个工作。