软件研发质量管理体系建设怎么做｜践行者第24期

什么是软件研发质量管理体系？为什么建设软件研发质量管理体系如此重要？软件研发质量管理体系建设有哪些步骤？

本期践行者邀请到了参与《软件研发质量管理体系建设白皮书》创作的陈磊老师、宋涛老师以及陈晓鹏老师，一起聊聊“软件研发质量体系建设”该如何做。

一、《软件研发质量管理体系建设白皮书》

2023年10月25日，《软件研发质量管理体系建设白皮书》正式对外发布！关于白皮书，那些我们想问的问题都在这里啦：

Q1：为什么要建设质量管理体系？它起了什么作用？

宋涛老师：
首先，产品质量不仅仅是通过测试来保障，而应从需求、产品设计和编码过程等各个阶段着手。因此，质量管理应该从设计端开始，一直到测试、交付阶段。通过这些方面，我们保证了一个产品或版本的质量，那如何保证持续交付的产品和软件版本的高质量呢？这就要引入质量管理体系的概念：质量管理体系不仅关注Bug的数量，还关注功能性、安全性、兼容性、可用性和可移植性等多个维度。同时，质量管理体系还需要考虑资源配置、公司管理结构以及项目管理等各方面的因素。所以，我们也需要从公司层面系统化地构建质量管理体系，创造能够构建质量管理体系的土壤，来确保稳定、一致、高质量的产品交付。

陈晓鹏老师：
质量和测试其实不在一个维度：从定义上讲，质量就是满足客户/用户需求。大家也会混淆QA跟QC的概念：根据我的经验，QC（Quality Control）其实和测试差不多是对应的。QA（Quality Assurance）源于CMMI要求的一个质量保障角色，它主要确保研发的整体流程满足CMMI的一些要求。也就是说，QA主要关注流程层面，确保研发流程符合相关标准要求；而QC主要关注产品层面，确保产品功能满足需求。保证质量需要同时关注产品和流程两个方面，即验证和校验，确保我们做的事情是正确的，做的过程也是正确的。

陈磊老师：

当我们谈论质量时，所有人都会想到什么？标准和质量特性。现在我们都知道质量层次模型中的八个质量特性，那怎样保证这八大特性呢？很多人会认为是通过测试来实现，但实际上并不全是测试。我记得当初我的老师教我这门课时，这门课的方法被称为测试和评估，它们是两种方法，测试与评估都是其中的一种手段。现在，测试的手段更加丰富，实践速度更快，所以测试被更广泛地应用。

质量管理不仅是说我们应该如何工作、做什么样的工作，而更应该有一套方法，从不同方面解决问题，以便更快、更好地保障产品的内在质量特性，交付一个优质的产品。质量管理不是虚无的，也不是仅仅写几个流程文档或做些测试就可以的。它是一个立体的管理体系，包含了组织级的管理方法、实践落地以及相应的结果要求，也包括了实践过程中每一步的约束和内容。

Q2：《软件研发质量管理体系建设白皮书》的意义何在？

陈磊老师：
近几年，国家提出质量建设的纲要，《软件研发质量管理体系建设》白皮书特别切合实际，为软件行业的质量管理提供了一个指导。设定质量目标后怎么建设质量体系、怎么落地质量保障，规划如何做、如何在组织内部落地……这些在书中都有涉及，每一步都可以详细学习。虽然白皮书已经发布了，但我们仍会不断更新迭代，最后成为软件行业集百家所长的质量管理白皮书。

宋涛老师：
大家处于不同的行业，对质量测试、QA、QC、测试的概念都存在混淆的地方，我们希望通过白皮书将这些概念向大家重新澄清一下。举个例子，在汽车行业，很多传统汽车制造更偏向硬件，大家对于将互联网的软件思维引入汽车行业，软件如何管理、汽车行业里的软件质量体系如何做等方面与传统方法存在着差异，白皮书虽然更偏向于互联网软件行业，但对汽车行业而言，很多内容是通用的，可以借鉴的。

陈晓鹏老师：
对我个人而言，《软件研发质量管理体系建设》白皮书是一个里程碑。我们经过不断讨论、优化、更新、迭代，最终呈现出来的1.0版本正是我心中所期望、所想要达到的程度。随着白皮书的发布后，我们可能会收到反馈，我们会不断更新优化白皮书，让它能够成为对于整个业界来说相对知名的白皮书体系。

Q3：质量管理体系和QA、QC之间的关系是什么？

质量管理不能简单地说某个方面包含了另一个方面。当涉及到质量管理时，我们通常指的是质量管理的整体框架。这个框架涵盖了从客户那里获取需求，再到交付给客户的价值。整个过程还包括了组织团队之间的协作，从底层的人员到管理团队的角色，以及团队培养和文化建设。此外，还涉及到实际的工作方法、记录要求、检测手段和评估内容，这些都是一整套的约束和要求。因此，质量管理涉及到各种不同类型的人员，其中包括QA方面的小伙伴，他们负责约束整个过程，按照质量管理体系的要求进行实施。

需要注意的是，质量管理涵盖了与质量相关的所有人，包括生产工程师、开发工程师等直接影响产品质量的人员。这些人员也受到QC和QA的约束。QC会去落地执行所有的测试过程，专注于内部的实践方法和质量特性的验证。在这个过程中，如果需要改进，那QA的角色可以更好地保障实施改进方法，纠正遗漏或流程缺陷。

综上所述，QC和QA之间并不是包含关系，质量管理体系也不是凌驾于所有工作和方法论之上，它们是相互交织、相互成全的关系。

总之，《软件研发质量管理体系建设白皮书》从应用落地的角度，给大家呈现了质量管理体系搭建的全过程，大家可以点击下载《软件研发质量管理体系建设白皮书》，查看详细内容~

三、直播实录

Q1：软件质量管理的北极星指标是什么？

宋涛老师：
在质量管理的实操过程中，北极星指标可能不是单一指标，它可能是由多个指标构成的。我们要关注的最核心的是产品质量，即交付具备高质量的产品给到客户，那北极星指标就可能是Bug解决率、产品功能的完整性等等。

Q2：项目交付比较急，如何保证质量?

这是一个普遍存在的问题。首先，我们在进行估算时必须认真对待问题，对我们即将开发的产品要有全面的了解，特别是对于技术难点要进行详细的研究。我曾经参与的一个项目因为估算不够充分而导致时间紧迫。预计的开发周期本应为一个月，但实际上最终开发完成花费了差不多两个月的时间，比预计时间增加了一倍。这给我留下了深刻的教训：项目初期没有进行充分地估算，且对于一些难点需求的理解不够深入。客户提供的需求可能很简单，但实际上在实施过程中，一两句话的需求里面包含很多小点，然后每个小点实现起来，会花很多的工作量。所以如果要去解决这个问题，需要从源头做起，即在进行估算时必须充分了解需求。如果没有充分的了解，我们宁愿不启动项目，也不要在项目的后期延期。

第二点，我认为在测试过程中，更多地采用自动化方式会是一个解决方案。例如，在进行自动化测试时，可以制定一些策略。可以先进行API的自动化测试，然后再进行UI的自动化测试。如果时间充足，可以同时进行API和UI的自动化测试。

第三点，现在许多企业都有自己的CI/CD流水线，可以借助CI/CD的能力来加快开发流程，减少交付时间。这是我能想到的一些相对比较能够实现的一些方法。

Q3：如何处理TO B的项目每天有紧急需求，QA基本来不及写测试用例，开发也没有时间写单元测试的情况？

陈磊老师：

这个问题让我想到《凤凰项目》这本书，除了写代码，其他的时间都没有，需求也不好。因为ToB大多数要满足甲方的需求，所以我觉得短期就是以保障交付为主。

陈晓鹏老师：
其实在测试里面，哪怕是手工测试，有一种方式就是探索测试。它的原理是这个要求并非要写非常详尽的测试用例，所以它会更加地灵活，跟敏捷的一些思维或者敏捷理念是差不多的。也不需要写很多测试用例，但是更多地瞄准产品上面存在的风险，然后不断地支持，我觉得这是一个考虑的方向。

Q4：质量管理体系可以在不同公司、行业、产品形态间进行复用吗？

宋涛老师：
在不同公司（如零售公司、软件开发公司、制造公司）、行业（如电子制造、石油化工等）以及不同的开发形态，质量管理体系会有所不同。整体上来讲，质量管理体系可以从两方面来看：

第一，公司的组织文化和管理层的作用层面，主要涉及：

管理层对质量的态度；
如何进行质量度量；
通过PDCA（Plan-Do-Check-Act）模型，持续改善质量管理体系。

在这方面，不同公司、行业差异不会太大。比如领导层对质量体系、流程体系的持续改进要求基本上是相似的。

第二，这个也是白皮书中描述的质量管理体系的另一个重要方面，即企业在客户价值创造方面的作用。就软件行业而言，从客户需求到最终软件产品的上线交付，这是一个价值创造的过程，也是企业盈利的重要环节。在这方面，不同的公司和行业可能存在差异，软件行业基本上可以复用相似的方法和实践。化工产品或其他行业与纯软件行业是不同的。

有一点要注意，不同公司由于组织架构的不同，其流程实施过程可能会有所不同，因此不能盲目地照搬。以价值创造流程为例，目前国内最著名的是IPD的端到端产品研发过程。但是它不能完全照搬到各个公司，我们必须进行定制化、适配工作。

对于探索研究和方案原型设计方面，从整体的体系角度来看，前面所描述的方法是适用的，但在具体的探索研究和方案原型设计过程实施方面，在不同的公司和产品中可能会有不同做法。因为不同的行业中存在着更好的实践经验，我们可以借鉴和学习。

Q5：探索性研究与方案原型，这种类型的项目适用吗？

适用的。区别是工程开发的价值创造流程与探索性研究或者方案原型在具体流程步骤、质量目标管控会有所不同。

Q6：质量体系和研发过程的关联关系怎么理解，比如怎样进行5年规划？上线运维是否可以融入整个质量体系？

宋涛老师：
研发过程属于质量管理体系中的重要部分，是企业对客户价值创造的过程。它是质量管理体系里不可分割的一部分。而上线运维作为企业研发活动的重要一环，应该而且也有必要融入质量管理体系的。
关于质量管理体系的5年规划，实际反映的是管理体系建设的过程。建议参考白皮书，分析目前问题及现状，根据企业战略和业务需求，分步实施质量管理体系的规划。当然，规划可以是5年，也可以是3年。具体实施的步骤，建议：
• 从企业价值流，即核心研发过程做起，逐步扩展到其它支持域的活动，如供应商管理、采购管理等等；
• 从实施的场景来看，建议先从项目实施，再逐步扩展到组织层面。

Q7：我们创建了质量体系，但还是会遇到开发过程中由于时间关系无法完成的情况，怎么办？

宋涛老师：

质量体系建设要杜绝做成两张皮的情况，就像把一堆文档放在那，就说质量管理体系有了。这位小伙伴的问题本质是质量管理体系没有真正建立。我们要先问管理层对这个事的重视程度如何？另外还要给予全面的资源支持。

其次，我们要讲如何让流程持续地改进，更好地适应业务现状。因为很多做质量的小伙伴，觉得流程写的这个样，必须严格执行。我们应该抓住流程与质量管理的第一性原理，去和实际业务做适应，而不是拿着教条的流程文档讲。

陈晓鹏老师：
我补充两小点，第一点是质量体系应该慢慢融进到整个研发体系中，不是说将质量体系创建出一个文档就OK了；第二点是质量管理最好的方式，是融入到整个研发过程的环节中。比如在流水线上做质量门禁，要求单元测试的覆盖率达到60%等等。

Q8：有没有现成的软件系统？

目前了解到的是没有这种大而全的软件系统。但在具体的某个研发过程中存在数字化的手段，如一些项目管理工具，如CI/CD、DevOps的发布工具链等。

Q9：车企行业软件质量保障体系和纯软件开发企业都有哪些共通性？

宋涛老师：

这之间确实存在共通性。只要企业过了ISO9001等质量管理体系，就会存在许多共性。这主要体现在管理层对整体质量的要求、公司的质量文化方面、持续改进的文化等。

从软件本身价值创造来讲，车企行业的软件开发和纯软件的开发其实还是有较大的区别：车企的软件开发主要是嵌入式软件，而互联网软件开发多为基于云端的纯软件开发。这两种开发方式在约束条件、硬件要求、开发周期、软硬件的配合方式等方面存在差异。尽管这两者都被称为质量管理体系，但在实际应用中，会存在不一致之处。

Q10：软件研发管理体系建设已经有ISO9001、CMMI等，本白皮书的初衷和定位是什么？

东伟老师：
白皮书并非标准模型，也不是标准模型的同类，更类似于一个实践落地的行动指南，帮助大家实现落地应用。因此，白皮书的重点在于阐述具体操作方式（how），旨在帮助大家有效实施并满足CMMI等相关要求。而ISO 9001和CMMI等则是定义了要达到的标准（what），可以视为考试大纲。

因此，我们的目标是为质量管理领域的从业人员提供帮助，如质量总监、研究人员和学生等。我们在白皮书的前言部分明确描述了面向群体以及白皮书的作用。

Q11：本白皮书有哪些点可以用于完善已有的软件研发管理体系呢？与已有的标准模型的差异？

陈磊老师：
我们不需要逐章照抄白皮书，我们可以从白皮书中借鉴一些内容来完善某个环节或质量保障体系的某些部分。这些内容相当于一种底层逻辑，在环境变量下会有变化并不是万金油，白皮书并不是在每个组织或团队都能平安落地的，这需要相互融合成一个完全契合的方法论。

在现有的体系下，我们还要以更适合的方式为主，白皮书并不是一个绝对值。白皮书与ISO9001、CMMI的差异是什么？在标准管理体系上，我们学习了其组织结构，融入了实践中的优秀案例，并添加了一些具体措施给大家参考学习。二者差异不是在模块上，而是在层次上的，ISO9001、CMMI强调目标与愿景，白皮书更强调如何做。

Q12：因客户需求变更影响，导致后期着急上线而没时间测试怎么办？

陈磊老师：
这个问题在质量管理和测试领域经常遇到，几乎所有从事这方面工作的人都会碰到类似的情况。哪怕现在，我遇到这种情况仍然会头疼。我们返工的确会带来一些浪费，这是不可避免的。需要让客户和业务方意识到这一点，因为他们的需求在初期定义不准确，才需要后期进行变更。这实际上增加了团队的成本，这些成本最终需要由客户来承担，这是无法改变的。如果客户确实提出了一些需求，又要求进行改变，尤其他们是出资方，那么很难与他们进行博弈。

从测试的交付流程看，很多人遇到这种情况会为了着急上线而放弃测试。一旦出现问题，无论有多少理由，责任都会归咎于测试团队。如果这是一个一次性交付的产品，测试工程师要尽量在需求阶段就参与，将一些测试用例的内容融入需求中。尽管需求会发生变动，但可以了解到变动后的需求，其中包含了测试思维方式和测试可能遇到的问题，这会大大减少在上线时遗漏缺陷的可能性。

客户明确所有成本是由客户自身承担是非常重要的。在某些必须上线的紧急情况，双方需要达成一致：上线后的所有风险需要客户和团队共同面对。所以，甲方的要求有时候真的难以抗衡，但我们仍要尽力做到最大程度的测试和保障。

虽然这种做法不是完全正确，但在特定条件下，我们必须权衡相关方，保证最大的价值。“带病上线”不一定是最糟糕的情况，有时候客户认为团队不交付会认为团队不合作，就不再签订合同，这可能才是最大的损失。

无论项目多么紧急，我们之前建立的质量保障和测试资产都会发挥作用，以最大程度地保证所有交付物的质量。

从团队的质量管理和质量建设上看，出现问题的原因往往是与客户沟通不清楚。我们在需求质量部分需要多花一些功夫，才能在需求走入制品前，深挖到现在的需求与客户需求不一致。我们所说的最终极的测试左移是指：在需求提出时，测试团队就会知道这个需求与客户期望不符。但这确实很难实现。

这也说明了：在需求阶段将一些质量保障的思维灌输到需求中，对后续工作有很大的帮助和增益。因此，如果遇见这种情况，我们应该先解决团队中关键的问题，最大限度地利用现有资产，特别是那些能保障交付质量的特殊资产。实际上，有时候我们也会面临无法逾越的困境，因为有些事情确实是力所不能及的。

Q13：不写测试用例如何确定覆盖产品设计的需求？

宋涛老师：
从严格意义上看，这涉及到整个公司质量管理体系的成熟度问题。而其中隐含的是如何更好地衡量产品质量是否符合标准。实际上，这涉及到组织思维和数据度量的问题。数据度量可以通过多个维度进行，比如测试用例等等。在这种情况下，测试用例的编写有多种方法。我有以下建议：
• 大家至少为每个测试用例提供一个明确的标题，以便大家能够大致了解测试内容；
• 我们应该逐步进行，而不是一开始就要求所有事情做到完美；
• 在目前国内的软件环境中，我们需要采用一些更加适应性的持续改进的方法，对项目流程进行微调。

Q14：我们能避开重构？一套架构的生命周期有多长？

陈磊老师：
重构是避不开的话题。马丁·福勒（Martin Fowler）说：“今天写的每一行代码都是明天的遗留系统。”

宋涛老师：
重构话题是避不开的，与第二个问题是相关的。一套架构生命周期是没定数的，因为架构一定是变动的。架构设计会从多个维度考虑，如架构的生命周期、全生命周期的成本等，不同产品与行业的架构生命周期各不相同，这很难给出一个确定的答案。一旦架构不合适，那一定要重构，所以重构是避不开的。不管有没有质量管理体系，你都无法保证架构是一成不变的、不需要重构的。

陈晓鹏老师：
重构是演进的，而架构是演进的架构。

Q15：度量元需要与绩效关联吗？

宋涛老师：
这两个重要的概念存在混淆。绩效（key performance indicator）与钱相关，而度量是一个更广泛的概念。所以，一些重要的具备北极星性质的指标可能要与绩效关联，但大量的指标未必一定要与绩效关联。在实施过程中需要小伙伴们斟酌，真正核心的、与公司长期质量目标和质量策略一致的、与公司整体业务目标框架一致的指标，这肯定与绩效挂钩。但有些为了衡量整体进度或过程的、为了确保最后质量满足要求的指标，这些未必与绩效相关联。

陈晓鹏老师：
第一点，我认为度量应该是有奖有罚的。这并不只是不达标就扣绩效，还要做得好有奖励，这样大家的接受度会比较高。
第二点，如果个人的绩效难以实施，还可以考虑采用团队绩效，这只是其中一个可以选择的方式。

Q16：如何选择度量指标？

度量指标的选择可以看《软件研发质量管理体系建设白皮书》的第三章制定质量政策和质量目标。在具体的实践过程中，度量指标的选择可以考虑以下几个方面：
• 与企业的战略目标或项目/产品的最终成功的链接性；
• 度量的purpose - 考核 vs. 寻求改进机会；
• 度量指标是否容易获取，准确获取度量数据，指标数据能够及时反映现状；
• 度量指标是否有说服力，能够产生相应的行动；

• 指标最好要简单易懂，避免指标过多或者过于复杂的复合指标。

Q17：如何平衡公司内部的敏捷质量管理方式与客户传统体系要求，如大量文档、形式化评审等？

实际上，无论是敏捷方法还是传统体系要求，第一性原理都是为客户提供高质量且有价值的产品或服务。在这个共同目标的指引下，项目上的一些活动需要具备灵活性，根据项目的实际情况进行调整。具体而言：

文档输出方面：我们需要弄清楚文档的目的，是“为了满足客户需要”“法规要求”“内部存档”还是为“后期产品维护提供基础”？针对不同的目的，我们可以对文档的要求进行适当裁剪，并在迭代完成前完成文档工作。当然，我们也不能因为采用敏捷方法而完全放弃文档编写，这实际上是对敏捷方法的误读。
评审方面：对于形式化的评审，类似文档管控一样，我们需要因地制宜地分析，并进行适当的裁剪。比如说，代码通过pair programming的实践，那就未必一定要让同学重新来一遍类似Fagan Code Inspection 一样的代码评审。

Q18：测试和QA没有问题，但上线后出现测试问题，这怎么办？

零缺陷之父菲利普·克劳斯比（Philip Crosby）曾提过零缺陷的三不心态之一是“不害怕错误”。从软件开发的实践来看，没有任何一家公司能够确保产品发布后没有任何问题。因此，“不害怕错误”的关键在于出现问题后，我们需要深刻分析问题产生的根源和漏测的原因，从而避免类似问题再次发生。这种行动实际上是质量管理体系中倡导的“持续改进”文化。另外，我们还需要注意的是，根因分析后的行动项不应仅仅是增加一个又一个流程，而需要用创新的方法和技术手段来预防问题。

三、送大家一句话

宋涛老师：
质量一定是每一个人的责任，而不仅仅是质量管理部门的责任。因为很多小伙伴问质量管理体系没法落地开发或测试没时间测试的问题，这其实是需要开发、架构开发、测试相互合作的。每个人都要把质量当作自己的责任来看待。

陈晓鹏老师：
质量应该融入我们研发过程的每一个环节。如果将质量放入每个环节中，就不会增加研发部门的额外负担。

陈磊老师：
质量是团队的质量，质量管理体系是组织级的质量管理体系。欢迎大家参考《软件研发质量管理体系建设》白皮书，希望它成为大家组织级管理体系的一部分。