通用过程质量保证

人们常说质量管理要做到个性化、定制化，避免千篇一律，一成不变，但实际上，如果能掌握一套一成不变的东西作为范本，后续的开拓创新就可以在朽木上种出新的生命！

在软件过程中，什么最通用？“软件生命周期”最通用……

那么为了适配软件生命周期每个阶段的质量保证，我们就定义了通用过程质量保证活动。通用过程质量保证活动就是那么一套核心的范本，它能让你明白基本的质量保证内容。

众所周知，软件生命周期有六个阶段，分别是启动、需求、设计、编码、测试、运维，这六个阶段至少每个阶段都收纳了一种核心业务活动，所以为了应对这六种核心活动，我们也准备了六项质量保证活动，其中启动阶段有两项，分别是质量保证策划和定义例行检查，质量策划不再重复讲，且需求阶段和设计阶段可以合并，所以剩余聊聊五种内容。

这五种保证活动为了通用性，也只做质量工作简单四象限中的唯一项——检查审计，而且因为审计算是正式化检查，所以综合来说，通用过程质量保证活动是为了做好软件生命周期六个阶段的检查。

那么，首先我们进入第一个阶段。

一、启动阶段；

在这个阶段，质量人员需要定义清楚整个软件生产过程中，需要例行检查的活动有哪些？这个时候质量人员就需要思考，软件生命周期中，什么事情是几乎贯穿各个环节的呢？下面举几个例子……

1、日报、周报，质量人员要时长关注这些报告记录的内容是否完整、是否例行发出，内容中的三大项（进度、风险、问题）是否有进展？列出的检查checklist可以有：

1）进度与原计划里程碑或项目进度对比是否存在异常，若有异常，原因是什么，严不严重，要不要预警或上升汇报？

2）风险是否例行识别，已识别的风险现状如何了，有没刷新变化，潜在影响、风险规避措施有了吗，可否闭环？

3）现状有哪些问题，问题按优先级程度不同，进展情况分别怎样了，停留很久未解决的问题原因是什么，需不需要拉通、对接、协调资源或上升处理？

2、会议也是始终贯穿存在的活动，质量人员除了要经常跟随参与到会议中，还要检查会议是否聚焦主题、开会是否有成效，通过检查来保证会议开展的完整性，譬如会议的通知、纪要、时长、参与人、会后的事务闭环。

3、月结工作，按月的质量情况晾晒、总结、成员质量绩效情况等。

上面都是运作方面的例子，业务方面例行工作的检查如版本配置管理（SVN、Git等）、持续集成构建之类的活动是否健康开展。

从启动阶段，我们进入需求和设计阶段，因为在生产过程中，需求和设计往往会一起开展，所以合并起来讲一个质量保证活动。

二、需求&设计阶段；

需求活动中，我们重点关心需求管理有效性检查中的四类内容：需求澄清情况、需求跟踪管理情况、需求设计情况、需求检视情况。

1、需求澄清情况的检查，重点关注需求是否有唯一入口，是否有相应的澄清计划，是否提供颗粒度在10人天内的Story card，澄清过程是否讲清楚了背景、方案、应用场景，过程中提出的疑问是否记录并最终答疑，澄清内容是否有效记录？这里边，需求澄清质量的好坏需要明确一点，澄清内容后开发可以讲述大体的实现思路，测试可以讲述大体的测试思路，意味着澄清质量合格。

2、需求跟踪管理情况的检查；质量人员在检查的时候要重点关注需求跟踪矩阵或录入到系统管理需求的内容刷新情况，并与实际进展对齐印证，确保从需求到设计文档到代码到测试用例的责任人、输入/输出、时间都能随时双向可追溯。

3、需求设计情况是检查设计文档或原型；如基本信息、背景价值、设计描述、依赖关系、用户规格、业务流、数据流、原型界面、方案（表结构、模型、接口）描述、测试建议、功能验证用例、专项测试等，判断这几个部分的内容是否明确没有遗漏，如果有缺失，需要跟进团队给出合理的原因。

4、需求检视情况的检查；检视这块分两种，一种是针对需求澄清前后需求清单明细的检视，这个检视主要是确保需求清单完整、清晰、工作量可达成；还有一种是团队对需求方案、场景、用例、设计文档的检视。无论是哪种，质量人员都要通过检查来保证检视活动有效性，发现的问题要闭环。

在设计完成后，逐步有进入开发编码的内容，此时就得关注编码质量。

三、编码阶段

无论在瀑布模式还是敏捷迭代中，编码阶段保证代码质量是团队所有成员的集体意识，除了开发人员自身的自检、单元测试外，集体参与的代码QC也是保证代码质量的关键，但问题是，很多时候因为能力不足或没有流程规范，代码检视活动往往流于形式。

所以质量人员在此个阶段可以选择两种方式来保证代码质量，一种是代码抽检，如果质量人员本身不具备编程方面的能力，可以协调结对一名有经验的开发来抽检已经被QC过的代码，看看是否还有低级问题遗漏，以此评判QC活动开展的质量。

另一种是开展代码检视活动有效性审计，通过检查QC前后过程中的活动组织规范性、输出物情况、人员参与情况（编程专家占比）、自检情况、问题记录跟踪情况、最终问题闭环的情况、QCchecklist准备情况以及访谈员工对checklist熟悉的情况来评判代码QC活动开展的质量……

随着一些功能实现，转测试，此时就要保证生产过程中的控制环节——测试工作开展的好坏了。

四、测试阶段

除了测试策略、测试用例、自动化测试这些内容的检查外，测试的缺陷跟踪管理常常是质量人员入手检查的要点。此时检查测试人员提的缺陷单也是代价最小，最容易发现问题的好方式。

缺陷单的检查主要关注缺陷处理流程是否有序合理，确保缺陷是在开发修复后，经过审核ok了才回到测试手中，不能出现回归不通过的问题以及不能出现修改引入的问题，若出现了，则应该统计此类问题的数量，在积攒一定量后分多次，统一拉团队开小会，分析评审乃至回溯问题症结。

其次关注缺陷转需求的情况，提醒团队做好变更管理，检查转需求的数量，并保证团队完整记录清单。

最后就是检查严重缺陷和安全性缺陷修复的情况，若积压大量此类问题，需要预警，提前做好进度延期甚至无法顺利上线的预案。

走完了测试，最后就是上线环节。

五、上线阶段；

重点关注团队是否开展上线演练，演练的内容是否和以往实际上线的活动操作相类似，避免假演练或无效演练。

然后复查前面几个阶段检查发现的问题是否都已经得到解决，遗留的问题是否影响到上线。

再有就是检查需求清单中功能实现的情况，避免需求遗漏，此外检查缺陷遗留的情况，判断缺陷数量随日期或测试轮次收敛的情况，避免未修复的缺陷或大量潜在未发现缺陷遗留到生产环境。

以上就是通用过程质量保证的内容，它仅仅质量人员基础实践的内容范本。从一开始的质量保证策划，紧跟着定义例行检查活动，然后是需求管理有效性检查，接着是确保代码QC有效性，再之后是检查缺陷跟踪管理规范性，最后的上线检查……通用过程质量保证活动的内容也就这么少，需要检查的项也不多，事实上除了第一部分有给出checklist外，其余部分都没有检查表，所以质量人员务必要结合项目实践，自身去识别和积累质量保证活动检查的细项条目，这样才有针对性，才能真正掌握好通用过程质量保证的内容。