对于QA这个职位，相信没做过的人比较陌生，做过的人做久了就有点迷茫，找了篇文章给大家，感觉剖析的很到位！

　　QA ＝ Quality Assurance ≠ Flow Assurance 。QA是质量保证不是流程保证。“言必称流程”这是流程推行初期的好现象，但经过两年多IPD－CMM流程的推行与实践，“言必称流程”已经显得落后，显得“土”。我们需要发展的看问题，根据质量保证工作发展的状况调整自己的工作内容和工作方式，这可以说是我们工作中的“时尚”。质量保证就是要保证质量，这是大多数普通人朴素而实在的看法，尽管在质量管理相关的学术领域存在着质量控制、质量保证和质量管理三个层次三个领域的划分，并把质量保证定义为产品开发的“过程保证”，但那是建立在“所有的角色职责都被清晰定义，并被有效执行”的理想分工下的。如果“后卫”只管球门前的区域，“中锋”只管球场中间的区域，那这个球是没法踢的。现实中是不存在理想分工的，何况我们的质量体系还没有发展得足够成熟，所以总会有一些责任并不明确的“模糊边界”。“模糊边界”是多事的地带，在这个“地带”，若能有成功的“跑位”，必将展示出显著的绩效。因为这是超出组织预期（或称为组织定义，这只是底线）的良好表现。另一方面，不同组织赋予QA工作的职责是从自己的现实需要出发的，不是按学术界的分工定义QA工作的内容。所以个人认为，在质量体系还不够健全、成熟的情况下，突破流程去作事，突破TR2-TR4，突破过程与工程，突破部门和角色的顾虑，从产品需求分析到开发测试完成，再到后续的升级、割接、维护，各个环节中影响质量的流程问题、技术问题、工具问题、管理问题，都可以成为QA工作的关注点。相对推行IPD-CMM流程来说，这些工作，套用一个流行词，叫“增值服务”。 “增值服务”会赢得更多的掌声。

　　QA　＝　Question, Answer 。QA工作要致力到发现问题，并关注问题的解决。上面说到，各个影响质量的环节都可以成为QA工作的关注点。那如何关注呢？

　　首先是发现问题（Question）。以“医生”的专业身份，以“局外人”的中立眼光，寻找问题并大胆执着的暴漏出来。发现问题，不是比对流程，不是查看实际操作与流程的不符之处，而是要找出影响质量、左右进度、降低效率、削弱效果，进而损坏组织目标达成的不良现状来。这些现状可能包括流程问题、技术问题、工具问题、管理问题等。在矩阵形组织结构中，能够全流程关注的角色很少，能够全流程关注的眼光很弱。这可以成为QA工作的切入点。发现问题之中还涵盖“预警问题”，这就是扁鹊高明于华佗之处。要做到准确的预警问题、及时的发现问题，需要深入实际，密切跟踪，了解现实的操作过程。如果不知道市场需求是通过什么人、什么样的交流方式、什么样的交流对象、什么样的工作量投入、什么样的反馈机制、什么样的写作过程、什么样的分解方法、什么样的表达规格、什么样的承载形式、什么样的评审过程、什么样的变更机率，说白了就是，如果不知道需求形成的各个“环节”，不知道从每个环节中收集有效信息，是不可能发现问题的，是不可能作出“增值服务”的。当开发环境已经变化，（如OI从没集成开发环境到使用USAP集成开发工具），当测试工具已经变化，（如从TCL到CPP　UNIT），当开发模式已经变化，（如从全自主开发到外包合作、ISV开发），我们的质量过程是否能够适应？当客户要求已经变化，（如海外成熟运营商对质量越来越高的重视），当投标要求已经变化，（如SUNDAY对整体解决方案的要求），我们的管理重心是否作了调整？当PM们越来越成熟，当流程已经落地，等等，当这些变化发生的时候，就是问题暴露的时候，就是思考问题的时机。我们需要了解这些变化，跟踪这些变化，才能及时发现新的问题，才能指出我们正确的改进方向。

　　第二是给出方案，解决问题。（Answer）。作为QA个人来讲，在流程层面，给出解决方案或提出建议措施，是QA角色的强项。在工程方法推行方面，在技术改进方面，在管理实施方面，在人员激励方面，是不是就束手无策、无所作为呢？QA是一个可以全流程关注的角色，是一个可以充分发挥协调作用的角色。利用这一点，就可以协调各方力量，组织专题会议，跟踪问题解决，推动共同改进。 这是QA借力行事，关注问题，侧面解决问题的方法。如果QA个人能够独立解决所有问题，那么QA就是Leader了。