QA到底是干什么的？
“QA”——一个越来越多在软件企业中设立的岗位。但是一说起QA，很多人会问：“QA到底是干什么的？”。
QA（Quality Assurance）的中文含义是质量保证。
在ISO8402中对于QA的定义（1994）：“为了提供足够的信任表明实体能够满足品质要求，而在品质管理体系中实施并根据需要进行证实的全部有计划和有系统的活动”。
在CMMI中对于QA的定义是“有计划的和系统的管理方法，保证已定义的标准、实践、规程和过程方法得到应用”。
QA的基本职责是保证企业研发规范与实际操作实施的一致性，以及规范的有效性。通过监控软件的开发过程来保证产品的质量。保证软件产品、软件过程中存在的不符合问题得到处理，在项目组内不能解决的问题反映给高层经理决策解决。不包括开发软件产品和承担项目管理工作，这些是开发人员和项目经理的工作。
但是具体的工作内容和职责，不同的国度和不同的企业却有很大的不同。先看看国外的QA，很多企业的QA指的是测试人员；实施CMM/CMMI等标准化规范的企业，将QA定位在过程质量保证和体系改进。而国内企业的QA多数都有过程质量保证的职责，但也有不少的企业将测试与QA合二为一。
天融信对QA的定位
就像技术人员和管理人员一样，QA除了基本职责外，还有工作范围和深度的不同之分。以天融信为例，质量保证人员的岗位分为QA、资深QA、QA主管。
对于QA，除完成基本职责外，因为天天与项目组在一起，接触和掌握第一手信息，还会参与过程改进工作；
对于资深QA，在完成QA的工作外，由于具备多年丰富的项目管理和质量管理经验，要根据企业的商业和业务需求，负责质量体系的架构设计，承担主要规范文件的制定和改进工作；并能够指导其他QA和项目经理的工作；
对于QA主管，则要求在具备多年扎实的资深QA基本功以外，跟踪和熟悉企业产品业务，能够洞察不规范和责任定义不清的“管理灰色地带”，以“指导员”和“医生”的角度识别和标识出问题。这里的发现问题，不是比对流程，不是查看实际操作与流程的不符之处，而是要找出影响质量、左右进度、降低效率、削弱效果，进而损坏组织目标达成的不良现状来。这些现状可能包括流程问题、技术问题、工具问题、管理问题等。针对这些问题，在流程层面，在工程方法推行方面，在技术改进方面，在管理实施方面，在人员激励方面，给出解决方案或协调各方力量，组织专题会议，推动共同改进，即所谓借力行事。
QA给企业带来的变化
在实施CMMI之前，天融信没有QA这个岗位（当然也没有配置管理岗位）。项目经理都是研发出身，没有接受系统的项目管理培训，缺少有效的管理方法指导。由于缺少系统化、制度化的研发管理流程，缺少QA这样一个指导和监督机制，使得产品的计划交付时间很难准确预计，经常被推迟；项目管理、生产率等数据没有得到有效的记录和积累；个人的经验和技能不能有效地推广和转化为企业财富；成功项目的经验不能得到复用。
通过引入CMMI思想，其实不论CMM/CMMI还是ISO9000等其他管理思想，在这点上都是相通的，即强调法治而非人治。将行之有效的、优秀的管理和开发经验进行制度化，沉淀固化为制度，使项目的成功能够重复、不再成为一种与个人英雄相关的偶然行为。
在组织层面上，我们增设了QA岗位，在原有研发部门中增加了专职配置管理岗位，并组织公司研发总裁、骨干项目经理/测试经理、QA、配置管理员成立了EPG（工程过程组）。这体现了三权分立的思想：
EPG是立法机构，负责研发过程的制度化和改进；
EG（工程组，产品开发/测试人员组成）是执行和反馈机构，一方面遵循研发规范执行产品开发，一方面反馈执行中发现的问题和有效的经验；
QA既是监督机构，负责督促、指导研发规范贯彻实施；同时往往也是EPG的成员，参与研发过程的改进；
在项目层面上，当筹划一个项目团队时，首先要保证至少有以下三个人：项目经理、技术经理、QA。项目经理、技术经理、QA三个角色的职责分工不同。
项目经理负责项目筹划、组织资源和监控进度等管理性工作，不参与具体开发工作（但会参与需求、设计的讨论）；
技术经理承担需求分析、架构设计和技术指导，是项目组的技术核心人物；
QA独立于项目组之外，为项目组提供规范流程作为产品开发依据，指导和审核项目组是否按规范执行，要求敏锐地识别问题产生原因并将经验和纠正措施固化到流程中，实现过程改进，避免以后的项目重蹈覆辙。同时将自己在多个项目中积累的经验应用到其他项目组，帮助其他项目组避免重复其他项目组发生过的问题、促使项目成功完成；
这种机制保证了企业花大量的人力物力建立的规范开发制度，不会因缺少监督机构来进行督促，而导致项目在实施过程中由于这样或那样的原因而偏离既定轨道的，导致项目难于得到有效地控制，最终失败。企业的规范属于技术制度范畴，相当于法律，如果有法不依，执法不严，违法不究，那么法律就形同虚设、流于形式。所以非常有必要存在QA这么一个机构来维护企业开发制度的权威性，并督促项目有效地实施。
这一机制一直运行到现在，经过实际验证是非常有效的。例如，我们一个产品引入此机制后，新版本开发比原有版本生产率提高17%。并且按照规范做事，已经形成一种氛围，大家在做事之前，都会问一句：“这件事有没有规范，是怎么要求的？”
成为优秀QA的基本要素
QA的规范实施监督、指导工作，仅仅是基本工作。一个优秀的QA还会花更多的精力在过程改进的思考和实践上，这里的过程改进不是仅指根据CMMI等管理模型编写规范文件，而是通过实际参与项目活动，了解项目、产品问题，识别哪些环节是急待改进的，哪些问题可以通过完善流程避免以后出现。这里体现了两个层面的价值：
做该做的事：
不能理解用户的要求，你做出来的产品没有人会要。如同产品满足客户要求一样，如果不能标识出产品开发环节中真正存在的问题（这些问题往往是开发组最需要解决的），并将这些问题按照重要程度和紧迫程度排序，解决优先级最高的问题。开发组会说你订出的规范没有用。
不要埋怨开发人员认识不高，不懂规范的意义，不懂质量管理，不配合。QA经过了系统的质量管理培训，在看待质量的角度上自然比开发人员认识高。但光说大道理没有，解决了人家的问题，才是好QA。人家才明白：“哦，原来这就是过程改进，这就是规范化管理”，进而认识到规范管理的重要性和价值，并乐于参与其中。
做有价值的事：
以前经常看到有些QA每周发出报告，里面说：“项目按计划对分包商交付的产品包进行了评审，评审发现的问题已经解决，符合规范要求”。这样说不是不对，QA的基本职责的确是审核规范的一致性，但是要做一个优秀的QA还远远不够。
评审发现了问题，项目经理通过与分包商沟通解决了。但是，这属于对问题的纠正。那么，以后或别的项目是不是还会出现这类问题呢？这就是优秀QA发挥作用的地方，通过分析，发现原来是在签订分包合同时，规格不够详细，导致接收到的产品包部分指标不符合要求，因此我们应该做两件事：
组织项目经理和有关部门人员讨论，识别问题、与分包商协商确定解决方案，将解决方案作为合同补充协议，双方签字存档。并作为验收标准。
召集EPG会议，讨论、修订分包合同附件，将规格、验收标准细化，保证以后的项目不会再出现此类问题。
上面谈到了做一个优秀QA的几个基本要素，要想做个优秀的QA，还有很多key point，这里就不赘述了。希望所有设有QA的企业，都能通过QA获得“Quality value-Added”。
“QA”——一个越来越多在软件企业中设立的岗位。但是一说起QA，很多人会问：“QA到底是干什么的？”。
QA（Quality Assurance）的中文含义是质量保证。
在ISO8402中对于QA的定义（1994）：“为了提供足够的信任表明实体能够满足品质要求，而在品质管理体系中实施并根据需要进行证实的全部有计划和有系统的活动”。
在CMMI中对于QA的定义是“有计划的和系统的管理方法，保证已定义的标准、实践、规程和过程方法得到应用”。
QA的基本职责是保证企业研发规范与实际操作实施的一致性，以及规范的有效性。通过监控软件的开发过程来保证产品的质量。保证软件产品、软件过程中存在的不符合问题得到处理，在项目组内不能解决的问题反映给高层经理决策解决。不包括开发软件产品和承担项目管理工作，这些是开发人员和项目经理的工作。
但是具体的工作内容和职责，不同的国度和不同的企业却有很大的不同。先看看国外的QA，很多企业的QA指的是测试人员；实施CMM/CMMI等标准化规范的企业，将QA定位在过程质量保证和体系改进。而国内企业的QA多数都有过程质量保证的职责，但也有不少的企业将测试与QA合二为一。
天融信对QA的定位
就像技术人员和管理人员一样，QA除了基本职责外，还有工作范围和深度的不同之分。以天融信为例，质量保证人员的岗位分为QA、资深QA、QA主管。
对于QA，除完成基本职责外，因为天天与项目组在一起，接触和掌握第一手信息，还会参与过程改进工作；
对于资深QA，在完成QA的工作外，由于具备多年丰富的项目管理和质量管理经验，要根据企业的商业和业务需求，负责质量体系的架构设计，承担主要规范文件的制定和改进工作；并能够指导其他QA和项目经理的工作；
对于QA主管，则要求在具备多年扎实的资深QA基本功以外，跟踪和熟悉企业产品业务，能够洞察不规范和责任定义不清的“管理灰色地带”，以“指导员”和“医生”的角度识别和标识出问题。这里的发现问题，不是比对流程，不是查看实际操作与流程的不符之处，而是要找出影响质量、左右进度、降低效率、削弱效果，进而损坏组织目标达成的不良现状来。这些现状可能包括流程问题、技术问题、工具问题、管理问题等。针对这些问题，在流程层面，在工程方法推行方面，在技术改进方面，在管理实施方面，在人员激励方面，给出解决方案或协调各方力量，组织专题会议，推动共同改进，即所谓借力行事。
QA给企业带来的变化
在实施CMMI之前，天融信没有QA这个岗位（当然也没有配置管理岗位）。项目经理都是研发出身，没有接受系统的项目管理培训，缺少有效的管理方法指导。由于缺少系统化、制度化的研发管理流程，缺少QA这样一个指导和监督机制，使得产品的计划交付时间很难准确预计，经常被推迟；项目管理、生产率等数据没有得到有效的记录和积累；个人的经验和技能不能有效地推广和转化为企业财富；成功项目的经验不能得到复用。
通过引入CMMI思想，其实不论CMM/CMMI还是ISO9000等其他管理思想，在这点上都是相通的，即强调法治而非人治。将行之有效的、优秀的管理和开发经验进行制度化，沉淀固化为制度，使项目的成功能够重复、不再成为一种与个人英雄相关的偶然行为。
在组织层面上，我们增设了QA岗位，在原有研发部门中增加了专职配置管理岗位，并组织公司研发总裁、骨干项目经理/测试经理、QA、配置管理员成立了EPG（工程过程组）。这体现了三权分立的思想：
EPG是立法机构，负责研发过程的制度化和改进；
EG（工程组，产品开发/测试人员组成）是执行和反馈机构，一方面遵循研发规范执行产品开发，一方面反馈执行中发现的问题和有效的经验；
QA既是监督机构，负责督促、指导研发规范贯彻实施；同时往往也是EPG的成员，参与研发过程的改进；
在项目层面上，当筹划一个项目团队时，首先要保证至少有以下三个人：项目经理、技术经理、QA。项目经理、技术经理、QA三个角色的职责分工不同。
项目经理负责项目筹划、组织资源和监控进度等管理性工作，不参与具体开发工作（但会参与需求、设计的讨论）；
技术经理承担需求分析、架构设计和技术指导，是项目组的技术核心人物；
QA独立于项目组之外，为项目组提供规范流程作为产品开发依据，指导和审核项目组是否按规范执行，要求敏锐地识别问题产生原因并将经验和纠正措施固化到流程中，实现过程改进，避免以后的项目重蹈覆辙。同时将自己在多个项目中积累的经验应用到其他项目组，帮助其他项目组避免重复其他项目组发生过的问题、促使项目成功完成；
这种机制保证了企业花大量的人力物力建立的规范开发制度，不会因缺少监督机构来进行督促，而导致项目在实施过程中由于这样或那样的原因而偏离既定轨道的，导致项目难于得到有效地控制，最终失败。企业的规范属于技术制度范畴，相当于法律，如果有法不依，执法不严，违法不究，那么法律就形同虚设、流于形式。所以非常有必要存在QA这么一个机构来维护企业开发制度的权威性，并督促项目有效地实施。
这一机制一直运行到现在，经过实际验证是非常有效的。例如，我们一个产品引入此机制后，新版本开发比原有版本生产率提高17%。并且按照规范做事，已经形成一种氛围，大家在做事之前，都会问一句：“这件事有没有规范，是怎么要求的？”
成为优秀QA的基本要素
QA的规范实施监督、指导工作，仅仅是基本工作。一个优秀的QA还会花更多的精力在过程改进的思考和实践上，这里的过程改进不是仅指根据CMMI等管理模型编写规范文件，而是通过实际参与项目活动，了解项目、产品问题，识别哪些环节是急待改进的，哪些问题可以通过完善流程避免以后出现。这里体现了两个层面的价值：
做该做的事：
不能理解用户的要求，你做出来的产品没有人会要。如同产品满足客户要求一样，如果不能标识出产品开发环节中真正存在的问题（这些问题往往是开发组最需要解决的），并将这些问题按照重要程度和紧迫程度排序，解决优先级最高的问题。开发组会说你订出的规范没有用。
不要埋怨开发人员认识不高，不懂规范的意义，不懂质量管理，不配合。QA经过了系统的质量管理培训，在看待质量的角度上自然比开发人员认识高。但光说大道理没有，解决了人家的问题，才是好QA。人家才明白：“哦，原来这就是过程改进，这就是规范化管理”，进而认识到规范管理的重要性和价值，并乐于参与其中。
做有价值的事：
以前经常看到有些QA每周发出报告，里面说：“项目按计划对分包商交付的产品包进行了评审，评审发现的问题已经解决，符合规范要求”。这样说不是不对，QA的基本职责的确是审核规范的一致性，但是要做一个优秀的QA还远远不够。
评审发现了问题，项目经理通过与分包商沟通解决了。但是，这属于对问题的纠正。那么，以后或别的项目是不是还会出现这类问题呢？这就是优秀QA发挥作用的地方，通过分析，发现原来是在签订分包合同时，规格不够详细，导致接收到的产品包部分指标不符合要求，因此我们应该做两件事：
组织项目经理和有关部门人员讨论，识别问题、与分包商协商确定解决方案，将解决方案作为合同补充协议，双方签字存档。并作为验收标准。
召集EPG会议，讨论、修订分包合同附件，将规格、验收标准细化，保证以后的项目不会再出现此类问题。
上面谈到了做一个优秀QA的几个基本要素，要想做个优秀的QA，还有很多key point，这里就不赘述了。希望所有设有QA的企业，都能通过QA获得“Quality value-Added”。
回复Comments
{commenttime}{commentauthor}
{CommentUrl}
{commentcontent}