结合担任SQA人员的亲身体会，总结出SQA人员在CMM三级标准下怎样做好自己的工作。
1 引言
在CMM标准下，SQA人员独立于软件项目组负责软件质量保证，具体的职责在我们的《软件质量保证》（机构标准v1.1）KPA文档中定义如下：
1) 实施软件质量保证活动；
2) 定期总结并提交软件质量保证活动的审核报告；
3) 制定项目的SQA计划；
4) 参加项目的软件开发计划、标准和过程的准备及评审；
5) 协助项目经理建立项目的质量目标；
6) 跟踪和监督纠正措施的实施；
7) 定期和必要时分析项目提供的原始数据并报告结果；
8) 如果需要，与客户的SQA人员定期评审SQA人员的活动及发现的问题。
其实，以上职责中，第一条就已经涵盖了其他几条的内容，只不过其他几条更加具体，是第一条职责的细化。但是，这些职责只是文档中定义了的而已，并不全面，特别是对于刚开始实施CMM的企业来说，SQA为了达到软件质量保证的目的，要做很多其他的工作。因为他要进行质量保证，首先必须要推广CMM，也就说，他必须不断地跟软件项目组和相关组的人员解释CMM的标准是怎样的，才能让他们按照CMM的标准作。因此，一名SQA的活动可以围绕两个方面来进行：一是推广CMM标准，二是检查执行情况。
2 SQA怎样推广CMM标准
尽管公司在正式实施CMM之前对和软件项目有关的人员会进行有关CMM的培训，但这样并不足以使CMM标准的执行者足以理解它，更谈不上去操作它。怎样让他们更多地知道CMM标准，使他们在工作中能够按照CMM标准去做呢？这些都依靠和他们密切相关的SQA人员的努力。
SQA人员在履行职责之前，应该认真的学习CMM标准，深刻理解每个KPA的目的，熟练掌握每个KPA的流程。然后，对于公司定义的CMM标准要非常的熟悉，不仅要知道SQA在本公司每个KPA是怎样操作的，而且要知道其他角色按照本公司定义的CMM标准的工作流程，还要知道公司软件开发中每一种工作产品的质量标准。以上这些条件构成SQA人员推广CMM标准的前提。
在刚刚开始实施CMM时，碰到的问题往往要比想象的还多，作为一名SQA人员，要本着解决这些问题的目的去进行自己的工作，而并不只是起到监督的作用。SQA人员在负责一个软件项目的质量保证工作时，要随时了解项目的进展情况，在软件项目组的每一个活动之前，就要和软件项目组成员特别是软件项目经理进行交流，直到他们知道按照CMM的标准应该怎样去做。比如说，在进入项目之前，就要告诉软件项目组按照公司定义的CMM标准怎样去管理需求。有些活动并不是必须要求SQA人员参加的，如周例会，但为了指导软件项目经理怎样跟踪项目的工作量、进度、风险等等，SQA人员通常也是每会必到，在会后还要指导他们填写周报等等。
即使软件项目组的每一个活动都是在SQA人员的指导下完成的，SQA人员在对项目进行评审时，仍然可以找到一些与CMM标准不相符的地方，因为软件项目组每一个人对CMM标准的理解程度并不一样，具体执行起来还会存在一定的偏差。SQA人员发现这些问题后，首先应及时和软件项目经理进行沟通，争取对这些问题达成共识，同时，要对他们的工作加以肯定，强调他们工作成绩是主要的，这些问题在CMM刚刚实施时是难免的，是很容易克服的。千万不要轻易上报，否则，很容易打击他们的积极性，甚至引起抵触情绪。
也许，当SQA人员针对评审时发现的问题给软件项目经理提出改进建议后，项目经理出于进度的压力或其他原因，并不引起重视甚至拒绝采取任何措施，这是很正常的现象，SQA人员也不要立即上报，否则，更加不利于问题的解决。在这个时候，SQA人员要理解软件项目经理，要为他们提供更为方便的服务，尽量减少他们的工作量，例如，提供别的项目的同类文档以供参考，共同去填一些表格，把模板针对项目做一些细化、具体工作等等。一般情况下，软件项目经理在这样的引导下还是会尽量去改进的，除非极端情况下，才向高级管理者汇报。
总之，SQA人员在自己对CMM标准非常熟悉的情况下，要有足够的耐心和决心，把CMM标准推广到项目中去。在软件项目组所有成员按照CMM标准做过一两个项目之后，对这种工作流程和标准会比较熟悉，而且执行之后的优越性会逐渐体现出来，SQA人员的工作会慢慢变得轻松一些。
3 几个KPA中的SQA活动
3.1 需求管理
在这个KPA中，SQA必须检查软件项目组一下几个方面：
1) 给定需求交给软件项目组之前经过评审，确保需求没有问题；
2) 当给定需求发生变更时，软件开发计划、工作产品和活动有没有进行相应的适当的修改；
3) 由于给定需求更改引起了约定的更改，这些更改由没有经过相关小组协商。
对于第一方面的检查，是SQA在参与制定软件开发计划之前，检查软件项目组的《客户需求书》评审记录，如果评审没有通过，是否有再评审。由于《客户需求书》已经纳入配置管理，SQA在每月审核基线库的时候，可以发现给定需求的变更情况，同时要审核软件开发计划、工作产品和活动是否针对变更的需求进行了适当的修改，审核约定更改是否经过相关小组的签字确认，这样就检查第二和第三方面的内容。
3.2 软件项目计划
在这个KPA中，SQA必须检查软件项目组一下几个方面：
1) 软件估计和计划的活动是否进行；
2) 评审和形成项目约定的活动是否进行；
3) 制定软件开发计划的活动是否进行；
4) 用于制定软件开发计划的标准是否遵守；
5) 软件开发计划的内容是否完整。
由于SQA人员要参照软件开发计划制定SQA计划，所以必须密切关注软件项目组的计划制定情况，同时也在审核软件开发计划活动。在软件开发计划制定完毕后，SQA必须评审软件开发计划，首先对照软件开发计划模板，审核计划的内容是否完整，是否符合给定需求、项目、客户等的标准，审核计划中是否有工作产品规模、工作量、成本、进度和风险的估计，估计的方法是否适合。
3.3 软件项目跟踪和监督
在这个KPA中，SQA必须检查软件项目组一下几个方面：
1) 评审和修改约定的活动是否进行；
2) 修订软件开发计划的活动是否进行；
3) 修订软件开发计划的内容是否进行；
4) 跟踪软件项目的成本、进度计划、风险、技术和设计限制、功能和性能等有关活动是否进行；
5) 实施计划安排的评审技术和管理的活动是否进行。
里程碑时，SQA通过检查约定修改和评审的记录审核该活动是否进行；检查当前工作产品审核软件开活动是否与计划相符，如果不符，审核是否有修订软件开发计划的活动；通过检查软件项目组的周报审核软件项目经理是否跟踪软件项目的成本、进度、风险、技术等；对照同行评审计划的内容检查评审记录，验证计划安排的评审技术和管理活动是否进行。
3.4 软件配置管理
在这个KPA中，SQA必须检查软件项目组一下几个方面：
1) SCM组、SCCB、软件项目组是否遵循SCM的标准和规程；
2) 对软件基线有定期审核。
SQA每月定期审核配置管理活动，对照软件配置管理计划检查配置管理员是否及时将配置项纳入配置管理，成为基线的配置项是否经同行评审和SCCB批准，软件项目组对配置项的变更是否遵循了配置项的变更控制流程。检查配置管理员是否定期报告基线库状态，软件项目经理是否定期审核基线库。
3.5 机构过程定义
在这个KPA中，SQA必须检查SEPG组的以下几个方面：
1) 编写和维护机构标准软件过程和相关过程资源以及建立文档时是否遵循适当的标准；
2) 使用机构标准软件过程和相关过程资源时是否受控。
SQA每月审核机构标准软件过程和相关过程资源，检查文档变更是否符合变更流程。
3.6 同行评审
在这个KPA中，SQA必须检查软件项目组的以下几个方面：
1) 所计划的同行评审已被实施；
2) 同行评审负责人根据其职责接受过充分的培训；
3) 评审人员根据其职责接受过适当的培训或具有相关的经验；
4) 准备同行评审、实施同行评审和完成后继措施等过程得到遵循；
5) 同行评审的数据报告具有完整性、精确性和及时性。
在里程碑时，SQA根据软件开发计划检查计划的同行评审是否实施，通过检查评审记录，审核同行评审是否符合CMM规程。
3.7 综合软件管理
在这个KPA中，SQA必须检查软件项目组的以下几个方面：
1) 制定和修改项目定义的软件过程；
2) 项目的软件开发计划和软件风险管理计划的准备过程；
3) 依据项目定义的软件过程管理项目的过程；
4) 为机构的软件过程数据库收集和提供合适数据的过程；
5) 使用机构的软件过程数据库支持软件项目的计划、评价和跟踪过程。
SQA人员在软件项目组开始启动项目时指导软件项目经理制定项目定义的软件过程，里程碑时依
照项目定义的软件过程检查软件项目组管理项目的活动，每季度检查一次软件项目组是否按规程为机构软件过程数据库提供数据，里程碑时检查软件项目组的计划、评价和跟踪过程是否合理的使用了机构过程数据库。
3.8 软件产品工程
在这个KPA中，SQA必须检查SEPG组的以下几个方面：
1) 软件需求是否经过评审；
2) 每个软件工程任务的准备就绪和完成准则得到满足；
3) 软件产品符合规定的标准和需求；
4) 已完成所需的测试；
5) 依据书面计划和规程完成软件的系统测试和验收测试；
6) 测试满足软件测试计划中的验收标准；
7) 已圆满地完成测试并记录了测试结果；
8) 检测出的问题和缺陷以建立文档，并被跟踪和处理；
9) 通过软件需求、设计、代码和测试用例，对给定需求的跟踪得以实施；
10) 在软件产品提交给客户和最终用户前，依据软件基线和给定需求验证了用来管理和维护软件的文档。
SQA人员在里程碑时根据软件开发计划检查该里程碑所产生的软件工作产品是否符合有关规程。
3.9 培训大纲
在这个KPA中，SQA必须检查软件项目组的以下几个方面：
1) 制定和修改培训大纲的过程是否得到遵循；
2) 制定和修改培训课程的过程是否得到遵循；
3) 培训记录是否得以适当管理；
4) 指定要培训的成员是否完成了所需的培训；
5) 机构的培训计划是否得到遵循。
针对公司培训机构专门设立SQA人员，每月检查培训机构的相关文档，审核其活动是否符合有关
规程。
3.10 组间协调
在这个KPA中，SQA人员必须检查软件项目组的以下几个方面：
1) 用于识别协商和跟踪项目工程组间关键依赖关系的规程是否确定；
2) 组间问题的处理是否符合规程。
SQA人员检查工程计划中确定组间关键依赖关系的规程，通过检查业务裁决书和备忘录审核组间
问题的处理是否符合规程。
3.11 软件质量保证
SQA人员在参与制定软件开发计划的同时，制定该项目的SQA计划，制定完毕后由开发部经理、工程经理和软件项目经理评审。SQA人员根据计划进行SQA活动，当软件开发计划发生变更时，SQA计划作相应的变更。
SQA人员在对软件项目进行验证后，将结果填SQA检查报告，该报告至少应该包括以上KPA中所列的应该检查的方面，格式可如下表：
软件项目名称 XX医保 项目进度 概要设计阶段
软件项目经理 XXX 检查日期 2002-8-30
所属KPA 检查项 合格否 备注
　　　需求管理 给定需求交给软件项目组之前经过评审，确保需求没有问题； 合格 8月9日评审时，发现若干问题（见评审记录），当场解决。
当给定需求发生变更时，软件开发计划、工作产品和活动有没有进行相应的适当的修改；   暂无变动
由于给定需求更改引起了约定的更改，这些更改由没有经过相关小组协商。   暂无变动
软件配置管理 SCM组、SCCB、软件项目组是否遵循SCM的标准和规程； 合格 8月12日评审了软件配置管理计划，发现配置项不全，修改后于8月13日通过评审。
对软件基线有定期审核。   计划8月31日审核
　软件开发计划 软件估计和计划的活动是否进行； 合格 8月12日评审了软件开发计划，由于进度计划不够详细，没有通过评审，软件项目经理修正后，8月13日通过了再评审。
评审和形成项目约定的活动是否进行； 合格
制定软件开发计划的活动是否进行； 合格
用于制定软件开发计划的标准是否遵守； 合格
软件开发计划的内容是否完整。 合格
　　　软件项目跟踪和监督 评审和修改约定的活动是否进行；   暂无
修订软件开发计划的活动是否进行；   暂无
修订软件开发计划的内容是否完整；   暂无
跟踪软件项目的成本、进度计划、风险、技术和设计限制、功能和性能等有关活动是否进行； 合格 8月19日因软件项目经理出差，周例会取消，周例会和里程碑会议时对软件项目进行了跟踪
实施计划安排的评审技术和管理的活动是否进行。 合格 计划和工作产品都经过了评审
　　　同行评审 所计划的同行评审已被实施； 合格 8月26日对需求分析说明书进行了同行评审
同行评审负责人根据其职责接受过充分的培训； 合格
评审人员根据其职责接受过适当的培训或具有相关的经验； 合格
准备同行评审、实施同行评审和完成后继措施等过程得到遵循； 合格
同行评审的数据报告具有完整性、精确性和及时性。 合格
　　　　　综合软件管理 制定和修改项目定义的软件过程； 合格 8月11日参与制项目定义的软件过程，8月12日通过评审
项目的软件开发计划和软件风险管理计划的准备过程； 合格  
依据项目定义的软件过程管理项目的过程； 合格  
为机构的软件过程数据库收集和提供合适数据的过程； 合格 8月20日上报了测量数据
使用机构的软件过程数据库支持软件项目的计划、评价和跟踪过程。 合格 参见项目的软件开发计划
　　　　　　　　　软件产品工程 软件需求是否经过评审； 合格  
每个软件工程任务的准备就绪和完成准则得到满足； 合格  
软件产品符合规定的标准和需求；   暂未结束
已完成所需的测试；   暂未进行
依据书面计划和规程完成软件的系统测试和验收测试；   暂未进行
测试满足软件测试计划中的验收标准；   测试计划通过评审
已圆满地完成测试并记录了测试结果；   暂未进行
检测出的问题和缺陷已建立文档，并被跟踪和处理 合格 参见需求分析说明书的评审记录
通过软件需求、设计、代码和测试用例，对给定需求的跟踪得以实施； 合格 在需求分析说明书的同行评审中进行了跟踪
在软件产品提交给客户和最终用户前，依据软件基线和给定需求验证了用来管理和维护软件的文档。   暂未进行
如果上表中列出了软件项目不合格的方面，SQA必须填写一份问题解决报告，及时通报给软件项目经理，如果问题得不到解决，再将报告提交给上级管理部门，请求支援以解决问题。问题解决报告可如下表：
报告编号   上次报告编号  
问题负责人 　 软件项目经理 　
SQA人员 　 制表日期 　
计划完成日期 　 实际完成日期 　
问题描述：[描述发现的问题；问题可能产生的风险（可选）]            　
解决方法：[描述解决问题的具体方法和步骤]            　
问题负责人签字 　
SQA人员签字 　
软件项目经理签字 　
完成情况描述：                　

注：
1) 报告编号用来唯一标识问题解决报告。报告编号由项目名称、问题描述、问题序号三部分组成。（如：PowerHygeia-Inhosp-001）问题序号用来标识同一个问题的不同解决报告
2) 上次报告编号，是指问题上次未解决的报告编号。
SQA人员在进行质量保证活动的同时，要记录自己的工作量，并在每月或里程碑时进行统计分析，将结果填入SQA活动测量表，如下所示：
软件项目名称 　 软件项目编号 　
软件项目经理 　 SQA人员 　
项目阶段 工作量 审核次数 发现问题数 上报次数
计划 实际 计划 实际   
时间段（或里程碑） 　 　 　 　 　 　
。。。。。。 　 　 　 　 　 　
。。。。。。 　 　 　 　 　 　
。。。。。。 　 　 　 　 　 　
合计 　 　 　 　 　 　

　
4 结论
作为一名SQA人员，不仅要熟练掌握业务知识，而且要具有一定的业务技巧，灵活运用CMM的标准，才能将CMM标准贯彻落实到软件项目中去，从而逐步提高软件过程的成熟度。
参考书目
1. 卡纳基梅隆大学软件工程研究所 《能力成熟度模型（CMM）:软件过程改进指南》 刘孟仁等译 电子工业出版社 2001年7月

QA不好当 总觉得QA要“纵观全局”:D

很想去当QA呢,可惜机会还没到阿

QA需要了解很多很多，太多自知能力还无法达到，呵呵，先学习，再加入此队列中。 skyline提供了学习的知识点了

QA的工作很容易费力不讨好，两面都不讨好

这里的checklist很不错呀.CMM中QA工作能不能做细,做实,其实checklist是关键呀.

在大多数企业，QA肯定都是不好当的。 你不是创造者，是挑毛病的。经常耽误出货、影响利润。
如果公司老大不强力支持，就像后娘养的，

引用:

原帖由 阿曼 于 2006-9-21 11:16 发表
很想去当QA呢,可惜机会还没到阿

想当QA，的敢于吵架、善于吵架。

软件研发人员像糖水或蜜水，老版喝起来陶醉、舒服；
QA像茶水，喝起来苦涩，但能让人清醒。
但是一般都愿意甜甜蜜蜜，不愿苦涩

QA要说好当也好当,要说不好当也的确不好当.看自己工作的态度,看别人对你的理解程度,看领导对你的支持力度.呵呵

qa的工作一定要得到领导的支持，否则工作真是很难推进。领导要是管理出身还好说要是技术出身就很难了！