质量保证工程师（QA）岗位职责

一、工作摘要
负责所分配项目质量保证计划的制订、项目开发过程中的质量保证的审计、组织阶段评审（含技术评审，决策评审，里程碑评审）、项目风险识别、预警。研发流程的执行监督、反馈、数据收集。运用规范的流程引导项目全员参与。对不符合项进行报告/追踪解决。负责度量数据的收集、文档维护、培训支持等。
二、工作职责
No.	类别	职  务	责  任
1	项目质量保证	制订具体项目的质量保证计划及执行	Ø         根据公司质量目标及项目实际情况，制订项目的质量保证计划，计划应当明确定义开发各阶段的质量保证活动和项目质量目标；严格执行质量保证计划。 Ø         依据质量保证计划审计项目是否按照过程要求执行了相应活动，是否按照过程要求产生了相应工作产品，并对工作成果的合理性进行审计；并按时提交项目的质量报告。 Ø         对不符合项有权发出不符合问题报告，并要求项目组分析原因采取措施预防再次发生，同时跟踪直到验证解决。
2	评审	评审的组织	Ø         根据项目计划，适时组织项目阶段评审（含技术评审，决策评审，里程碑评审）； Ø         审核评审材料的正确性、前后关联性、规范性； Ø         评审结果形成报告，提交相关领导审核，OA上提交； Ø         跟踪直至所有评审中发现的缺陷已被关闭；
3	风险控制	项目风险识别、预警	Ø         识别项目风险，组织进行风险等级评估以及可能会对项目的影响，督促项目经理采取风险预防措施； Ø         督促项目经理更新项目进度计划，使其包含与所采用的风险措施； Ø         监督项目风险预防或缓解措施的执行； Ø         定期对已识别的项目风险组织重新评估以确定风险状态是否已发生变化。
4	度量数据	参与项目考核和产品效益考核	Ø         根据考核制度收集项目过程绩效数据，并对项目奖考核、产品效益奖考核提供考核数据，形成记录； Ø         按项目类型，逐步建立不同类型项目的过程能力基准数据（进度计划达成率，生产率、工作量分布等）； Ø         分析过程能力基准数据的变化，度量过程改进实际效果
5	研发流程	研发流程的执行监督、反馈、数据收集	Ø         研发流程，发现存在的问题并及时反馈，识别流程优化的机会点并提出可行的优化解决方案； Ø         搜集项目组反馈，不断根据公司发展改进优化现有流程。 Ø         定期向流程组提供项目中流程执行情况及有关数据；
6	质量事故	负责产品研发质量事故的原因调查	Ø         对于研发过程中，因人为因素造成产品出现严重质量事故，由QA进行跟踪调查，分析其根本原因，并向组织通报质量事故。QA在下次执行同类项目时，及早提醒项目经理采取预防措施。
7	文档维护	项目文档维护管理	Ø         妥善存放项目开发过程中的管理文档； Ø         阶段评审通过的项目资料提交配置管理工程师入基线库； Ø         项目验收后的纸质开发文档列文档清单后提交文控中心存档；
8	培训支持	相关培训支持	Ø         对外提供项目管理、质量保证、项目管理工具方面的培训

 

建立、完善质量体系一般要经历质量体系的策划与设计，质量体系文件的编制、质量体系的试运行，质量体系审核和评审四个阶段，每个阶段又可分为若干具体步骤。

　　一、质量体系的策划与设计

　　该阶段主要是做好各种准备工作，包括教育培训，统一认识，组织落实，拟定计划；确定质量方针，制订质量目标；现状调查和分析；调整组织结构，配备资源等方面。

　　（一）教育培训，统一认识

　　质量体系建立和完善的过程，是始于教育，终于教育的过程，也是提高认识和统一认识的过程，教育培训要分层次，循序渐进地进行。

　　第一层次为决策层，包括党、政、技（术）领导。主要培训：

　　1.通过介绍质量管理和质量保证的发展和本单位的经验教训，说明建立、完善质量体系的迫切性和重要性；

　　2.通过ISO9000族标准的总体介绍，提高按国家（国际）标准建立质量体系的认识。

　　3.通过质量体系要素讲解（重点应讲解“管理职责”等总体要素），明确决策层领导在质量体系建设中的关键地位和主导作用。

　　第二层次为管理层，重点是管理、技术和生产部门的负责人，以及与建立质量体系有关的工作人员。

　　这二层次的人员是建设、完善质量体系的骨干力量，起着承上启下的作用，要使他们全面接受ISO9000族标准有关内容的培训，在方法上可采取讲解与研讨结合，理论与实际结合。

　　第三层次为执行层，即与产品质量形成全过程有关的作业人员。对这一层次人员主要培训与本岗位质量活动有关的内容，包括在质量活动中应承担的任务，完成任务应赋予的权限，以及造成质量过失应承担的责任等。

　　（二）组织落实，拟定计划

　　尽管质量体系建设涉及到一个组织的所有部门和全体职工，但对多数单位来说，成立一个精干的工作班子可能是需要的，根据一些单位的做法，这个班子也可分三个层次。

　　第一层次：成立以最高管理者（厂长、总经理等）为组长，质量主管领导为副组长的质量本系建设领导小组（或委员会）。其主要任务包括：

　　1.体系建设的总体规划；

　　2.制订质量方针和目标；

　　3.按职能部门进行质量职能的分解。

　　第二层次，成立由各职能部门领导（或代表）参加的工作班子。这个工作班子一般由质量部门和计划部门的领导共同牵头，其主要任务是按照体系建设的总体规划具体组织实施。

　　第三层次：成立要素工作小组。根据各职能部门的分工明确质量体系要素的责任单位，例如，“设计控制”一般应由设计部门负责，“采购”要素由物资采购部门负责。

　　组织和责任落实后，按不同层次分别制定工作计划，在制定工作计划时应注意：

　　1.目标要明确。要完成什么任务，要解决哪些主要问题，要达到什么目的？

　　2.要控制进程。建立质量体系的主要阶段要规定完成任务的时间表、主要负责人和参与人员、以及他们的职责分工及相互协作关系。

　　3.要突出重点。重点主要是体系中的薄弱环节及关键的少数。这少数可能是某个或某几个要素，也可能是要素中的一些活动。

[NextPage]

　　（三）确定质量方针，制定质量目标

　　质量方针体现了一个组织对质量的追求，对顾客的承诺，是职工质量行为的准则和质量工作的方向。

　　制定质量方针的要求是：

　　1.与总方针相协调；

　　2.应包含质量目标；

　　3.结合组织的特点；

　　4.确保各级人员都能理解和坚持执行。

　　（四）现状调查和分析

　　现状调查和分析的目的是为了合理地选择体系要素，内容包括：

　　1.体系情况分析。即分析本组织的质量体系情况，以便根据所处的质量体系情况选择质量体系要素的要求。

　　2.产品特点分析。即分析产品的技术密集程度、使用对象、产品安全特性等，以确定要素的采用程度。

　　3.组织结构分析。组织的管理机构设置是否适应质量体系的需要。应建立与质量体系相适应的组织结构并确立各机构间隶属关系、联系方法。

　　4.生产设备和检测设备能否适应质量体系的有关要求。

　　5.技术、管理和操作人员的组成、结构及水平状况的分析。

　　6.管理基础工作情况分析。即标准化、计量、质量责任制、质量教育和质量信息等工作的分析。

　　对以上内容可采取与标准中规定的质量体系要素要求进行对比性分析。

　　（五）调整组织结构，配备资源

　　因为在一个组织中除质量管理外，还有其他各种管理。组织机构设置由于历史沿革多数并不是按质量形成客观规律来设置相应的职能部门的，所以在完成落实质量体系要素并展开成对应的质量活动以后，必须将活动中相应的工作职责和权限分配到各职能部门。一方面是客观展开的质量活动，一方面是人为的现有的职能部门，两者之间的关系处理，一般地讲，一个质量职能部门可以负责或参与多个质量活动，但不要让一项质量活动由多个职能部门来负责。目前我国企业现有职能部门对质量管理活动所承担的职责、所起的作用普遍不够理想总的来说应该加强。

　　在活动展开的过程中，必须涉及相应的硬件、软件和人员配备，根据需要应进行适当的调配和充实。

　　二、质量体系文件的编制

　　质量体系文件的编制内容和要求，从质量体系的建设角度讲，应强调几个问题：

　　1.体系文件一般应在第一阶段工作完成后才正式制订，必要时也可交叉进行。如果前期工作不做，直接编制体系文件就容易产生系统性、整体性不强，以及脱离实际等弊病。

　　2.除质量手册需统一组织制订外，其它体系文件应按分工由归口职能部门分别制订，失提出草案，再组织审核，这样做有利于今后文件的执行。

　　3.质量体系文件的编制应结合本单位的质量职能分配进行。按所选择的质量体系要，素，逐个展开为各项质量活动（包括直接质量活动和间接质量活动），将质量职能分配落实到各职能部门。质量活动项目和分配可采用矩阵图的形式表述，质量职能矩阵图也可作为附件附于质量手册之后。

　　4.为了使所编制的质量体系文件做到协调、统一，在编制前应制订“质量体系文件明细表”，将现行的质量手册（如果已编制）、企业标准、规章制度、管理办法以及记录表式收集在一起，与质量体系要素进行比较，从而确定新编、增编或修订质量体系文件项目。

[NextPage]

　　5.为了提高质量体系文件的编制效率，减少返工，在文件编制过程中要加强文件的层次间、文件与文件间的协调。尽管如此，一套质量好的质量体系文件也要经过自上而下和自下而上的多次反复。

　　6.编制质量体系文件的关键是讲求实效，不走形式。既要从总体上和原则上满足 ISO9000族标准，又要在方法上和具体做法上符合本单位的实际。三、质量体系的试运行

　　质量体系文件编制完成后，质量体系将进入试运行阶段。其目的，是通过试运行，考验质量体系文件的有效性和协调性，并对暴露出的问题，采取改进措施和纠正措施，以达到进一步完善质量体系文件的目的。

　　在质量体系试运行过程中，要重点抓好以下工作：

　　1.有针对性地宣贯质量体系文件。使全体职工认识到新建立或完善的质量体系是对过去质量体系的变革，是为了向国际标准接轨，要适应这种变革就必须认真学习、贯彻质量体系文件。

　　2.实践是检验真理的唯一标准。体系文件通过试运行必然会出现一些问题，全体职工立将从实践中出现的问题和改进意见如实反映给有关部门，以便采取纠正措施。

　　3.将体系试运行中暴露出的问题，如体系设计不周、项目不全等进行协调、改进。

　　4.强信息管理，不仅是体系试运行本身的需要，也是保证试运行成功的关键。所有与质量活动有关的人员都应按体系文件要求，做好质量信息的收集、分析、传递、反馈、处理和归档等工作。

　　四、质量体系的审核与评审

　　质量体系审核在体系建立的初始阶段往往更加重要。在这一阶段，质量体系审核的重点，主要是验证和确认体系文件的适用性和有效性。

　　1.审核与评审的主要内容一般包括：

　　（1）规定的质量方针和质量目标是否可行；

　　（2）体系文件是否覆盖了所有主要质量活动，各文件之间的接口是否清楚；

　　（3）组织结构能否满足质量体系运行的需要，各部门、各岗位的质量职责是否明确；

　　（4）质量体系要素的选择是否合理；

　　（5）规定的质量记录是否能起到见证作用

　　（6）所有职工是否养成了按体系文件操作或工作的习惯，执行情况如何。

　　2.该阶段体系审核的特点是：

　　（1）体系正常运行时的体系审核，重点在符合性，在试运行阶段，通常是将符合性与适用性结合起来进行；

　　（2）为使问题尽可能地在试运行阶段暴露无遗，除组织审核组进行正式审核外，还应有广大职工的参与，鼓励他们通过试运行的实践，发现和提出问题；（3）在试运行的每一阶段结束后，一般应正式安排一次审核，以便及时对发现的问题进行纠正，对一些重大问题也可根据需要，适时地组织审核；

　　（4）在试运行中要对所有要素审核覆盖一遍；

　　（5）充分考虑对产品的保证作用；

　　（6）在内部审核的基础上，由最高管理者组织一次体系评审。

　　应当强调，质量体系是在不断改进中行以完善的，质量体系进入正常运行后，仍然要采取内部审核，管理评审等各种手段以使质量体系能够保持和不断完善。 window.google_render_ad();

1.   是否涵盖了需求文档上的每个功能点

2.   是否涵盖了需求文档上的每条业务规则说明

3.   是否覆盖了输入条件的各种有意义组合

4.   是否覆盖了业务操作的基本路径和异常路径

5.   是否考虑了重要表单字段的数据合法性检查

6.   是否考虑了其他的测试类型（对某个功能很重要，但未在需求文档中提及的，如安全测试、周期性测试和故障恢复等方面）

7.   是否考虑了对其他模块/功能的影响

8.   是否使用了项目组的标准用例模板

9.   用例是否覆盖了测试设计中定义的所有场景

10.用例编号是否统一、规范

11.用例名称是否简洁、明了

12.目的字段是否准确地描述了对应场景的测试输入的特征（不同数据，操作，配置等）

13.前提条件字段的条目是否充分、准确，操作上是否不依赖于同组之外的其他用例

14.对应的需求编号字段是否填写正确

15.用例粒度、预估出的执行时间是否适当

16.同组用例中，仅数据不同的，是否实现了测试步骤的重用

17.某个功能点的第一个用例是否是基本流的

18.操作步骤的描述，是否清晰、易懂

19.操作步骤是否充分和必要，并具有可操作性

20.测试用例的检查点是否明确、充分和可操作

21.单个用例步骤或检查点中是否不再存在分支

22.测试数据的特征描述是否准确，有条件的情况下，是否给出了一个当前环境下的可用参考值

23.文字、语法是否准确；布局、格式是否统一

.1   度量的目的

度量活动首要考虑的是目的，测试中的度量一般有如下目的：

a)     判断测试的有效性

b)     判断测试的完整性

c)     判断工作产品的质量

d)     分析和改进测试过程

 

1.2   度量内容

   度量的数据构成一个层次化的体系，就是度量框架。框架的上层是度量指标(Factor)，下层是直接度量(Metrics)。度量指标表示产品或过程的特征，需要从直接度量计算而来。而直接度量是可以直接收集到的数据。下面分别说明系统测试中需要测量的度量内容，注意区分其中的度量指标和直接度量。

 

1.2.1进度（时间）度量

a)     计划的测试开始、结束时间

b)     实际的测试开始、结束时间

c)     执行测试用例的时间。

1.2.2成本度量

1.     计划投入测试的工作量(人时)

2.     计划投入测试的资金

3.     实际投入测试的工作量(人时)

4.     实际投入测试的资金

5.     评审投入的工作量（人时）

6.     缺陷修正成本（提交缺陷、研究缺陷、改正缺陷、验证等所需时间）

7.     累积测试时间。对每一个发布的版本，累积测试时间等于该版本在演变过程中经历的所有测试的测试时间之和。包括完整测试、验证测试和回归测试。 

 

1.2.3规模度量

1.     被测对象的规模（功能点、代码行（有效代码行，注释行）等）

2.     系统需求数目

3.     测试用例数目（总用例数、计划执行数、实际执行数）

 

1.2.4测试质量（效率）度量

1．  测试覆盖率

    a)需求覆盖率： 需求覆盖率=至少被测试用例覆盖一次的需求数/系统总需求数     b)测试用例覆盖率： 测试用例覆盖率=计划执行的测试用例数/测试用例总数

    c)测试用例执行率： 测试用例执行率=实际执行的测试用例数/计划执行的测试用例数

     d)测试用例通过率：测试用例通过率＝(实际执行的测试用例数-测试执行不通过的测试用例数)/实际执行的测试用例数

 

2．  缺陷检测率对某一版本，某一个环节（阶段）的缺陷检测率＝(A/（A＋B）)*100％。

其中：

A:测试人员查找出的不包括重复缺陷的数量。

B：用户（包括下一环节的部门）报告的不包括重复缺陷的数量。

 

3．  测试过程能力

单位缺陷开销＝测试投入的工作量（人时）/缺陷总数

 

1.2.5产品质量度量

1.     版本发布前缺陷数

2.     版本发布后缺陷数

3.     评审发现的缺陷数

4.     缺陷修正率：缺陷修正率＝发布前已修正的缺陷数/发布前已知的缺陷总数。

5.     缺陷密度：千行代码缺陷率＝测试和评审中发现的缺陷数/被测目标的代码的规模（KL）

测试过程改进的大致内容：

1.重视测试软件的需求分析：

  在测试过程改进中要特别注意这一点，很多公司的测试人员都不太重视测试需求分析，由于时间紧或测试人员有限，不得不看了一部分需求，就开始编写相应的测试用例，这也不是什么大惊小怪的事了。我建议：首先，了解获取需求的渠道，保证测试需求比较全面准确。

其次，可以罗列出功能测试或业务测试需求点，让用户和项目组成员评审确认，避免测试后期由于时间原因而导致漏测。

 

2.提高测试计划的可执行性：

  很多时候，测试部门测试经理在项目测试初期，编写了一个测试计划以后，后面不管是发生了什么情况，测试计划都不会做相应的调整，这就导致测试计划成了摆设，应付领导检查了事的文档，没有真正发挥测试计划的指导性作用。不知道大家是否有同感。我的做法：把测试计划分成大计划和小计划。先写大计划，后编写小计划。大计划通过估算一旦确定后，基本上改动不大。小计划要跟随项目的测试情况，随时调整或修改，当然这就对“测试经理”预估测试工作量的能力要求比较高。预估不准那就每周改计划吧，呵呵！

 

3.合理安排测试活动的顺序：不合理的测试顺序，可能会引起务工，测试效率低下。如果不立即采取相应的措施，到后来还会导致测试进度失控。比如说一个项目中，哪些测试活动必须有先后顺序，哪些测试活动能够并行开展，哪些测试活动可以合并，作为测试Leader必须要非常清楚。不明白测试活动的顺序，让测试活动自由发展，何谈测试过程改进？

 

4.优化测试文档设计： 测试文档的优化，也不是一蹴而就的事情，需要我们不断提高测试文档的编写能力，循序渐进逐步提高。我们尽量保证测试文档的可读写高，任何人都能够看懂，都能够执行，也许这是一个理想化的境界吧，呵呵！！在这个前提下，尽量保证较少的测试用例，覆盖较多的需求内容，可能这一点实施难度比较大。

 

5.强化测试资源的最优配置：

  软件测试是一个非常复杂的过程，需要人力资源、测试设备、测试环境等多个因素密切相关。比如说测试设备配置多少个为最佳？每个模块配置的测试人员的能力水平需要达到什么程度？需要多少个测试人员？等等问题。我们必须给出一个最优的资源配置方案。

 

6.参与部分开发文档的讨论：

一般情况下，不懂开发的测试人员，很难发现深层次、严重等级较高的缺陷。比如说Web测试，如果你不懂Oracle数据库设计文档，你很难确定页面显示的结果是否是真实的数据。不了解详细设计文档，很多业务流程可能就不会太清晰，这也就是为什么第一轮测试时，测试人员老是去问开发人员的原因？如果在测试前期，参与了部分开发文档的讨论，尽量了解每个数据库中每个字段的意思，对开发了解深入一些，可能测试深度就不一样了。

 

7.全面分析测试结果，确定合理的测试度量标准：

  全面分析阶段测试结果，总结测试经验和系统缺陷，分析测试过程中存在的问题，提交有价值的测试报告，推动相关高层管理人员予以关注，促进问题和缺陷得到有效的解决，这才能够起到关键性的作用。同时，要确定一个比较合理的测试度量标准，不断实践、不断总结、不断改进，提出符合公司实际情况的测试过程改进措施。

 

8.兼顾成本的前提下，尽量保证测试的覆盖率：

 在保证测试成本的前提下，我们要尽可能的提高测试的覆盖率。其中测试覆盖：包括测试内容覆盖、测试技术覆盖和测试过程覆盖。我们可以通过测试用例覆盖率来提高测试的质量，保证较多的缺陷在版本发布以前被测试组发现。也可以通过提高测试技术覆盖率，用实践来验证，不能够轻易相信部分行业人士的一面之词，而误入歧途。在保证公司盈利的情况下，尽量提高测试的覆盖率，提高测试质量。 

 

测试过程改进的注意事项：

1.切忌“好高骛远”脱离公司实际：

  很多时候，软件公司大家都一窝蜂的赶时髦。我们一提到测试过程改进，大家都想像“测试规范”一样弄得非常全面，大部分都停留在理论上，花了大量的人力和物力，往往脱离了公司的实际情况，得不丧失，结果可想而知。

 

2.测试过程改进不能盲目跟风，切不可赶潮流：

 一个公司近年来的发展方向一旦确定，那就要坚持走下去。如果定位不一样，那对测试过程改进的要求也就不一样。比如说一个小公司，本来测试人员都很少，测试资源都有限，正常测试都无法保证，那你觉的谈“测试过程改进”还有意义吗？再比如说小公司有测试过程改进的经济实力，那也无法和大公司相比，毕竟企业也要赚钱、盈利、生存。所以，测试改进时，一定要考虑测试部门的规模、公司的商业机会、企业经济实力等等方面的因素，更不应该盲目跟风。合适的才是最好的！过程改进，切不可赶潮流！

 

3.测试过程改进最好由专人负责：

  在中国，很多时候，一个人干多个人的事情，拿到的工资与付出不成正比，亏呀！！！比如说在我们公司，凡是涉及到软件测试的工作，都由测试经理负责，包括“测试过程改进”、“测试规范制定”、“测试模板制定”、“自动化测试”呀？什么的，都一个人干，甚至包括QA的工作，都快被累死了，呵呵！！最主要是一个人干几个人该做的事情，很容易分散精力，并且考虑也不会很周到，也没有一个人专业了。建议由专人来负责测试过程的改进比较好，测试过程改进成功的几率会大很多。

 

4.测试过程改进并不等于花费大量资金

 大部分的测试公司，在测试过程改进上都是走走过场，为得都是应付客户。有的公司是请一些测试专家进行咨询，不仅花费大量的时间，还耗费的大量的资金。有的公司是买一些测试工具、缺陷工具，当然开销也不小。我觉得：如果条件允许的情况下，各方面都可以跟上，那样比较理想。如果公司经济条件有限，我建议针对公司的实际情况，合理利用测试部门的集体智慧，改进测试过程方为良策。

 

5.测试过程改进不能够急于求成：

软件测试过程改进，作为软件测试的一个阶段，我们只能够循序渐进，不能急于求成。我们应该正确处理好测试和测试过程改进的主次关系，一步一步用实践验证来完善。相信只要经过测试部门的不断努力，测试过程改进一定会取得成功.