第一篇：(软件企业)有效实施QA职能
QA即英文QUALITY ASSURANCE 的简称，中文意思是品质保证，其在ISO8402：1994中的定义是“为了提供足够的信任表明实体能够满足品质要求，而在品质管理体系中实施并根据需要进行证实的全部有计划和有系统的活动”。有些推行ISO9000的组织会设置这样的部门或岗位，负责ISO9000标准所要求的有关品质保证的职能，担任这类工作的人员就叫做QA人员
无论是ISO9000还是CMMI，都是以过程为中心。也就是说，通过过程的持续改进来提高产品质量。而过程质量与产品质量如何正向关联呢？就需要质量保证（QA）。这也是ISO9000和CMMI都很推崇的方法。但从国内软件企业的现状来看，很多企业的过程体系都相差无几，而开发出来的产品质量却千差万别。导致这种差别的原因有很多，过程及其执行方式的生搬硬套就是其中很重要的原因之一。
在建立QA组织的时候，多数企业也这样实行“拿来主义”。就像看着别人穿着一双非常漂亮的鞋，就想拿过来自己穿，一般都不会适合自己。其结果要么是打肿脚穿大鞋，要么是削足适履，效果可想而知。我们应该做的是“量脚买鞋”、“量体裁衣”。QA组织的建立也一样，应先了解企业的文化、可获得的资源以及过程成熟度水平等，再据此选择适宜的QA组织。下面我们就从一个动态的视角来探讨QA组织的建立。
QA的职责是什么？负责质量保证。
在谈QA的职责的时候，首先要了解质量问题会出现在那些方面，因为这是质量保证的重点。我们经常说，质量是制造出来的，是设计出来的，所以QA对整个过程都应该跟踪。但是如果是整个过程跟踪，就出现了缺少重点的问题，没有重点那就难以监控了。所以必须要了解整个开发过程中那些是必须被监控的，那些是可以放松力度的，那些是不必要去监控的（这些根据公司对QA的定义而要求不同）。在确定了这些事情后，就要对必须被监控的东西进行分类，进行排序。这样可以让QA的主要经历放在关键地方（一般来说，中国的软件企业不会要求到一点问题都没有，所以有的地方可以放松，这也是出于成本的考虑）。
在过程中，QA一般比较注重的是过程是否符合规范？测试是否合理、充分？评审是否及时、有效等，这些是重要的“检验”过程，可以列为重点。对于过程符合规范来说就比较复杂了，首先要看过程有没有计划，计划详细与否，可行与否，工作量评估是否可行（主要是检查评估方法）？日常管理是否可行？配置管理是否可行？过程遵循那些标准？实施什么样的裁减......QA在做这些工作的时候，必须遵照公司的要求进行，如果公司没相关规范，那你就中奖了！除非你懂得项目管理，可以从中知道PM，要不然，嘿嘿......在整个过程的监督中，QA需要具备一定的数据意识，要不断的收集各种数据，尤其是质量数据。现在大多数的QA基本只是收集与时间有关的数据，这是不够的！
QA最好具备一定的项目管理经验，要不然，你只能是一种边缘参与，是进入不了项目的。最好能帮助PM将问题分析清楚。PM会思考要将问题做成什么样子，而QA可以思考如何去做，这样就可以达到一种配合的效果。
其次还要注意一点，就是QA以什么心态去监控项目组，我们公司提出的是“质量服务”，也就是说，项目组是我们的客户，我们是为他们提供质量服务的。
QA不是监督人，但是必须了解人！
QA应该注重过程！
QA应该加薪！
QA应该升职！
.......除了主持人讲的这三方面，质量管理、沟通能力、软件工程能力，我认为还有项目管理经验也是非常重要的。至于说到学历，一般来说，希望QA人员一定是在本科以上，也有专科毕业素质很好的人，招聘的话首先要求本科以上。另外从个人素质上来讲，沟通能力是非常重要的。还要求有一个非常好的工作主动性和好的团队意识。质量管理的知识也是很重要的，但从中国目前的QA现状来讲，项目管理的经验比质量管理的知识获得更加困难，用友在培养自己QA的时候，会更多的关注很好的项目管理的经验，在用友我们也有很多这样的例子，当一个项目完成以后，项目经理经过一个疲惫期，让他轮换到QA部门做一段QA工作，我们的要求是至少做三个月，这样的话，有很好的质量管理背景的QA，和具有很好项目管理经验的项目经理，就可以互相的学习，项目经理基于他的很好的项目经验，一般他可以用比较高的效率发现已经存在和预计将要发生的问题，通过预防将要产生的问题，会使质量成本大大的降低。有一些项目经理做QA做了几个月以后，再回到项目中去的时候，就会发现他现在管项目和原来没有做QA的时候，有很大的差别。
主持人：企业在招聘QA人员的时候，有什么具体要求？
刘清富：刚才我也谈到了，百度一直寻找优秀的人员包括经理级别的人来加盟百度，我怎么选一个QA人员，或者我在面试的时候怎么选QA人员，我觉得百度建立了一个很好的技术的体系，这个体系大概是什么样的要求，我们仅在QA等级方面就分七个等级，什么样的层次做等级
一、等级二，跟你招聘人选的时候有很大的参考性，我招聘人的时候要看他的能力是符合我们的等级
一、还是等级二。这样的时候我们要判断一下，我对他判定的时候，掌握的过程改进的基础知识怎么样？他有没有这方面的成功的实战经验。互联网调查的数据我也是赞同的，大概47％的人有QA经验很重要的。其次是沟通能力网上调查是30％，百度也是非常重视沟通能力的，不仅有QA的能力和背景、经验，或者有更高等级CMMI的经验，而且有良好的沟通能力，因为你做QA是跟人打交道。
你对互联网的敏锐性，或者你怎么融入一个你从来没有涉猎过的行业，这是很重要的，对整个的行业，假如你对互联网非常的熟悉，你非常的敏锐，这样你做QA的时候，你很快能捕捉到你对QA遇到的问题，你对产品非常了解，你对QA更有发言权，你不仅能做过程的审计，还能做产品的审计。百度提供了很好的体系，也在招聘QA人员，也有一些基本的要求。
嘉宾主持Bluesky：那么在选择QA人员方面，是以内部培养为主还是外部招聘为主？
刘清富：对于百度，外部招聘占很重要的成份。百对有这个部门的构建，但没有太长的时间。他和用友不一样，内部有轮岗机制。我们百度有一个很专门的机制，如果没有百度QA的经验的话，是很难涉猎这个角色。如果做的话，可能没有做到位，没有发挥QA的作用，百度还是倾向于从外面招聘人员，这方面如果有网友想加盟百度，可以访问百度的网站，给百度投简历。
嘉宾主持Bluesky：QA团队对公司都起哪些作用呢？于老师如何通过咨询和评估的经验来介绍SEI的CMM和CMMI模型对QA有哪些要求呢？
于波：SEI的CMM模型中强调的是软件质量保证（SQA）的独立性，即SQA要独立于其所进行质量保证的项目和项目的所在部门。也就是说，SQA要在行政管理上不隶属项目和项目的负责部门。刚才两位老总谈到QA向QA经理和更高层管理报告，这也是CMM所要求的另一个SQA发挥职能的&ldquo独立上报渠道&rdquo，尤其是发现的不符合问题要逐级上报并跟踪问题的处理直致结束。如果SQA受技术高层的管理，而且技术高层之间对SQA职能和价值有很好的理解，如刘总说，SQA和项目间的对立和协调就会顺畅和协调一致得很好。SQA的价值和作用的有效发挥，还受到企业从上到下各个层面对SQA价值和作用的认识、SQA资源的选择和投入的影响。
在一个企业中，QA也好、开发工程师也好、或承担其他角色的员工，他们的目标都是一样的，他们都是企业的产品或服务质量链条上紧密相连和不可或缺的各个环节，他们之间没有完全或绝对的对立的关系。SQA要对项目相关的各种过程活动要遵循过程和规程进行评审，并对工作产品应遵循的标准规范进行审核。SQA除了工作能力、经验之外，还要对已建立过程和技术的了解。QA对整个商业目标和高层领导负责。
CMMI模型进一步强调的是过程和产品质量保证和评价，即PPQA。虽然对QA的独立性放宽了要求，提高了实施PPQA的灵活性，但更加强调了PPQA功能的客观性。PPQA人员可以在项目间交叉，但还是不允许项目成员做本项目的QA。
另外，到目前为止，大家的讨论还没有涉及到的一个话题，即QA做检查或评审与审核，并不是他们想查什么就查什么。QA要检查的内容在公司的过程、标准与规范、或质量体系中已经完全定义好了，并遵循QA的计划来执行的。QA要对过程活动评审和工作产品的审核，他们除了对过程和规范要熟练掌握外，其开发等各个环节的工作经历、经验，软件工程的知识，沟通能力也是十分重要的。
傅纯一：刚才听了三位老总讲了之后，很受启发。我同意谢总的观点，成熟度低的企业要求有更多的QA人员，成熟度高的企业QA人员可以少一些。我想补充一下，成熟度低的企业对QA人员的素质要求更高一些。在成熟度较低的企业，在项目、组织各个层次，都缺乏成熟的流程。这时候QA应该起什么作用呢？第一他应该制定流程；第二是要使开发团队按这个流程来进行开发实践。在这种情况下，我认为QA的资历、对软件工程的认识都要比一般人员高。他们相当于内部的咨询人员，来向项目团队提供咨询工作，指导他们如何执行流程，用规范的流程来保证产品质量。相反，成熟度非常高的企业已经有了流程规范，整个开发团队都在按照企业的流程来进行软件开发，所有的开发人员这些工作流程已经习以为常了，他们就不太需要QA的指导，这个时候QA更多是起一个监督的作用。QA的另外一个重要职责就是要不断根据企业发展的需要来改进现有的流程。从这个角度来说，如果企业要做基于CMMI模型的流程改进工作，这个工作一般都是由QA来主导的，就是要做流程改进，这就是QA部门比较重要的一个职能。刚才谢总也谈到，用友的QA部门里面有一个小组就是来做流程改进的。总结一下QA的职责，一方面是制定流程并且保证流程的执行；另一方面就是不断搜集项目团队反馈，不断根据企业发展改进优化现有流程。
主持人：现在聊天室的网友讨论的非常激烈，傅老师您刚才提到在小型企业里面，QA的职责比较多一些，对QA的要求也要高一些。有一些网友问，如果是这样的话，那还要项目经理做什么？项目经理做SQA，不是自己检查自己吗？很多公司并不乐意让项目经理拿出一部分时间做SQA的工作。还有的说可以轮流做。又有网友说项目经理应该做其他项目的SQA。各位专家怎么看呢？
谢琳：这里我想澄清一下，我们在用友的做法，是项目经理轮换到QA部门是，是做专职的QA，这时他不再做其他的项目工作，比如说项目经理。一个项目经理在项目中是非常重要的，应该专注于他的工作。
傅纯一：网友们提出的问题，我觉得是沟通上的误解，也需要澄清一下。第一，并不是小型组织要对QA人员的要求更高，正确的说法是成熟度低的企业对QA的要求较高，成熟度高低和企业大小没有关系。还有就是轮岗，无论是刘总还是谢总，他们在招QA的时候都需要有项目管理经验，只有你做过这件事情，才能有经验、有能力去指导别人，才有切身体会。另一方面，谢总提到在用友有时会交换一下QA和项目经理的岗位，我觉得很有道理，要保证每一个项目经理按照公司的流程来管理项目开发，就要求他很熟悉这些流程，如果他做QA工作，就会增加他对流程的了解，这样能够保证他在项目开发过程中，真正把公司的流程实践进去。另外，项目经理其实和QA的职责还是不一样的，项目经理要保证项目按时完成，QA是要保证这个项目质量健康发展，能够和公司制定的流程不相违背。为什么公司要制作流程呢？主要是希望通过流程来保证产品的质量，使项目能够按时完成，并且控制开发成本。在实际项目中，项目经理往往迫于各种压力，如客户需求变更、紧张的开发进度等等，不会完全按照流程来做，如跳过单元测试、代码评审等环节，这就有可能带来质量隐患。这时候需要QA站在第三方的角度来看，对他进行一些提醒，使项目在关键点上能够不折不扣地按照流程来做。大家有一些误解，说QA是警察，和项目经理水火不相容，这些都是误解。在成熟度比较高的企业，这两个角色应该是互相配合、互相支持，共同把工作做好。
于波：网友们刚才提出的问题属于不在同一个现场而产生的谈话沟通和理解上的问题。前面提到了QA在企业里面的设置比例，刚才有一个是按规模调查的。SEI对企业QA比例的统计一般占开发资源的3%--7％这样一个范围。但这并不是说小的企业成熟度低的企业QA少，成熟度越高、越大的企业需要QA多。随企业过程能力成熟度的提高，所有员工对过程和规范的理解和自觉遵循的意识会提高，QA发现的问题会相对降低。另外，还要与业对QA的重视程度、QA人员的流动和培养等因素有关。有的企业注意把有经验的人放在QA上，但不一定是永远做QA，像谢总所说到的要搞一个轮岗，增进整体的过程和质量意识。QA资源的投入比例和是否有效发挥QA的作用不是一个简单的百分比的范围就可以说明的，应该从QA的工作量、发现的问题数，问题的分类，产品交付后又发现的问题等等之间诸多数据的综合分析来进行评价QA的有效性和如何进一步改进产品的质量。
再一点，刚才傅总提到了，他所谈的QA已经更广义上的了，即包括了过程改进人员（SEPG/EPG人员），所以QA不但要建立过程、监督过程的实施，还要进一步改进过程。他们企业也是在这个大的范围下做质量保证的。所以，因为我们与网友不是一个面对面的沟通，在文字上理解可能有差异性。
不同的QA职责(2009-04-01 17:58:54)
简单务实的回顾一下我经历过的QA的职责定义，工作内容以及人员要求的不同。
QA=quality assurance，质量保证，为了精确区分，有时候也会在前面加上定语，比如SQA，S=software，也就是软件质量保证。对应到角色的话，还隐藏了一个Engineer，也就是还在工程的范畴内，工程师的一种。
质量不用多言，定义虽然不统一但概念个个清晰，不过保证这个词就不好理解了，质量要怎么个保证法？正因为所见所需不同，各家公司对QA的非官方定义才精彩纷呈各有侧重。1，QA近似于外审
QA完全独立于研发之外，偏重管理而非工程，对项目来说，除了在启动，结束和里程碑这些key point进行review和audit外，基本不干预研发过程，项目经理很可能是项目的唯一接口，基本不和工程师接触。QA对产品质量无关联责任，专注组织级过程资产库的建立维护，流程推行主要教化到项目经理。另外负责质量相关外联，比如外审接待和认证过程等。QA亲近核心管理层，所以被赋予很高的权利，比如里程碑评审不通过费用就受到限制。对于项目成员来说，QA工程师是天边飘来的一片云，遮一下就过去了；对于项目经理来说，QA工程师是上面派来滴，没必要得罪，问题都应下，有则改之，改不了化之。
因为偏重于标准和过程的管理，要求QA工程师对规范的标准和过程要非常了解，达到学院派的水平，对项目研发的需求和技术要求很低，文案的工作比较多。
这样出身的QA，我知道有的就去了专门的做标准认证或者咨询的公司。2，QA是研发一分子
QA就是研发的一个团队，QA工程师是把研发总监的非技术需求实现的工程师，一切行动听部门最高领导指挥，无论业界怎么做而是研发总监想怎么做，在某些时候某些领域，QA和总监助理的职责有些分不清。QA工程师和研发团队的各种角色尤其是工程师沟通紧密，常常involve到研发过程的细节中。
因为行政权利和质量要求高度统一，QA和项目团队都是自己人，所以推行流程相对容易得多，也没有太多繁文缛节，但更多是关门做事，不关心业界的最佳实践，QA可以不熟悉外面流行的模型却不能不熟悉内部用的技术和过程。在QA从研发团队剥离出来并入质量部门后，问题就出来，研发总监护犊的行为比较明显，不再像原先那样支持QA的工作，因为QA代表的更多的不再是他的需求。QA会成为不同部门总监角力的棋子。3，QA是项目经理之一 在复杂的大项目中，QA工程师是质量部门出具的项目经理，代表身后若干支持团队，更多的参与到项目管理和实践中，要对质量相关的事务和结果负责。
QA工程师常成为program manager或者product manager制衡R&D项目经理的棋子，所以需要和很多层面的manager打交道，对于向上沟通的能力要求比较高。这一点其实隐含了对QA工程师的要求是全面的，如果他理论不清或者技术不熟或者人格有所瑕疵，在Engineer那里不过是let it be，在manager或者director那里却会成为被反击的致命弱点。4，QA就是测试
这种定义的理解就是通过测试来保证质量，QA过程是研发过程中的一个环节，要求的是对业务需求的理解和测试能力。我没有这种定义下的岗位服务经历，且这样的定义也不是我辨析的针对，所以不做多说。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
发现一个问题：会写的越来越多，但是又没有时间担负起长篇大论，结果就是讲了意犹未尽而且不透彻。
有效实施QA职能
一、概述
许多企业在建立研发管理体系时，尤其是实施CMMI时，都需要建立一个QA组织。但由于缺乏经验和指导，只能摸着石头过河，先从各个部门抽调一些新人和“闲人”成立一个部门，按照规范要求试试再说。这样尝试的结果，往往是走了弯路，一切回到原点。
还有一些企业已经成立了QA部门，QA的职责就是保证过程体系一板一眼地得到严格执行。而研发人员却认为QA只会站在研发环节之外指手画脚，像警察一般指责研发人员的不是。而QA人员对此也相当委屈，“我是照章办事啊”，得罪了人不说，还可能对自己的工作内容感到迷惘。这样的QA部门，在其它部门的眼中“可有可无”，在老板的眼中是“白白增加了管理成本”。
二、QA在不同组织结构中的组织形式
质量体系的建设是一个系统工程，它存在的形式不仅是一套质量体系文件和质量管理部，它更体现为一个企业的质量文化和质量文化在企业的贯彻实施。软件企业在规划质量体系时往往会选择一个模型，如ISO9000、CMMI、XP等。具体选择何种模型，还要看企业的实际情况，充分协调人、技术、过程三者之间的关系，使质量体系能够充分发挥作用，促进企业生产力的发展。质量文化的形成和贯彻实施与QA组织的人员构成、角色定位有着密切的关系。同时，不同企业的各种组织结构也影响着QA组织的建立和作用。根据对一些企业实际情况的调查，以下分别介绍职能型组织结构和矩阵型组织结构中，QA组织的区别和各自的优缺点。
1.职能型组织结构中的QA组织
在职能型组织结构中，各个职能部门可能会设立自己的QA岗位。QA独立于项目组，直接向部门主管报告，但在业务上也向项目经理进行汇报。如图1所示。在职能型组织结构下QA组织的优点是：因为同属于一个部门，QA人员容易深入项目组的具体工作，容易发现项目的实际问题，项目组对问题的处理也更快捷。缺点是各职能部门相对独立，部门之间缺乏经验的交流和共享。不同部门还可能重复进行过程、方法和工具的研究。而且，企业中普遍存在“重业务，轻过程”的现象，QA的工作与业务工作相比显得无足轻重，QA人员的职业发展更容易受到忽视，很难接受应有的培训和提升。
图1 职能型组织结构下的QA组织
2.矩阵型组织结构中的QA组织
在矩阵型组织结构中，企业设立了专门的质管部，QA人员由质管部指派到各个项目组。QA独立于项目组和职能部门，在行政上向QA经理报告，业务上向项目经理报告。如图2所示，在矩阵型组织结构中，项目经理对QA的工作绩效有建议权，但由QA部经理对QA进行直接考评，这既有利于保证QA工作的独立性和评价的客观性，也可以保证QA组织的长期利益与项目的短期利益之间的平衡。QA资源的分配是根据项目特点、工作量和进度而确定的，同时考虑项目优先级，对QA人员进行动态调配，保证更加充分地利用资源。一个软件QA通常可以负责5个左右的软件项目的质量保证工作，硬件QA可以负责2、3个项目的工作。
此外，由于QA人员直接面对项目组开展工作，非常了解过程运行的情况，更容易发现过程改进的“短板”，所以QA是改进过程实施的重要推动力量。因此，许多企业的质管部还担负了组织级质量体系的优化、过程资产库和度量数据库的建立、维护和使用的职能。质管部甚至还可能包括了企业级IT系统规划、建立和推广实施的职能。这种情况下，质管部成为QA人员的资源池，一方面负责为项目输送QA人员，另一方面关注培养QA人员。可以有效避免职能型组织结构中不同部门重复投资于质量体系、忽视QA职业发展的问题。
在矩阵型组织结构中也有一个问题，由于QA和项目组分别向不同的领导负责，因此相对而言，QA较难融入项目组深入发现问题，而且可能常常遇到QA与项目经理很难就一个问题是否成其为问题而达成共识的扯皮情况。对于这种情况，可以通过问题的“上报”机制来解决，即对于QA与项目组协商后仍不能解决的问题，QA可以直接报告职能部门主管和质管部经理，通过高层协商和协调资源来寻求问题的解决。
图2 矩阵型组织结构下的QA组织
三、QA的三大角色和职责
1.QA的三大角色
CMMI标准文件说，QA是高级经理的“ears and eyes”。研发人员眼中的QA往往也是“警察”，QA的作用似乎仅限于发现和报告项目的问题。其实，一个合格的QA在项目中会充当三种角色：
角色1-老师，具备学习和培训的能力。
角色2-医生，通过度量数据对项目过程进行诊断，帮助分析原因，开处方。
角色3-警察，以企业流程为依据，但要告诉大家流程背后的原因；如果和项目组针对某些问题意见相左，可以直接汇报高层。
典型的QA的职责包括了：过程指导、过程评审、产品审计、过程改进、过程度量。
◆ 老师的角色——在项目前期，QA辅助项目经理制定项目计划，包括根据质量体系中的标准过程裁剪得到项目定义的过程，帮助项目进行估算，设定质量目标等；对项目成员进行过程和规范的培训以及在过程中进行指导等。
◆ 警察的角色——在项目过程中，QA有选择性地参加项目的技术评审，定期对项目的工作产品和过程进行审计和评审。
◆ 医生的角色——在项目过程中，QA也可以承担收集、统计、分析度量数据的工作，用于支持管理决策。
在CMMI中，度量分析是一个单独的过程域。CMMI成熟度等级越高，对度量分析提出的要求也越高，难度越大。相应地，QA人员应该具备的能力要求就更高。那么，在企业的实际操作中，QA到底是老师、医生还是警察？或者三者皆
如果企业计划进行CMMI评估或者经过评估已经达到了某个成熟度等级，那么这些企业中的QA应该做到以上所列的所有工作，这是为了满足CMMI要求的必须。但如果仅从企业自身业务和管理的需要出发，考虑到企业文化，就不一定非得要求QA既当警察又当老师和医生了。例如，企业认为同行评审投入资源多，产生效益却不明显，QA应加强对同行评审过程的监控，因此QA可以承担同行评审会议的组织和协调工作。而有些企业则是由项目组按照流程自行组织同行评审，QA只是抽样参与评审过程进行审计。如果企业有外包业务，则QA应该作为外包过程和产品质量监控的主力。
2.不同过程成熟度等级对QA职责的要求
CMMI不同成熟度等级对QA职责的要求有较大的不同，过程成熟度是影响QA工作分布很重要的因素。成熟度等级较低时，由于过程体系尚处于建立过程中，员工的过程意识不强，所以QA的工作主要集中在收集最佳实践、定义过程体系和培养员工建立过程意识方面。随着过程体系的实施、完善和制度化，QA的工作重点转移到过程评审和产品审计。当企业达到了高成熟度等级，即4、5级时，过程的执行已经高度制度化，成为员工的工作习惯，因此过程评审和产品审计所需要的工作量也大量减少，而定量管理需要QA作为专业人员更多地投入度量分析工作中。组织级的过程变革、技术变革等过程改进工作是5级企业对QA最主要的要求。如下图所示，随着成熟度等级的变化，QA花费在过程指导、过程评审、产品审计、过程度量和过程改进方面的工作量分布也不同。
图3 不同成熟度等级对QA职责的要求
五、谁是合适的QA人选
QA人员可以来自于企业的各个部门，既可以由专职人员担任，也可兼职。但很多企业的经验证明，选择一些新人和“闲人”组成的QA部门往往只能构成形式上的QA组织，却不能胜任企业对质量体系寄予的重任——保证逐步实现产品零缺陷、工作零错误。那么，企业应该选择什么样的人来担任QA才能有效地行使QA的职能？
1.QA应该具备的能力
在选择合适的QA人选时，企业应首先考虑他们的知识、技能和素质能否满足组织和岗位的要求。具体而言，可以从软能力、项目管理经验、软件工程经验、项目业务知识，以及对过程体系的熟悉程度等方面来考察。“软能力”是指创新、团队精神等不太容易评估但又非常重要的素质，软能力的培养不是一朝一夕的事情，而是一个潜移默化的渐进过程，它的形成则更多依赖于自我修炼。这好比我们在政治课上能学到政治常识，却不一定能提高政治觉悟一样。QA
人员如果没有实际参与过项目/产品的开发，没有从事过项目管理工作，或是从有些部门抽调来的工作相对比较“轻松”的人员，即便他们熟读背诵了整个过程体系，仍然很难成为企业真正需要的合格的QA。
企业由于成熟度和企业文化的不同，对QA的期望也很不同。比如一个沟通协作差、部门墙林立的企业，QA的软能力，尤其是团队精神和沟通协调能力可能是最重要的要求；对于一个高过程成熟度的企业，对QA的要求则不仅仅是对过程体系的熟知，而要求QA同时具备深入的业务领域知识，并且是一位度量分析的专家。
2.EPG和QA人员的7种素质
EPG，即工程过程组，是过程改进的主体，QA的素质：
1.真正相信过程改进-只有发自内心的相信才能感染别人。
2.自我激励-即便身处逆境，也可以克服不良情绪振作起来。
3.不畏惧失败-我们的任何工作在第一次做时不可能完美。
4.引导和激励其他人-只有几个人的改变不代表整个组织的成功。
5.分清工作轻重缓急层次清晰-平衡工作的长期目标和短期利益。
6.不断充电-不断学习、思考、实践、再学习。
7.开心地工作。
六、总结
企业在建立QA组织时，应根据自身的需要，考虑到企业文化、成熟度等级，以及可获得的资源等因素，因地制宜。“抓壮丁”式地选择QA人员，绝无利于企业的质量体系发挥作用。只有选择了合适的是过程改进实施的重要推动力量，他们应该具备以下7种基本
QA组织形式，QA人员具备相应的能力和素质，才能保证质量管理体系良好地运作，从而现产品零缺陷、工作零错误的最终目标。
第二篇：鸿业软件感想建议及QA
1.经验大家谈：
（1）刚开始时候没有重视教学视频，主要依靠组员们的摸索自行制作。在摸索的过程中，对鸿业软件各个按键以及功能有了一定程度的了解，但是因为大部分不太了解，最后越做越乱，出现很多不能理解的线。后来重做，按照教学视频一步步来，加快了进度。
（2）图左下角河流下游左方有一块区域，刚开始发现没有红线，无法分排水区域。尝试了很多方法，例如自己画红线等等。到最后发现是X-road图层没有打开。觉得有些事情特别麻烦的时候，肯定是自己想错了，要静下心所探究一下。
（3）雨水水力计算，提示部分管道过流能力太差，计算书里面显示那些管道的直径为复制，检查井和管道连接情况没有问题，检查了好久也不知道为什么。最后换了台电脑自动解决了，但是没有找出为什么。
（4）在污水参数块编辑时候，要求输入流量变化系数，但是书上公式根据流量来计算的变化系数。因为每个区域的面积不同，而且区域众多，每个都自己手算的话，工作量很大，但是又没有找到便捷的方法。
（5）最后计算书里面坡度有一部分小于0.003，刚开始手动改坡度，造成了有些地方埋设深度过大，或者在计算的时候又出现了一些问题。所以就保持了原来的坡度。
（6）鸿业软件是一款优秀的给排水设计软件。9.0版本的功能相较于以前的版本有了很大的改进，更加自动化，节省了很多时间。不足之处是在进行给水区域自动划分时，不同的区域的参数块要一个个的修改，比较麻烦。（7）作业类型不同，其制作特点也不同，需要边看教学视频边做，不然会出现令人意想不到的结果„„软件的一些功能还需进一步了解，才能做出真正的工程图，目前我们做的只不过是一个体验，做好一个工程师恐怕还要十年功吧。
（8）再应用鸿业软件过程中，经常遇到意想不到的bug：比如污水赋井地面标高时，出现了离散点可以赋到点上，但是无法赋到井上的情况，这种情况的出现使得设计进度严重被拖后，总共尝试了近一周之后，才在一次机缘巧合的情况下，突然附上。当再次尝试给其他组赋值的时候，上述问题再次出现，问题无法解决，只能靠运气。鸿业软件在赋值的时候程序运行不顺利，而且如果仅仅一个点没有编号或者在离散点外，整个赋值都不能进行，希望软件对这点进行改进。
（9）随着作业进展我们渐渐发现，给水的重头戏在管道计算部分，需要反复计算和复查。软件本身可以运行自行计算，但是一些理论知识我们稍显欠缺，在关键时刻不能清晰地说出为什么。于是在后期，我们细化为专人负责理论部分的支持，其余负责软件的操作计算。经过大家通力合作，后期进行地非常顺利。
（10）在雨水设计的过程中还是遇到很多纠结的问题，首先是定检查进标高的问题，很多同学都无法定标高，但我们组一个同学她的电脑是可以完成的，所以这个问题很容易就解决了。然后就是检查进的编号，按桩号线布管和检查井，编号的时候也是按照桩号线进行编号，但是编号的时候只能一小段一小段的进行，无法整体进行编号，导致这部分工作很累。
（11）在定排水界限的过程中，软件识别道路边界线，使得分得的区域很大，进行参数快连接后有些管道就没有流量，为此，我们手动各个区域进行细分，主要是街坊，道路和一些绿地并没有形成闭合的区域，导致设计过程中没有计算这部分的雨水量，产生了较大的误差。
（12）在设计的过程中间我们遇到了不少的难题，比如由于部分地区的道路坡度较小，导致埋深增加很快，汇入干管后也增加了干管的埋深，为了解决这个问题，我们修改了管道的布局，想办法增加了部分管道中的流量以减少坡度，并对部分管道进行了改道，重新定义了管径等参数，费了不少力气才终于解决。但事实上正是因为这些问题的出现才使我们才真正的了解了排水设计过程，对于城镇污水以及雨水排水都有了更深的理解。（13）在做污水管道设计中，虽然一开始就着重考虑了地形对布置管道的影响，但实际出计算书后才发现地面标高、设计坡度、管径对埋深的综合影响很大，只有协调好其中的大小关系才能使埋深不超标。适当地选择主干管及支管的流向可使事半功倍。
（14）我们出现的最严重的问题是：污水设计中，无法定检查井的地面标高。
解决方法：重新识别离散点标高，并且调整图层，注意不要锁定0图层，并且不要对0图层进行操作，避免发生不可预见的错误，导致无法完成标高的计算。
（15）关于雨水方面的设计，感觉就是软件不是很好用，分排水界限方面，还有布置雨水井方面以及各种工具都超难用，最后计算的时候还是很轻松的，但是图的处理太繁琐了很多地方连接的都不好，导致自动划分面积不成功，高程点有时候也设计不上，然后就没了。做设计作业的过程也是一个搜寻资料的过程，软件不会用，上网搜教程，某一步不知该怎么做，上网搜索，出现错误不知怎么解决，存好版本一步一步的尝试。说实话做给排水大作业很累，在院馆机房一泡就是一个整天，但是当你解决了一个问题，完成一个方案，那种快乐真的是难以形容的。
（16）首先说软件操作。虽然我们在软件操作中遇到了许许多多的问题并且耗费了很多的时间，但是我觉得这个过程还是值得的。这让我们几乎完成了一次有一定的实际操作性的计划——这在之前的课程中是没有的经历。而且自学一个软件的历程也是非常难得的考验我们耐心和毅力的机会。（17）在设计中，我们也走了不少弯路，例如设计管段布置过密，误设零高程点等，花费了很多时间来纠正，对此我们也总结出了较为详尽的操作步骤以及设计的注意事项可供参考。
（18）相比于其他的大作业，给排水的大作业还是非常有分量的。从软件的操作到报告的撰写，我逐渐熟悉了给排水设计的流程，并且强化了记忆。虽然在设计的过程中出现了很多问题，但是每一次解决问题都让我对于这门课程多了一些理解。
（19）总体说来，这次的作业我们组还是合作的不错的。不过希望下一年可以减少每个组的组员个数，这样大家可以从中得到更好的学习。
（20）在软件使用过程中，感觉宏业软件还是有许多待改进的地方，1、可以设置一个说明栏，用来说明计算过程中采用的公式以及流程，方便大家了解软件的计算原理；
2、软件的自我纠错能力不行，比如有时由于人为失误，管道的埋深达到几千米，而软件却没有报错；
3、软件有时候会有bug，一些运算过程得换一台电脑才能操作完成。整体上，这次大作业的收获还是很多的，虽然和实际的工程设计相差甚远，但至少让大家心里留了个底，有个初步的印象。
（21）一个学期，两份大作业，六个人，无数的收获。在整个大作业的过程中，我们遇到了很多困难。求助，挣扎，叹息，彷徨，坚持，合作，分享，喜悦。最后，在大家的齐心努力下，终于完成了开始并不觉得可以完成的任务。大作业分工起来比较困难。如果说分成两个大部分——鸿业软件的操作和论文撰写，要不同的人去完成。可是显然操作的人也会更加清晰的知道整个流程以及过程中的一些假设、取值等，貌似也是写报告的不二人选。这样，任务基本读压在一两个人身上，导致其他组员想帮忙却又也无能为力。
2．常见问题Q&A：
Q：删除标高点时为什么总是选中地块？ A：把地块图层先关掉再删。
Q：以“点选且两端相连管线”方式定给水管时为什么有的是实线，有的是虚线？
A：虚线是已连接起来的管线，实线是未连接的，需要检查将未连接的管线都连起来。一个简便方法时把管线全选，统一定给水管。此外如果给节点编号时出现无法编号的情况，也是这个原因。
Q：定完给水管上，为什么除了交点处有节点，在某些管道中间也有节点？ A：管道中间有节点说明那段管道不是一根管道，要用【平差】—【管线合并】命令将其合并成一根管道。
Q：“按参数块分配流量”时显示“参数块未编号或有重复编号”？ A：自动给参数块编号时，软件可能会遗漏一些参数块未编号，需要手动找出并编号；此外，另一个猜测的原因是有些管道中间有重复的短线，需要用【工具】—【查重合管线】命令检查出来并删去。
Q：为什么平差时出现某些管道流量为0，如”5-5”，并且计算时出现极大的水压？
A：说明在该节点处有一个多余的属于管道图层的点或短线，需要删去 Q：平差时“图面提取”，为什么显示未找到节点？ A：节点图层没开。
Q：布置消防栓，定管道桩号时，为什么显示“路桩号线没有两个端点”？ A：不能选择所有管线统一定桩号，因为是环状管网软件不知道从哪开始，正解是按横竖一根一根定桩号。Q: 软件启动过程中要求多次注册？
A：一般是360问题或者是管理员运行身份的问题，退出360或者点击右键以管理员身份运行即可。
Q：软件启动后不能出现鸿业提示工具栏？
A：一般是因为cad安装版本不对，或者鸿业安装中选择的cad版本不一致，重新卸载安装即可解决。
Q：软件启动后机器运行死机，运行不了软件？
A: 有可能是机器显卡设置的问题，华硕笔记本出现过这个现象。Q：如何定义给水点？管网水塔位置如果定义？ A：可以通过设置节点流量来定义
Q：离散点转化的问题：使用鸿业软件打开任务2的道路标高修改图，有高程文字如439.00等文字标注，直接“地图提标高”时显示“离散点小于三个，无法提标高”。当使用“自然离散点”识别标高时，出现菜单栏有“逐点输入“文本定义”等条目，视频中只说使用文本定义，然后按照提示操作。当我选择文本定义时，提示选择离散点、圆等，我尝试了很多都不行。上课的时候，工程师介绍使用块定位，然后选择all。可是我的软件提示无效块。
A:应该选择“离散点”识别标高方法，通过点选“文本定义”功能，然后按照相应的提示进行操作即可，选择离散点时候可以用all命令全选。块定义的方法适合于任务1底图的标高提取操作。
3.利用鸿业市政管线软件做给水工程设计的几点总结: 市政管线的给水设计一般步骤主要包括设置工程名,管线平面设计,标高设计,平面标注,纵断面图和节点祥图设计几个部分.1)平面设计 即主要完成给水管线的平面布线,主要有以下几个方面(1)布置管线,这方面,我个人的经验是, 尽量利用该软件提供的道路绘制命令重新定原有道路,并定义道路桩号,(注意其命名在后续的标高定义中要用到)根据设计要求确定阀门井和消火栓井的平面位置, 再利用道路边线的偏移准确定位.采用定义给水管道命令,在弹出的给水管道设计文本框中选择管代号和管材,再根据命令行提示选择连线方式便可快速完成给水管线的布置.(2)管线节点位置核定后,即可点取布置井类命令向管线上布置阀门井,室外消火栓等检查井,(注意布置时启用端点铺捉)布置过程中,根据设计要求在相关命令行提示下选择布置.如命令行提示`图形标志处管线是否设置阀门`如果设计中要求,则选Y ,程序据此可初选检查井规格.由于会出现非标准图的情况,检查井规格的最终定型,则是由该井所设的节点管件和设计规范决定,要采用检查井编辑功能重新修改输入该井的标准图号和规格.(3)采用给水菜单中的定义管径命令,选择管道规格一致的管道,即可方便地为所选管段定义管径规格,若在选择管道规格文本框中没有所要求的规格,则须在设置菜单中的管道规格管理中添加相应的公称直径等参数后存盘设置.(4)管线整理命令专用来编辑整理所要修改位置的管线.(5)节点编号, 根据管线形式采用具体的编号方式,对于枝状管网,采用枝状网成组编号,程序将自动搜索连续的各检查井和节点,并快速统一编号,若想将不同类检查井区分开来,则采用逐个编号方式逐个为检查井编号.2)管线标高设计:
即定义节点地面标高和管线标高, 该软件中节点地面标高的确定有多种方式,各标高定义方式也可据其字面意思得知,其中,较为严格的定标高方式应为路标高计算,即根据道路中心地面标高及其到管线处的高差或横坡等参数定义节点地面标高的方式,其具体步骤如下: 利用测绘单位提供的道路纵断面图或标高文件,选用自然地面标高文件菜单项中测量图提取命令,将图面文件转换为与道路桩号相对应的路面标高bgz文件,文件的保存命名要与对应的道路桩号一致,再利用自然标高文件转设计标高文件,将文件转化为bgs设计标高文件.点取桩号和标高文件关联,使道路与其路面标高建立起联系.点取定节点地面标高命令,选取路标高计算,根据命令行提示,选择参考桩号线,即其旁侧布设管线的道路桩号线, 程序将自动检查该桩号线是否关联过道路设计标高文件,并弹出该工程名下的标高文件,选择其对应的标高文件,再选取管线上的相应节点,输入所需参数(如道路横破等),即可为相应节点定义上地面标高.（注意：在利用道路标高定节点标高时, 设计标高文件的起点和终点不能在竖曲线范围内，如果设计中桩号线的起点和终点刚好在竖曲线范围内，如道路中心线的起点和终点处有路弧.须将桩号线向两端进行延长。道路的起点桩号和终点桩号必须包含所要绘制中桩断面的管道, 标高文件桩号范围可包括其所对应的道路中心线的桩号范围。）
管线标高的确定也有多种方式,个人经验是先采用管中心埋深定标高的方式,在生成的中断面图中查看管线的坡度变化,在根据设计要求将管线按坡度和管径变化分成几大段,(以利于施工过程中的接管方便),再采用控制点定标高的方式,选择各段的控制点, 输入控制点处的管中心标高程序将自动找出他们之间的管道,根据它们之间的管道长度采用线性内插的方式计算出管道各端点的标高.另一种比较自由的管高确定方式是断面拉坡方式定标高.3.平面标注:
通过编辑标注命令可快速实现管线的管高,管径,井编号等参数的图面标注.如要查看所做的节点编号可选用标井编号命令,选择标注方式,成组标注,引出标注或逐个标注,若选择成组标注,则还可选择是回车自动定标注位置还是用户定标注位置,选择确定后,程序将自动实现井编号的平面标注.4.绘制管线纵断面图:
在设置菜单的纵断表头项中设置纵断面图的表头内容,在纵断标注设置项中设置管径表示法,标注整桩号等标注方式设置.根据设计要求,选择断面绘制种类,如投影端面,只反映管线在水平方向投影的长短和其竖向比例,没有横向比例的概念,同时在绘制过程中,命令行会提示输入竖向比例,管道基础,断面图中管线的表示形式和管道基础超挖等的参数,选择绘制管线的起点和终点井或节点标志,在图面上点取布置点(纵断面图的左下脚),管线的纵断面图即可逐渐生成.中桩断面的主要特点则是要求道路中心线定义过桩号,且关联过设计地面标高文件,其所绘的断面长度与道路中心线长度相等.若所做的管线中有交叉管存在,则采用拉坡文件绘断面或数据断面的方式,并要求输入交叉管的有关参数.以相同的步骤绘制出断面图.节点祥图设计,在给水菜单中,点取的绘节点图.井表命令中的平面管件项,弹出管件布置界面图,要向图面布置某一管件时,双击其图标,再选择布置方式,在图面上点取其布置位置即可,对于其布置方式,当布置时,若所布置的管件是该井的中心管件(首先布置),则要采用直接点取位置方式,在图面上旋转至指定布置位置(最好启用正交模式),该井的其余所接管件则采用选择要连接的管件的方式,点取所接管件的所在侧,程序将根据所接管的管径默认其接入端的管径.对于渐缩管和旁通管类的管件,命令行会提示输入另一端的口径规格.如此采用交互方式绘制给水节点祥图,绘制时,无须绘制节点管线,对于界面上没有的管件,侧可通过ADD添加新管件命令添加(在出图比例为1000下绘制管件)
第三篇：如何构建有效的QA组织
如何建立有效的QA组织
一、概述
许多企业在建立研发管理体系时，尤其是实施CMMI时，都需要建立一个QA组织。但由于缺乏经验和指导，只能摸着石头过河，先从各个部门抽调一些新人和“闲人”成立一个部门，按照规范要求试试再说。这样尝试的结果，往往是走了弯路，一切回到原点。
还有一些企业已经成立了QA部门，QA的职责就是保证过程体系一板一眼地得到严格执行。而研发人员却认为QA只会站在研发环节之外指手画脚，像警察一般指责研发人员的不是。而QA人员对此也相当委屈，“我是照章办事啊”，得罪了人不说，还可能对自己的工作内容感到迷惘。这样的QA部门，在其它部门的眼中“可有可无”，在老板的眼中是“白白增加了管理成本”。
二、QA在不同组织结构中的组织形式
质量体系的建设是一个系统工程，它存在的形式不仅是一套质量体系文件和质量管理部，它更体现为一个企业的质量文化和质量文化在企业的贯彻实施。软件企业在规划质量体系时往往会选择一个模型，如ISO9000、CMMI、XP等。具体选择何种模型，还要看企业的实际情况，充分协调人、技术、过程三者之间的关系，使质量体系能够充分发挥作用，促进企业生产力的发展。质量文化的形成和贯彻实施与QA组织的人员构成、角色定位有着密切的关系。同时，不同企业的各种组织结构也影响着QA组织的建立和作用。根据对一些企业实际情况的调查，以下分别介绍职能型组织结构和矩阵型组织结构中，QA组织的区别和各自的优缺点。
1.职能型组织结构中的QA组织
在职能型组织结构中，各个职能部门可能会设立自己的QA岗位。QA独立于项目组，直接向部门主管报告，但在业务上也向项目经理进行汇报。如图1所示。在职能型组织结构下QA组织的优点是：因为同属于一个部门，QA人员容易深入项目组的具体工作，容易发现项目的实际问题，项目组对问题的处理也更快捷。缺点是各职能部门相对独立，部门之间缺乏经验的交流和共享。不同部门还可能重复进行过程、方法和工具的研究。而且，企业中普遍存在“重业务，轻过程”的现象，QA的工作与业务工作相比显得无足轻重，QA人员的职业发展更容易受到忽视，很难接受应有的培训和提升。
图1 职能型组织结构下的QA组织
2.矩阵型组织结构中的QA组织
在矩阵型组织结构中，企业设立了专门的质管部，QA人员由质管部指派到各个项目组。QA独立于项目组和职能部门，在行政上向QA经理报告，业务上向项目经理报告。如图2所示，在矩阵型组织结构中，项目经理对QA的工作绩效有建议权，但由QA部经理对QA进行直接考评，这既有利于保证QA工作的独立性和评价的客观性，也可以保证QA组织的长期利益与项目的短期利益之间的平衡。QA资源的分配是根据项目特点、工作量和进度而确定的，同时考虑项目优先级，对QA人员进行动态调配，保证更加充分地利用资源。一个软件QA通常可以负责5个左右的软件项目的质量保证工作，硬件QA可以负责2、3个项目的工作。
此外，由于QA人员直接面对项目组开展工作，非常了解过程运行的情况，更容易发现过程改进的“短板”，所以QA是改进过程实施的重要推动力量。因此，许多企业的质管部还担负了组织级质量体系的优化、过程资产库和度量数据库的建立、维护和使用的职能。质管部甚至还可能包括了企业级IT系统规划、建立和推广实施的职能。这种情况下，质管部成为QA人员的资源池，一方面负责为项目输送QA人员，另一方面关注培养QA人员。可以有效避免职能型组织结构中不同部门重复投资于质量体系、忽视QA职业发展的问题。
在矩阵型组织结构中也有一个问题，由于QA和项目组分别向不同的领导负责，因此相对而言，QA较难融入项目组深入发现问题，而且可能常常遇到QA与项目经理很难就一个问题是否成其为问题而达成共识的扯皮情况。对于这种情况，可以通过问题的“上报”机制来解决，即对于QA与项目组协商后仍不能解决的问题，QA可以直接报告职能部门主管和质管部经理，通过高层协商和协调资源来寻求问题的解决。
图2 矩阵型组织结构下的QA组织
三、QA的三大角色和职责
1.QA的三大角色
CMMI标准文件说，QA是高级经理的“ears and eyes”。研发人员眼中的QA往往也是“警察”，QA的作用似乎仅限于发现和报告项目的问题。其实，一个合格的QA在项目中会充当三种角色：
角色1-老师，具备学习和培训的能力。
角色2-医生，通过度量数据对项目过程进行诊断，帮助分析原因，开处方。
角色3-警察，以企业流程为依据，但要告诉大家流程背后的原因；如果和项目组针对某些问题意见相左，可以直接汇报高层。
典型的QA的职责包括了：过程指导、过程评审、产品审计、过程改进、过程度量。
◆ 老师的角色——在项目前期，QA辅助项目经理制定项目计划，包括根据质量体系中的标准过程裁剪得到项目定义的过程，帮助项目进行估算，设定质量目标等；对项目成员进行过程和规范的培训以及在过程中进行指导等。
◆ 警察的角色——在项目过程中，QA有选择性地参加项目的技术评审，定期对项目的工作产品和过程进行审计和评审。
◆ 医生的角色——在项目过程中，QA也可以承担收集、统计、分析度量数据的工作，用于支持管理决策。
在CMMI中，度量分析是一个单独的过程域。CMMI成熟度等级越高，对度量分析提出的要求也越高，难度越大。相应地，QA人员应该具备的能力要求就更高。那么，在企业的实际操作中，QA到底是老师、医生还是警察？或者三者皆
如果企业计划进行CMMI评估或者经过评估已经达到了某个成熟度等级，那么这些企业中的QA应该做到以上所列的所有工作，这是为了满足CMMI要求的必须。但如果仅从企业自身业务和管理的需要出发，考虑到企业文化，就不一定非得要求QA既当警察又当老师和医生了。例如，企业认为同行评审投入资源多，产生效益却不明显，QA应加强对同行评审过程的监控，因此QA可以承担同行评审会议的组织和协调工作。而有些企业则是由项目组按照流程自行组织同行评审，QA只是抽样参与评审过程进行审计。如果企业有外包业务，则QA应该作为外包过程和产品质量监控的主力。
2.不同过程成熟度等级对QA职责的要求
CMMI不同成熟度等级对QA职责的要求有较大的不同，过程成熟度是影响QA工作分布很重要的因素。成熟度等级较低时，由于过程体系尚处于建立过程中，员工的过程意识不强，所以QA的工作主要集中在收集最佳实践、定义过程体系和培养员工建立过程意识方面。随着过程体系的实施、完善和制度化，QA的工作重点转移到过程评审和产品审计。当企业达到了高成熟度等级，即4、5级时，过程的执行已经高度制度化，成为员工的工作习惯，因此过程评审和产品审计所需要的工作量也大量减少，而定量管理需要QA作为专业人员更多地投入度量分析工作中。组织级的过程变革、技术变革等过程改进工作是5级企业对QA最主要的要求。如下图所示，随着成熟度等级的变化，QA花费在过程指导、过程评审、产品审计、过程度量和过程改进方面的工作量分布也不同。
图3 不同成熟度等级对QA职责的要求
五、谁是合适的QA人选
QA人员可以来自于企业的各个部门，既可以由专职人员担任，也可兼职。但很多企业的经验证明，选择一些新人和“闲人”组成的QA部门往往只能构成形式上的QA组织，却不能胜任企业对质量体系寄予的重任——保证逐步实现产品零缺陷、工作零错误。那么，企业应该选择什么样的人来担任QA才能有效地行使QA的职能？
1.QA应该具备的能力
在选择合适的QA人选时，企业应首先考虑他们的知识、技能和素质能否满足组织和岗位的要求。具体而言，可以从软能力、项目管理经验、软件工程经验、项目业务知识，以及对过程体系的熟悉程度等方面来考察。“软能力”是指创新、团队精神等不太容易评估但又非常重要的素质，软能力的培养不是一朝一夕的事情，而是一个潜移默化的渐进过程，它的形成则更多依赖于自我修炼。这好比我们在政治课上能学到政治常识，却不一定能提高政治觉悟一样。QA人员如果没有实际参与过项目/产品的开发，没有从事过项目管理工作，或是从有些部门抽调来的工作相对比较“轻松”的人员，即便他们熟读背诵了整个过程体系，仍然很难成为企业真正需要的合格的QA。
企业由于成熟度和企业文化的不同，对QA的期望也很不同。比如一个沟通协作差、部门墙林立的企业，QA的软能力，尤其是团队精神和沟通协调能力可能是最重要的要求；对于一个高过程成熟度的企业，对QA的要求则不仅仅是对过程体系的熟知，而要求QA同时具备深入的业务领域知识，并且是一位度量分析的专家。
2.EPG和QA人员的7种素质
EPG，即工程过程组，是过程改进的主体，QA是过程改进实施的重要推动力量，他们应该具备以下7种基本的素质：
1.真正相信过程改进-只有发自内心的相信才能感染别人。
2.自我激励-即便身处逆境，也可以克服不良情绪振作起来。
3.不畏惧失败-我们的任何工作在第一次做时不可能完美。
4.引导和激励其他人-只有几个人的改变不代表整个组织的成功。
5.分清工作轻重缓急层次清晰-平衡工作的长期目标和短期利益。
6.不断充电-不断学习、思考、实践、再学习。
7.开心地工作。
六、总结
企业在建立QA组织时，应根据自身的需要，考虑到企业文化、成熟度等级，以及可获得的资源等因素，因地制宜。“抓壮丁”式地选择QA人员，绝无利于企业的质量体系发挥作用。只有选择了合适的QA组织形式，QA人员具备相应的能力和素质，才能保证质量管理体系良好地运作，从而现产品零缺陷、工作零错误的最终目标。
CMM类体系下的QA价值所在
QA到底是什么？它是做什么的？能带来什么好处？相信接触过CMM的人对其中这个核心角色应该不感到陌生，可能也或多或少地知道它的一些工作内容。尽管如此，很多人对这个角色的价值以及必要性可能还并不真正地理解，这里作者结合多年的质量管理经验总结了QA的十大价值所在，希望能帮助大家更进一步地了解QA。
1、保障制度体系
无论是CMM/CMMI还是ISO9000等其他管理思想，它都是强调法治而非人治，实施CMM也是希望能通过它将一些优秀的软件工程化开发经验用一套合理、规范的制度沉淀固化下来，使项目的成功不再成为一种偶然。这其中体现了一个三权分立的思想：SEPG（软件工程过程组）相当于是立法机构，负责建立、维护、改进企业的开发过程体系；SEG（软件工程组）则是执行机构，来执行这套开发过程，按照软件工程化的思想来实施项目；而QA则是督促这些规范贯彻实施的监督机构了。
作为一个国家，监督机构的必要性和重要性不必多说。同样，作为一个企业，监督机构也是非常必要的。试想一下，如果企业花了大量的人力物力建立了一套规范的开发制度，每个项目启动时也制定了各种周密的计划，却缺少相应的机构来进行督促，那么项目在实施过程中是很容易由于这样或那样的原因而偏离既定轨道的，导致项目难于得到有效地控制。而企业的制度、项目的计划也就变得形同虚设。企业的制度实际上就相当于企业的法律，如果有法不依，执法不严，违法不究，久而久之这套制度就只是一纸空文了，浪费了大量的人力物力来建立却毫无用处。所以就非常需要存在QA这么一个机构来维护企业开发制度的权威性，并督促项目计划得到有效地实施。
2、促使过程改进
SEPG建立了一套规范过程后，并不表示这个过程就一成不变了，规范自身也必须不断地得到改进才能保证它的正确性和有效性。虽然过程规范在发布之前都必须经过评审，但并不表示只要通过评审就能发现所有的问题，还必须经过实践的检验才行。正所谓没有最好只有更好，所以过程的改进也是永无止境的。它的改变往往是来自两个方面，一方面可能是这个过程本身存在的缺陷和错误暴露出来了，促使SEPG必须去完善性的改进；另一方面可能是当时过程制定所依赖的情况发生了变化，现有的过程已不适应当前项目实施的需要，甚至还阻碍了项目的发展，这也会促使SEPG去进行适应性的改进。
但是改进的来源从哪来呢？表面上好像项目组可以向SEPG提出，SEPG自己也可以去发现。但是实际情况往往是一方面项目组成员尤其是成熟度等级较低企业的项目组成员缺乏质量意识，只关注与自身相关的开发工作，对过程改进工作缺乏应有的认识，提不出问题或者有问题也不愿提出来。而另一方面SEPG却又往往苦于不了解项目情况而找不到关键问题所在。
而QA的存在恰好就可以解决这一矛盾，因为QA经常要参与过程改进工作，又常常参与项目的活动，既熟悉过程体系又熟悉项目情况，刚好起到充当SEPG和项目组之间桥梁的作用。QA在项目实施过程中经常会发现很多问题，有些问题有些是因为项目组本身执行得不够规范而产生的，而另一些问题则是由于过程本身存在着一些缺陷引起的，如可操作性不强或前后矛盾等而让项目组无法实施。所以QA在工作当中，会将这些问题记录下来并反映给SEPG，以促使过程改进。另外项目实施过程中值得借鉴的一些经验做法QA也反映给SEPG，以便SEPG在企业范围内进行推广。如果过程完善了，反过来也会更好促进项目工作的开展，这就是一个良性循环。
3、指导项目实施
QA对项目有督促的作用，但是仅仅督促是不够的，还需要给予项目组在过程实施上的指导。虽然在项目过程实施之前会要接受相应的培训，但是工作的顺利开展并不是光靠几堂理论课就能解决问题的，很多具体的做法需要在实践中才能真正理解应用，而且每个项目组成员接受培训的程度不同，对过程的理解可能存在一些偏差。因此还需要QA人员在项目实施过程中给以解答和指导，将这些规范真正地贯彻下去。
QA对于项目组来说就象一把双刃剑，既有监督的一面也有指导的一面。既能帮助项目顺利的开展工作，也能使不规范不合格的项目暂停甚至关闭。这其中项目经理的指导思想非常重要，如果项目经理是抱着积极合作的态度，决心要真正按企业规范化过程来实施项目的话，那么QA将成为最有力的帮手和支持者。如果项目经理抱着消极对抗的态度，置企业管理制度不顾，欺上瞒下自行一套的话，则QA就是他们最大的障碍和绊脚石。
4、增加透明度
软件开发活动存在于人的大脑中，不象工业生产中在流水线上的工作情况令人一目了然。正是因为这一特点使得软件项目难于控制。而QA的存在则可以提高这种透明度、增加项目的可视性。让高级经理和相关工作人员能从项目组以外的第三方得到一个独立的视角和渠道，能从多方面客观地了解项目的过程、产品、服务等情况，以便做出正确的判断，及时发现问题及时进行纠正，使项目尽可能朝着良性的方向发展。
5、评审项目活动
评审项目活动是QA的核心工作之一，也是QA实施质量保证的一个重要手段，评审项目活动的目的是为了检查项目的活动是否符合企业制定的规范和项目既定的计划，及早发现可能存在的问题，并通报给相关人员以便及时纠正。
虽然质量保证的最终目的是希望能保证质量，但质量是过程、人、技术三者的函数，除了过程外，还与人员、技术有关，而人员素质和技术水平的提高并不是依赖QA就能保证的，所以QA虽名为质量保证，实际上它直接保证的是决定质量好坏的一个重要因素——过程。
过程不仅仅指活动，它还包括了产品，产品是一系列活动后的产物，所以保证过程要先从活动开始入手，因为控制得越早，发现问题越早，所付出的代价就越小，当产品出来之后再去控制就已经晚了。虽然单有好的过程不一定就会有产生好的质量，它还必须依赖人员和技术这两大因素，但是一个不好的过程肯定难产生好的质量，因为过程、人员、技术这个质量铁三角缺一不可。所以QA需要评审项目的活动，从保证活动入手来保证过程进而保证最终的质量。QA评审项目活动时应该做到独立、客观、公正，评审的时机和频率可按预定的检查点进行抽查。需要指出的一点是QA评审项目活动和同行评审不同，同行评审是指同行评审人员从技术角度对产品进行评审，而QA评审项目活动则是从规范角度对活动进行评审，这两者有本质的区别。
6、审核工作产品
评审完项目的活动，那么QA接下来就需要审核活动的产物——产品了，审核工作产品是QA的另一个核心工作。项目组在开发过程中会产生大量的工作产品，如需求、设计、代码、用户文档等。同行评审、测试等手段可以从技术角度对产品质量进行把关。而过程方面的质量，如符合性、规范性、一致性等则需要由QA来把关，产品的技术性与规范性不可或缺。
最终的产品质量是由单个的软件工作产品质量组成的，所以QA也必须从审核单个的软件工作产品开始来保证最终的产品质量。审核产品也应该做到独立、客观、公正，它的重点在于产品规范性、符合性、一致性、完整性、可追溯性等方面。对于同一工作产品，如果QA代表参加该产品的同行评审工作，则可以视情况不对该产品进行独立QA审核，以免重复工作。
7、协助问题解决
QA无论是评审项目活动还是审核工作产品，都是为了发现问题并及早解决。QA发现问题后会将问题记录在报告中并提交给项目经理确认。然后还会协助项目经理一起找出问题的原因。如果在项目一级问题能得到妥善解决则应尽量在项目内解决，如果项目组一级不能解决，则QA会上报给高级经理以寻求更高一级的支持。QA问题的上报并不能看成是在向高级经理打小报告。其出发点也是为了更好地协助项目解决问题，有问题要及时发现，发现了问题就要及时解决，越早越好，否则小问题发展成大问题很可能就会给项目和企业带来无可挽回的损失。
QA应客观地报告问题，报告用语应做到客观、公正、规范、严谨、准确、清楚。并且跟踪这些问题直到它们被妥当地解决为止。
8、提供决策参考
在那些没有专职度量分析人员的软件企业中，QA还承担了数据采集、统计、分析的工作。在项目一级，QA采集项目相关的数据并对其进行统计和分析。从分析的结果项目经理可以看出现阶段哪些方面做得还不够，哪些方面还存在着问题，哪些方面还需要改进，并为项目下一步的工作重点提供决策参考。在组织层面，QA也会收集组织的过程数据，并将统计分析的结果反馈到高层领导，用数据说话，用事实说话，为高层的决策提供有力的参考和依据。
9、进行缺陷预防 从长远来看，企业要降低成本、提高质量就必须要进行缺陷预防。消除产生缺陷和问题的根本原因并且防止将来这类缺陷和问题的再次发生，以优化项目及企业的规范过程。缺陷预防并不是简单对缺陷进行发现和纠正。等到缺陷被发现时，实际上缺陷已经发生过了，对节省项目成本和控制进度来说作用并不是显得特别大，缺陷预防重在预防，防范于未然才真正有效。通常的做法是要求在开发周期的每个阶段实施缺陷预防和原因分析，吸取其他项目或本项目前期的一些经验教训，并使原因分析和缺陷预防成为一种机制。
在项目过程实施当中，QA会指导并协助项目组积极地开展缺陷预防活动，采集问题和缺陷相关数据，并对缺陷和问题的类型进行分析，了解问题的趋势，确定这些缺陷的根源和将带来的影响，并通过共同决策分析，得出所需要采取的措施并具体去实施。
10、实现质量目标
经过了一系列质量相关的活动后，最根本目的还是要通过这些活动来达到项目乃至组织的预期质量目标。只有达到目标了，一切的努力才没有白费，工作才显现了应有的价值。
项目启动时，QA会和项目经理一起结合企业的过程能力基线来制定项目的质量目标。在项目实施过程中，QA会指导项目按阶段、里程碑等控制点对质量目标进行定量控制，定期将项目运行情况和质量目标进行比较，及时发现偏差，及时进行调整，以保证项目最终能达到质量目标。如果项目的质量目标都达到了，那么企业的质量目标也就容易实现了，并提升了整个企业的能力基线。
经过总结，大家可能已经认识到QA在企业中是一个不可缺少的角色了。但是从理论上来说，当企业的成熟度发展到很高等级，人人都具有很强的质量意识，人人都能自觉提维护质量体系，人人都充当起QA角色的时候，也许就不需要专职的QA了。正如国家机器的功能会随着社会文明的高速发展变得弱化甚至是消亡的道理一样。但是，就目前来说这还仅仅只是一种理想的状态，正如国家机器在若干年之后都不会退出历史的舞台一样，作为企业机器的QA在相当长的时间内也应该还会继续存在。而且随着我国软件业工程化思想的普及，软件企业对QA的需求也会相应地增大，QA这一新兴岗位也将越来越有发展前途。
一、前言
本人在企业从事SQA工作，同时兼任SEPG的工作进行基于CMM3的过程改进，在实践过程中，对SQA的工作有了较多的想法和认识。本文是个人看法，请大家指教，如果要和本人联系，请发Email到：heqingemail@163.net。
二、SQA的理论探索
2.1、过程的 认识
我们都知道一个项目的主要内容是：成本、进度、质量；良好的项目管理就是综合三方面的因素，平衡三方面的目标，最终依照目标完成任务。项目的这三个方面是相互制约和影响的，有时对这三方面的平衡策略甚至成为一个企业级的要求，决定了企业的行为，我们知道 IBM的软件是以质量为最重要目标的，而微软的“足够好的软件”策略更是耳熟能详，这些质量目标其实立足于企业的战略目标。所以用于进行质量保证的SQA工作也应当立足于企业的战略目标，从这个角度思考SQA，形成对SQA的理论认识。
软件界已经达成共识的：影响软件项目进度、成本、质量的因素主要是 “人、过程、技术”。首先要明确的是这三个因素中，人是第一位的。
现在许多实施 CMM的人员沉溺于CMM的理论过于强调“过程”，这是很危险的倾向。这个思想倾向在国外受到了猛烈抨击，从某种意义上各种敏捷过程方法的提出就是对强调过程的一种反思。“XP”中的一个思想“人比过程更重要” 是值得我们思考的。我个人的意见在进行过程改进中坚持“以人为本”，强调过程和人的和谐。
根据现代软件工程对众多失败项目的调查，发现管理是项目失败的主要原因。这个事实的重要性在于说明了 “要保证项目不失败，我们应当更加关注管理”，注意这个事实没有说明另外一个问题“良好的管理可以保证项目的成功”。现在很多人基于一种粗糙的逻辑，从一个事实反推到的这个结论，在逻辑上是错误的，这种错误形成了更加错误的做法，这点在SQA的理解上是体现较深。如果我们考证一下历史的沿革，应当更加容易理解 CMM的本质。CMM首先是作为一个“评估标准”出现的，主要评估的是美国国防部供应商保证质量的能力。CMM关注的软件生产有如下特点：
（1）质量重要（2）规模较大
这是 CMM产生的原因。它引入了“全面质量管理”的思想，尤其侧重了“全面质量管理”中的“过程方法”，并且引入了“统计过程控制”的方法。可以说这两个思想是CMM背后的基础。
上面这些内容形成了我对软件过程地位、价值的基本理解；在这个基础上我们可以引申讨论 SQA。
2.2、生产线的隐喻
如果将一个软件生产类比于一个工厂的生产。那么生产线就是过程，产品按照生产线的规定过程进行生产。SQA的职责就是保证过程的执行，也就是保证生产线的正常执行。
抽象出管理体系模型的如下，这个模型说明了一个过程体系至少应当包含 “决策、执行、反馈”三个重要方面。
QA的职责就是确保过程的有效执行，监督项目按照过程进行项目活动；它不负责监管产品的质量，不负责向管理层提供项目的情况，不负责代表管理层进行管理，只是代表管理层来保证过程的执行。
2.3、SQA和其他工作的组合
在很多企业中，将 SQA的工作和QC、SEPG、组织级的项目管理者的工作混合在一起了，有时甚至更加注重其他方面的工作而没有做好SQA的本职工作。
根据 hjhza 的意见“中国现在基本有三种QA（按照工作重点不同来分）：一是过程改进型，一是配置管理型，一是测试型”。我个人认为是因为SQA工作和其他不同工作组合在一起形成的。
下面根据本人经验对它们之间的关系进行一个说明。
2.4、QA和QC 两者基本职责
QC：检验产品的质量，保证产品符合客户的需求；是产品质量检查者；
QA：审计过程的质量，保证过程被正确执行；是过程质量审计者；
注意区别检查和审计的不同
检查：就是我们常说的找茬，是挑毛病的；
审计：来确认项目按照要求进行的证据；仔细看看CMM中各个KPA中SQA的检查采用的术语大量用到了“证实”，审计的内容主要是过程的；对照CMM看一下项目经理和高级管理者的审查内容，他们更加关注具体内容。
对照上面的管理体系模型，QC进行质量控制，向管理层反馈质量信息；QA则确保QC按照过程进行质量控制活动，按照过程将检查结果向管理层汇报。这就是QA和QC工作的关系。
在这样的分工原则下，QA只要检查项目按照过程进行了某项活动没有，产出了某个产品没有；而QC来检查产品是否符合质量要求。
如果企业原来具有 QC人员并且QA人员配备不足，可以先确定由QC兼任QA工作。但是只能是暂时的，独立的QA人员应当具备，因为QC工作也是要遵循过程要求的，也是要被审计过程的，这种混合情况，难以保证QC工作的过程质量。
2.5、QA和SEPG 两者基本职责
SEPG：制定过程，实施过程改进；
QA： 确保过程被正确执行 SEPG应当提供过程上的指导，帮助项目组制定项目过程，帮助项目组进行策划；从而帮助项目组有效的工作，有效的执行过程。如果项目和QA对过程的理解发生争持，SEPG作为最终仲裁者。为了进行有效过程改进，SEPG必须分析项目的数据。
QA本也要进行过程规范，那么所有QA中最有经验、最有能力的QA可以参加SEPG，但是要注意这两者的区别。
如果企业的 SEPG人员具有较为深厚的开发背景，可以兼任SQA工作，这样利于过程的不断改进；但是由于立法、执法集于一身也容易造成SQA过于强势，影响项目的独立性。
管理过程比较成熟的企业，因为企业的文化和管理机制已经健全，SQA职责范围的工作较少，往往只是针对具体项目制定明确重点的SQA计划，这样SQA的审计工作会大大减少，从而可以同时审计较多项目。
另一方面，由于分工的细致化，管理体系的复杂化，往往需要专职的 SEPG人员，这些人员要求了解企业的所有管理过程和运作情况，在这个基础上才能统筹全局的进行过程改进，这时了解全局的SQA人员就是专职SEPG的主要人选；这些SQA人员将逐渐的转化为SEPG人员，并且更加了解管理知识，而SQA工作渐渐成为他们的兼职工作。
这种情况在许多 CMM5企业比较多见，往往有时看不见SQA人员在项目组出现或者很少出现，这种SEPG和SQA的融合特别有利于组织的过程改进工作。SEPG确定过程改进内容，SQA计划重点反映这些改进内容，从保证有效的改进，特别有利于达到CMM5的要求。从这个角度，国外的SQA人员为什么高薪就不难理解了，也决定了当前中国SQA人员比较被轻视的原因；因为管理过程还不完善，我们的SQA人员还没有产生这么大的价值嘛！
2.6、QA和组织级的监督管理
有的企业为了更好的监督管理项目，建立了一个角色，我取名为 “组织级的监督管理者”，他们的职责是对所有项目进行统一的跟踪、监督、适当的管理，来保证管理层对所有项目的可视性、可管理性。为了有效管理项目，“组织级的监督管理者”必须分析项目的数据。
他们的职责对照上图的模型，就是执行 “反馈”职能。
QA本身不进行反馈工作，最多对过程执行情况的信息进行反馈。
SQA职责最好不要和“组织级的项目管理者”的职责混合在一起，否则容易出现SAQ困境：一方面SQA不能准确定位自己的工作，另一方面过程执行者对SQA人员抱有较大戒心。
如果建立了较好的管理过程，那么就会增强项目的可视性，从而保证企业对所有项目的较好管理；而 QA来确保这个管理过程的运行。
三、SQA的工作内容和工作方法
3.1、计划
针对具体项目制定 SQA计划，确保项目组正确执行过程。制定SQA计划应当注意如下几点：
有重点：依据企业目标以及项目情况确定审计的重点
明确审计内容：明确审计哪些活动，那些产品
明确审计方式：确定怎样进行审计
明确审计结果报告的规则：审计的结果报告给谁
3.2、审计/证实
依据 SQA计划进行SQA审计工作，按照规则发布审计结果报告。
注意审计一定要有项目组人员陪同，不能搞突然袭击。双方要开诚布公，坦诚相对。审计的内容：是否按照过程要求执行了相应活动，是否按照过程要求产生了相应产品。
3.3、问题跟踪
对审计中发现的问题，要求项目组改进，并跟进直到解决。
四、SQA的素质
过程为中心：应当站在过程的角度来考虑问题，只要保证了过程，QA就尽到了责任。
服务精神：为项目组服务，帮助项目组确保正确执行过程
了解过程：深刻了解企业的工程，并具有一定的过程管理理论知识
了解开发：对开发工作的基本情况了解，能够理解项目的活动
沟通技巧：善于沟通，能够营造良好的气氛，避免审计活动成为一种找茬活动。
QA活动的理解与实施
摘要：QA活动是CMMI实施中较难贯彻的过程。本文针对目前国内的QA过程实施情况，从QA的地位、原则、活动、实施等方面进行了阐述。同时讨论了QA与QC、测试之间的关系，以及实施QA活动的最佳实践，为组织实施过程改进提供了基础。概述
在使用CMMI模型实施过程改进时，需建立QA（Quality Assurance）的组织职能和角色，并实施“过程和产品质量保证”活动。这些活动目的在于使项目工作人员和所有各层管理者能适当地了解整个项目生存周期中工作产品和过程的情况，从而支持交付高质量的产品和服务。
由于CMMI模型是建立在西方的企业文化背景下，包含有三权分立的思想，所以对于国内IT及软件企业而言，如何理解和建立QA机制，更好地利用CMMI模型进行过程改进就显得非常重要。但是，目前国内IT及软件企业对于QA的意义和认识存在误区，导致在实施过程改进活动中，QA活动流于形式或没有发挥出其真正作用。到底QA在组织中应扮演什么样的角色，CMMI的QA的与ISO9000的QA或QC（Quality Control）概念有何区别，QA与测试是什么关系，如何实施QA活动，等等，本文针对这些进行阐述，以解决企业CMMI实施过程中的薄弱环节。QA的地位及活动
2.1 QA的地位 图1显示了在CMMI实施过程中QA所处的地位。
图1 QA的组织结构
QA活动的目标是以独立审查方式，从第三方的角度监控软件开发任务的执行，就项目是否正遵循已制定的计划、标准和规程给开发人员和管理层提供反映产品和过程质量的信息和数据，提高项目透明度，同时辅助软件工程组交付高质量的软件产品。所以对过程和产品质量保证的客观评价是项目成功的关键，一般是通过独立于项目的QA小组来提供这种客观性。每个从事QA活动的人都要进行质量保证方面的培训。从事某个产品的QA活动的那些人不应该是直接介入该工作产品开发或维护的人。同时，应该有一条向适当的管理层独立报告问题的渠道，以便在必要时逐级上报不符合问题。
不过，在某些组织里，不要求这种独立性而实现过程和产品质量保证角色可能更合适。例如，在一个具有开放的、面向质量的文化环境的组织里，可以由同行担任（部分或全部）过程和产品质量保证角色，可以把质量保证功能镶嵌在过程中。
QA应具备以下职责：
通过监控开发过程来保证工作产品质量
保证开发出来的产品和开发过程符合相应标准与规程；
保证产品、过程中存在的不符合问题得到处理，必要时将问题反映给高级管理者 确保项目组制定的计划、标准和规程适合项目组需要，同时满足评审需要 向开发人员提供反馈
2.2 QA的活动
QA的工作内容为：
1)客观评价过程和工作产品：对于所实施的过程和相关工作产品以及服务对适用的过程描述、标准和规程的遵循情况进行客观评价。
2)提供客观情况：客观地跟踪和通报不符合问题，并且确保解决它们。
因此，QA的活动步骤如图2所示。
图2 QA的活动步骤
由上可知，QA涉及以下活动：
对照适用的过程描述、标准和规程客观地评价所执行的过程、工作产品和服务； 识别不符合问题，并形成文件：
向项目工作人员和管理者反馈质量保证活动情况； 确保不符合问题得到处理。QA与QC、测试之间的关系
3.1 QA和QC QA和QC区别在于：
QC：检验产品的质量，保证产品符合客户的需求；是产品质量检查者；
QA：评审过程和产品的质量，特别要保证过程被正确执行，通过保证过程质量来保证产品质量。
由上面的区别可知，QC进行质量控制，向管理层反馈质量信息；QA则确保QC和过程实施者按照过程进行质量控制活动，按照过程将检查结果向管理层汇报。软件开发过程和的QC工作通常就是对软件工作产品的技术评审（如同行评审等）。
在这样的原则下，简单而言QA只要检查项目按照过程进行了某项活动没有，产出了某个产品没有；而QC来检查产品是否符合质量要求。
3.2 QA与测试 下图显示了一个企业的开发过程、支持过程的关系。
从现代软件工程的观点来看，测试应是软件生命周期过程的一个不可缺少的阶段，是确保规定的需求得以满足，上图的流程模型体现了这一点。而QA活动则是贯穿于整个软件生命周期过程及其支持过程，包括培训、采购等活动，以确保所策划的过程得以实施。QA活动和测试过程可能同时关注同一个产品，但是关注的角度不同。
应该在项目的早期阶段开始QA过程，以便确定有益于项目的计划、过程、标准和规程并且满足项目需求和组织方针。从事质量保证的人要参加计划、过程、标准和规程的确定，以确保它们适合于项目的需要和适合于进行质量保证评价。实施QA活动的方法
4.1 QA的工作流程 图4描述了QA的一般工作流程。
图4 QA的工作流程
应指定在生存周期中将进行评价的特定过程和产品。可以根据抽样方式或客观准则进行指定；这些准则要与组织的方针和项目需求以及需要一致。
识别出不符合问题后，首先是在项目内部处理，如果可能，就地加以解决。任何不能在项目组内部解决的不符合问题，要逐级上报适当的管理者予以解决。
在过程中，QA一般比较注重的是过程是否符合规范？测试是否合理、充分？评审是否及时、有效等，这些是重要的“检验”过程，可以列为重点。过程是否符合规范，一般要看过程有没有计划，计划详细与否，可行与否，工作量评估是否可行（主要是检查评估方法）？日常管理是否可行？配置管理是否可行？过程遵循那些标准？实施什么样的裁减，等等。
在整个QA过程的评审活动中，QA需要具备一定的数据意识，要不断的收集各种数据，尤其是质量数据。最好具备一定的项目管理经验，要不然，只能是一种边缘参与，是进入不了项目的。QA最好能帮助PM将问题分析清楚。PM会思考要将问题做成什么样子，而QA可以思考如何去做，这样就可以达到一种配合的效果。
其次还要注意一点，就是QA以什么心态去监控项目组，我们公司提出的是“质量服务”，也就是说，项目组是我们的客户，我们是为他们提供质量服务的。
4.2 最佳实践
实施QA活动的最佳实践应该根据不同的企业情况而不同，但以下几条是实施过程改进活动中总结出来的，具有一般意义。
1)QA人员要求
服务精神：QA应定位为教练、服务的角色，而不是警察的角色。了解过程：熟悉过程规范。
了解开发：如果QA有过开发经验，则可更好地实施评审活动。沟通技巧：通过好的沟通技巧发现问题，解决问题。专门培训：QA人员最好经过专门的培训，以提高评审技巧。
2)制定QA计划
计划中可能包含以下内容：
质量目标（与度量的数据相关联）人员安排 时间
检查工具（检查表）检查对象（活动和产品）检查点及频次
3)编制检查表
检查表是QA人员进行评审活动的工具。编制检查表时应考虑以下问题： 何时需要检查表 检查表包括什么内容 如何使用检查表 如何调整检查表
4)形成QA报告
QA应对检查的结果形成报告，以便跟踪、解决、关闭所发现的问题。形成QA报告时应考虑：
报告目的 报告内容 问题沟通 问题跟踪 问题上报
5)几个参见问题
QA价值开始不被项目组认可
一个全职的QA可以同时兼任多少个项目的QA工作 QA与项目组的关系难处理
项目组有了QA，可是需求文档和设计文档的质量还是不高 结束语
总之，QA活动对于过程改进具有重要的意义，这是由人治到法治的一个必经阶段。所以，只要国内IT及软件企业能够认真贯彻CMMI模型规范的要求，持之以恒，随时解决实施中发现的问题，就会体会到QA活动的巨大效益。
第四篇：软件测试工作中 QA 的角色和分工
1、测试的角色(Test)要独立出来么 ?
2、独立出来的测试角色怎么才能发挥作用?
有些成功人士和成功的公司号称没必要有独立的测试角色(Test)，你怎么看?
大多数的开发团队并不需要一个独立的测试角色。即使有一个，他的所有的开发时间比上所有的测试时间应该>20：1。
我正好在写相关的教案，也来凑个热闹。
[这篇文章的一些事例来自于我曾经和现在的团队。希望这些例子不足以影响相关人物和团队的伟大形象。任何软件团队都会犯错误，伟大的团队有勇气面对自己的错误并不断改进。]
首先，明确两个概念：
1、软件测试(Test)：运用定义好的流程，工具去验证软件能实现预先设计的功能和特性，工作的流程和结果通常是可量化的，例如，测试用例，bugs，代码覆盖率，MTTF，软件效能的参数。[注：正因为流程和结果是可明确定义的，可量化的，很多测试工作可以自动化]
2、软件质量保证工作(QualityAssurance)：软件团队的成员为了让软件达到事先定义的质量而进行的所有活动，包括测试工作。
对于这两个术语，不同人有不同的定义，有人认为它们是互通的，在《现代软件工程》的上下文中我尽量使用上述的定义.测试的角色(Test)要独立出来么?
回答：首先，领测国际相信有分工是好事，软件团队中应该有独立的测试(Testing)角色。所有人都可以参与QA的工作(报告bug什么的)，但是最后要有 一个角色对QA这件事负责。不但角色要独立，而且在最后软件发布的时候，必须得到此角色的签字保证(signoff)。我在微软参与的项目都是这样做的。
在开始论证之前，先引用斯密特·亚当斯的《国富论》来暖场(我没读过这本书，直接从网上抄的)。
亚当斯认为，分工的起源是由人的才能具有自然差异。…假定个人乐于专业化及提高生产力，经由剩余产品之交换行为，促使个人增加财富，此等过程将扩大社会 生产，促进社会繁荣，并达私利与公益之调和。他列举制针业来说明。“如果他们各自独立工作，不专习一种特殊业务，那么他们不论是谁，绝对不能一日制造二十 枚针，说不定一天连一枚也制造不出来。他们不但不能制出今日由适当分工合作而制成的数量的二百四十分之一，就连这数量的四千八百分之一，恐怕也制造不出 来。”
分工促进劳动生产力的原因有三：第一，劳动者的技巧因专业而日进;第二，由一种工作转到另一种工作，通常需损失不少时间，有了分工，就可以免除这种损失;第三，许多简化劳动和缩减劳动的机械发明，只有在分工的基础上方才可能。
我们看团队形式的职业体育比赛，各个位置的分工都很明确，拿足球来说，有专注进攻的，有专注防守的，但是在我的印象中，那些伟大的前锋大多数只管一件事-进攻。亨利(ThierryHenry)参加防守么?
1、当然一些球赛也有没有分工的时候，原因有好几个：
2、事太小，几个小孩踢个半场。
3、无知，小孩们刚开始玩球。
4、人手不够，一对一打篮球，你要参与防守么?沙滩排球，两人都是全攻全守。
如果你的软件团队做的事情和上面的情况类似，那当然不必分工。你们做的很可能不是商用软件，你的软件团队大概也不用受什么软件工程规律的束缚。
任何产业产业成熟到一定阶段的时候，独立的质量保证角色是不可避免的。团队内部有QA角色，团队外部也有独立的QA角色。
拿药品和食品来做例子，除了生产厂家自己的检测之外，这些产品还要接受行业主管部门相关机构的检测和认可(药品检验，食品检验)，才能上市。在出现争议的情况下，还要第三方机构来进行测试或认证。
有人也许这样建议：
这些药品都是药厂同一批工人一边制造一边测试出来的，特别有保证!不用测了，赶紧吃了吧!
也许还有人这样建议：
这个十字坡夫妻店的农家饭都是他们自己亲手做的，很可信，咱们今晚就去吃饭住一宿吧。
我们每天经常使用的电子产品，从大彩电到电影插座，也经历了很多团队内部的和外部的测试，请随手拿过任何一个电器，你会在背面看到密密麻麻的小字，其中肯定有下列标记之一：
没有这些标记的产品电子产品，市面上很少看到。
第五篇：软件实施岗位职责
软件项目实施岗位职责
目录
软件项目实施岗位职责...........................................................................................................1一、二、三、项目实施职责............................................................................................................2 岗位设置....................................................................................................................2 岗位职责说明............................................................................................................3
（一）项目经理...................................................................................................................3
（二）项目实施工程师.......................................................................................................4
（三）售前技术支持...........................................................................................................4
（四）售后技术支持...........................................................................................................5
一、项目实施职责
1、负责公司软件项目的现场实施工作和制定项目实施计划书
2、负责承担项目实施交付和项目管理职责
3、负责项目实施过程中，与客户各相关科室进行工作沟通与协调、遇到软件问题的记录与解决、用户提出意见与建议的记录、软件的培训工作
4、负责编写公司软件的安装手册、使用手册及相关帮助文档
5、负责软件售后问题处理工作，软件问题记录、分类、总结工作
6、负责各省常驻人员培训工作
7、协助研发部做好软件的相关测试工作
8、协助商务部做好售前需求调查工作
9、协助综合部做好新进人员的业务培训工作
二、岗位设置
实施服务是直接面向广大客户群，现场的为客户进行软件系统的实施、培训和售后服务的工作，在维护公司和客户关系上有着重要的作用。
具体工作包括软件实施、软件培训、售后服务和协助本公司内其他部门的相关工作。
三、岗位职责说明
（一）项目经理 职务名称：项目经理
直接上级：实施服务总经理
直接下级：项目实施工程师、售前技术支持、售后服务支持
本职工作：负责项目的整体沟通与协调工作 岗位职责：
1、承担项目交付和项目管理职责；
2、负责组织召开项目调研会，分析项目可行性。
3、负责组织实施人员的准备工作，制定项目实施计划于实施进度；
4、负责项目进度的整体把握。
5、负责项目的业务技术沟通及问题处理。
6、负责项目实施过程中与客户各科室之间的协调工作，了解客户项目负责人及其他相关人员的时间安排。
7、承担项目实施过程中，公司现场人员的协调与管理工作。
8、负责项目的验收与交接工作。
9、负责向实施服务部总经理反馈遇到的问题及工程进度工作。
10、协同商务部与客户进行项目洽谈
11、项目开始与合同签订。协同商务部进行合同最终签订工作，并做好客户关系建立与维护；
12、对项目实施和验收以及售后服务工作进行严格管理和控制，及时解决问题。
13、完成公司领导交办的其他工作。
（二）项目实施工程师 职务名称：项目实施工程师
直接上级：项目经理
本职工作：负责项目具体实施工作与问题记录工作 岗位职责：
1、参与项目实施计划书的编写；
2、完成项目实施的具体工作，掌握本公司软件实施的技术，可以独立完成软件实施工作；
3、及时记录并解决用户在软件使用过程中遇到的问题，其处理结果上报项目经理
4、记录用户在软件使用过程中对存在问题的建议与意见，并上报项目经理
5、协助售后服务人员编写《操作手册》和相关培训教材
6、负责用户的培训工作
7、负责实施服务部其他相关文件的编写工作
8、学习掌握财政和银行业务知识
9、完成公司领导交办的其他工作。
（三）售前技术支持 职务名称：售前技术支持 直接上级：项目经理
本职工作：负责项目前期需求调查，向客户讲解公司产品和技术方案。岗位职责：
1、负责项目前期需求调查工作，编写需求调查文档；
2、协同项目经理开展项目调研工作，分析项目可行性；
3、根据客户提供的需求，编写完整的解决方案，并进行方案演示和需求沟通；
4、负责对客户提出的技术问题进行解答，根据产品的特点和竞争产品的优缺点比较，将客户引导到解决方案中；
5、负责与研发部门进行沟通，为客户与研发部架起沟通桥梁；
6、掌握项目招投标的程序，协同商务部进行招投标、标书的编写和讲标等工作；
7、完成公司领导交办的其他工作。
（四）售后技术支持 职务名称：售后技术支持
直接上级：项目经理
本职工作：负责项目售后服务，解决软件使用中产生的问题，现场派驻人员须根据客户签署的维保合同中的内容，完成相关工作。岗位职责：
1、负责日常电话接听和网络在线解答，并将问题进行整理，编册印刷或登记在公司网站；
2、公司网站日常维护；
3、客户技术支持：通过电话、邮件等渠道，接受客户产品技术方面的咨询，解决常见问题、介绍相关知识，并收集整理客户的反馈信息，做好客户关系管理；如果客户反映的问题是软件BUG，及时向研发部门反映情况，提交BUG处理单，跟踪问题处理进度，及时向客户反馈结果并定期回访；
4、客户培训：根据培训需求，编制培训教材、使用手册等，并协调研发、商务等相关部门的资源，做好客户培训工作；
5、现场派驻人员须根据维保合同，完成本职工作，并了解派驻地的业务需求，协助商务部开拓新的市场；
6、现场派驻人员负责了解派驻地客户的工作计划及主管业务，协助商务部开展工作。
7、完成公司领导交办的其他工作。
点击咨询 