QA日常审计工作

       QA的审计，这是一种专项或者主题的审计，包括了过程审计和产品审计。

        国内的QA职业是伴随CMMI的推广而萌生的，很多小的软件企业是没有质量工程师这个岗位的。很多企业认为QA要对软件质量负责，这句话不完全对，能够对软件质量负责的是设计、开发软件的人员，

        有专门对软件进行测试的工程技术人员（QC，质量控制）。QA的工作主要是对过程管理方法的改善、对软件产品进行第三方的客观评价。

1.过程审计

按照流程定义、规范制作QA的《过程检查表》对项目组的文档和交付物进行检查，必要时展开人员访谈，记录问题。

•         公司已经有规范的流程，那么只需要按部就班的进行检查，这类QA也叫警察QA。
•         公司没有很规范的流程，那么就需要对流程规范和再造，这类的QA也叫医生QA。
•         公司没有任何流程管理的实施经验，那么需要教练QA能够引导大家走上正轨。

常规的项目过程审计核心内容包括：

• 不同规模（合同金额、功能点、代码行、文档页数）的项目裁剪的情况。可能根据规模重新制定裁剪表的模板。
• 不同行业领域的项目裁剪情况。可能根据领域的工程流程不同制定新的裁剪表模板。
• 项目里程碑进度是否和计划发生偏差。
• 项目是否发生变更。

评审过程一览表

#	评审对象	评审类型	参展标准	评审时间
1	立项活动
2	产品立项	过程评审	《立项管理程序》《配置管理过程》	每2周
3	项目立项	过程评审	《立项管理程序》《配置管理过程》	每2周
4	需求管理活动
5	需求定义	过程评审	《需求管理过程》	需求评审后
6	需求跟踪	过程评审	《》
7	项目策划、集成软件管理、组件协调活动
8	项目定义	过程评审	《项目策划过程》	立项报告完成
9	工作分解	过程评审	《项目策划过程》	工作拆分完成
10	风险管理计划	过程评审	《风险管理规程》	风险管理计划完成
11	规模估计	过程评审	《软件估计规程》	估算完成后
12	跟踪与监控活动
13	度量与分析	过程评审	《项目跟踪与监控过程》	每2周
14	项目控制	过程评审	《项目跟踪与监控过程》	每2周
15	项目报告	过程评审	《项目跟踪与监控过程》	每2周
16	里程碑评审	管理评审	《评审过程》	里程碑点
17	配置管理活动
18	基线定义	过程评审	《配置管理规范》 《配置管理计划规程》 《配置管理计划模板》 《命名规程》	配置管理计划完成后
19	基线控制变更	过程评审	《配置管理计划规范》 《基线发布控制规程》	里程碑基线变更时
20	配置状态报告	过程评审	《配置管理规范》 《配置管理过程》 《配置状态报告模板》	每2周
21	评审、审计和发布	过程评审	《配置管理规范》 《配置管理过程》	里程碑纳入基线时
22	CM管理工作	过程评审	《配置管理规范》 《配置管理过程》	每2周
23	培训活动
24	制定培训计划	过程评审	《培训过程》 《培训计划模板》	培训计划制定完成后
25	培训实施	过程评审	《培训过程》 《培训指南》	培训后
26	培训管理活动	过程评审	《培训过程》 《培训需求调查报告模板》 《培训总结报告模板》	每2周
27	同行评审活动
28	评审	过程评审	《评审过程》	每2周

 

2.产品审计

      对交付物的关键不合格点进行检查，这种审计不是去做测试人员做的测试，而是第三方的客观评价。

     能够做产品审计的只有行业的专家才有能力去做，专家要充当警察和医生级别的QA的角色，所以才需要有专家参与的评审活动去保证产品质量。

     很多公司因为成本原因不可能为单独一个项目配备专门的QA，所以在项目中，一般都是项目经理充当了QA的角色，项目经理去检查质量，在PMP的管理中，项目经理是需要做质量管理的，但是这种既当运动员又当裁判员的管理往往都做的不尽如人意。有些公司的实践是每个熟悉流程的人员只检查自己负责的那一部分，项目QA去检查项目经理的项目管理做好了没，项目经理有技术背景的去检查编码做好了没，测试人员检查需求和设计做好了没，组织级QA再去检查项目QA做好了没。

审计产品一览表

#	审计对象	参照的标准
1	用户需求说明书	《用户需求说明书模板》
2	软件需求规格说明书、需求跟踪矩阵	《产品需求规格说明书模板》
3	项目策划	《项目计划模板》 《测试计划模板》 《配置管理计划模板》 《质量保证计划模板》
4	概要设计说明书	《概要设计模板》
5	详细设计说明书	《详细设计模板》
6	界面、源代码	《界面规范》、《编码规范》
7	测试报告	《测试规程》、《测试报告模板》
8	用户文档	《用户需求说明书》 《概要设计》、《详细设计》、《用户手册》
9	最终产品	《用户需求说明书、合同》

              

      工作成果的同行评审有两种形式：正式技术评审（FTR）和非正式技术评审（ITR）。FTR需要举行评审会议，参与评审会议的人数相对较多。ITR形式比较灵活，一般在同伴之间开展。

工作产品	评审方式	执行人	评审依据
立项申请 立项可行性研究报告	FTR	项目经理 QA	立项评审检查表、立项建议书模板、立项可行性分析报告
项目计划	FTR/ITR		项目计划、配置管理计划、测试计划和质量保证计划模板、评审检查表
质量保证计划
配置管理计划
测试计划
用户需求文档	FTR		用户需求、评审检查表
需求规格说明书	FTR		需求规格说明书模板、评审检查表
概要设计文档	FTR		用户需求、设计评审检查表
详细设计文档	FTR/ITR		用户需求、设计评审检查表
测试用例	FTR/ITR		需求文档、测试规范、测试计划、评审检查表
测试报告	FTR		需求文档、测试计划、用例
用户手册	FTR/ITR		需求文档、测试用例
内部验收	FTR		需求文档

 QA工作的度量表

度量内容	度量时机	度量方法	计划值
对项目开发工作的支持所花费的工时	提交质量报告	支持活动所花费的工时记录在《个人周报》中	计划工时
QA产品审计所花费的工时次数	审计完成	审计花费的工时记录在《QA产品审计表》中	计划工时
			计划次数
QA过程评审所花费的工时次数	评审完成	评审花费的工时记录在《QA产品审计表》中	计划工时
			计划次数

 

         QA再细分，会有专门负责项目的PQA（项目QA）和在PMO工作的OQA（组织级QA），OQA主要对项目群的整体运行情况进行客观评价，所以会用到很多数据和统计报表，然后对体系文件进行适当的调整。

 

 

我的工作实践

 审计的内容包括

1. 立项环节的估算过程、立项各个材料中的进度时间节点、资源情况的一致性查的较严。目前的估算只是基于功能规模分解的工作量总计，项目经理还没有考虑进度、风险等制约因素。目前推行的delphi方法主要为了估算期间就获得项目组成员的承诺。
2. 项目周报监控的6个关键指标是否都在执行。
3. 项目结项的文档清单和SVN的一致性。
4. 例行的月度SVN配置库提交情况检查。（以前有发现有人离职，资料不全或者没有的情况，只是提醒各经理加强管控）
5.  临时布置的项目的专项审计工作任务。

每月预期的项目审计工作包括

1.  如果需要监控项目进度的真实性，那么就需要对物理配置审计中的第6项。
2. 模板变更后的执行情况检查和内容审计。
3. 各部项目SVN配置库的提交情况。
4. 部分领导觉得有问题的项目进行的第三方独立审计。

配置物理审计

1. 检查SVN库的结构是否标准统一。
2. 检查每个配置项的命名是否符合规范（和编码规范类似）。
3. 检查建立基线的过程、变更管理是否符合公司的流程和规范。（上次的审计报告已经谈到了变更流程不规范的问题）
4. 检查《项目裁剪表》未被裁剪的文档是否提交。
5. 检查公司体系文件中各个不同流程文档模板的使用情况。（为修订体系文件做数据支撑）
6. 检查规定的里程碑阶段是否提交了应该提交的所有文档。这个审计就引出了另外两个需要审计的问题。

配置功能审计

（实际上是第三方抽检需求跟踪的情况），审计的方法可以检查基线关联关系，也可以检查需求跟踪矩阵，也可以自己进行抽检和统计。：

1. 检查需求规格说明书中的内容在设计说明书中是否实现。
2. 检查设计说明书的内容在软硬件产品中是否实现。
3. 检查需求规格说明书中的内容是否在软硬件产品中实现。

功能审计在不同的软件公司执行人可能不同。

1. 有产品经理的公司一般是产品经理要完成类似的审计工作
2. 没有产品经理的公司，在项目组中，项目经理要对功能审计负责（这是范围管理中的一部分），其次负责的依次是测试工程师，设计工程师，项目QA，开发工程师。