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主要对项目群的整体运行情况进行客观评价,所以会用到很多数据和统计报表,然后对体系文件进行适当的调整。
我的工作实践
审计的内容包括
- 立项环节的估算过程、立项各个材料中的进度时间节点、资源情况的一致性查的较严。目前的估算只是基于功能规模分解的工作量总计,项目经理还没有考虑进度、风险等制约因素。目前推行的delphi方法主要为了估算期间就获得项目组成员的承诺。
- 项目周报监控的6个关键指标是否都在执行。
- 项目结项的文档清单和SVN的一致性。
- 例行的月度SVN配置库提交情况检查。(以前有发现有人离职,资料不全或者没有的情况,只是提醒各经理加强管控)
- 临时布置的项目的专项审计工作任务。
每月预期的项目审计工作包括
- 如果需要监控项目进度的真实性,那么就需要对物理配置审计中的第6项。
- 模板变更后的执行情况检查和内容审计。
- 各部项目SVN配置库的提交情况。
- 部分领导觉得有问题的项目进行的第三方独立审计。
配置物理审计
- 检查SVN库的结构是否标准统一。
- 检查每个配置项的命名是否符合规范(和编码规范类似)。
- 检查建立基线的过程、变更管理是否符合公司的流程和规范。(上次的审计报告已经谈到了变更流程不规范的问题)
- 检查《项目裁剪表》未被裁剪的文档是否提交。
- 检查公司体系文件中各个不同流程文档模板的使用情况。(为修订体系文件做数据支撑)
- 检查规定的里程碑阶段是否提交了应该提交的所有文档。这个审计就引出了另外两个需要审计的问题。
配置功能审计
(实际上是第三方抽检需求跟踪的情况),审计的方法可以检查基线关联关系,也可以检查需求跟踪矩阵,也可以自己进行抽检和统计。:
- 检查需求规格说明书中的内容在设计说明书中是否实现。
- 检查设计说明书的内容在软硬件产品中是否实现。
- 检查需求规格说明书中的内容是否在软硬件产品中实现。
功能审计在不同的软件公司执行人可能不同。
- 有产品经理的公司一般是产品经理要完成类似的审计工作
- 没有产品经理的公司,在项目组中,项目经理要对功能审计负责(这是范围管理中的一部分),其次负责的依次是测试工程师,设计工程师,项目QA,开发工程师。