随着技术的飞速发展和市场竞争的加剧,软件质量已成为企业成功的关键因素。传统的质量管理方法已难以适应新时代的需求,全面质量管理(TQM)应运而生,它强调全员参与、持续改进和顾客满意。本指南将深入探讨全面质量管理的核心理念,为软件开发团队提供一套系统的质量管理优化策略。
本文首先阐述了全面质量管理的核心价值观,包括价值驱动、鼓励创新和全员负责。在此基础上,明确了各角色在质量管理中的职责,确保从需求分析到运维的全链条人员都能为质量负责。通过培养团队的责任感,实现高效率协同工作,我们旨在构建一个持续改进的质量管理体系。
进一步地,本文提出了标准化指导的原则和测试策略与实践。通过研发流程的标准化、质量目标和度量策略的标准化,以及测试左移、精益测试、测试右移等策略的实践,确保软件质量得到全面保障。同时,还强调了自动化支撑在质量管理中的重要性,通过引入自动化测试工具和流程管理工具,实现测试活动的全面覆盖和高效执行。
最后,文关注质量赋能,通过树立新时代软件质量价值观、推进全流程标准化、强化质量基础设施建设以及加强人员能力建设等措施,为团队注入质量意识和创新能力。我们相信,通过全面质量管理的实施和优化,软件开发团队将能够不断提升软件质量,为企业创造更大的价值。
一、质量管理核心价值观
价值驱动,鼓励创新,全员负责
1、价值驱动
维度 | 传统 | 业务价值驱动 |
需求的关注 | 功能需求 | 业务需求 |
计划与执行 | 过得最大的测试覆盖率 | 基于风险考虑在最优的时间内获得最大的覆盖率 |
应对缺陷 | 不做缺陷预防,而是响应式机制 | 分析历史数据和模式来精确预防缺陷 |
测试人员角度 | 测试 | 业务分析,质量分析 |
目标 | 高效发现缺陷 | 快速投发布上线 |
生产力 | 基于用例编写或执行的数量 | 分析历史数据和模式来精确预防缺陷 |
指标 | 面向项目的指标 | 面向业务的指标 |
有效性 | 实现测试的目标 | 通过健壮的测试实现业务目标 |
-
关注业务的需求,而不仅仅是功能需求;
-
以追求快速高质量的交付价值为目标,单纯的测试覆盖率和缺陷数量不再是考核的因素;
-
以预防缺陷为主,正确跟踪缺陷并进行深入分析是帮助缺陷预防的必要的手段;
-
不再简单的根据数量来考核生产力,可以从多个维度评估测试的成熟度,以驱动出持续改进的方案。
2、鼓励创新
-
缺陷分析:分析客观原因,不追责到人,鼓励创新尝试。
-
创新文化:宣扬试错文化,给予员工创新空间,持续改进软件开发流程和质量。
-
拥抱AI:利用人工智能技术提升软件质量
3、全员负责
-
质量定义:外部质量(用户体验)和内部质量(代码质量)并重。
-
质量内建:强调质量不是检测出来的,而是内建于每个开发环节。
-
团队责任:团队整体对质量负责,强调快速反馈、集中精力、信心和责任感。
二、各角色的职责
-
需求分析师
-
核心职责:负责业务需求的分析与细化,确保客户需求被准确、清晰地转化为可实施的功能点。
-
质量关注:确保需求分析的准确性和清晰度,促进团队对需求的一致理解。从用户旅程角度出发,验证产品价值,确保最终交付的产品能够满足用户需求。
-
-
开发人员(Dev)
-
核心职责:作为软件系统实现的核心力量,负责从需求理解到代码实现、测试覆盖率保障、持续集成、生产环境关注及运维支持的全过程。
-
质量关注:不仅关注功能的正确实现,更重视代码质量、系统性能和稳定性。通过高效开发,确保功能能够按时、高质量地交付给最终用户。
-
-
质量分析师(QA)
-
核心职责:作为软件质量的守护者,全程参与软件开发过程,从需求阶段到上线后的支持,确保质量保障策略的有效实施。
-
质量关注:制定并执行全面的测试计划,包括手动测试、自动化测试、探索式测试、跨功能测试和非功能测试等。及时反馈质量信息,识别业务风险和优先级,帮助团队优化业务价值。
-
-
架构师
-
核心职责:负责项目架构的设计与维护,确保系统架构的健康、可扩展性和稳定性。
-
质量关注:通过合理的架构设计,降低系统复杂度,提高系统的可维护性和可测试性。同时,与基础设施负责人合作,确保基础设施的稳定运行,为开发和运维工作提供有力支持。
-
-
项目经理(PM)
-
核心职责:负责团队的交付节奏管理、团队成员的工作状态监控以及客户满意度提升。
-
质量关注:通过有效的项目管理手段,确保项目按时、高质量地完成。同时,关注团队成员的工作状态,提供必要的支持和激励,提高团队整体的工作效率和满意度。同时,与客户保持密切沟通,确保项目成果符合客户需求和期望。
-
三、培养责任感的三把钥匙
1、动机:激发内在动力,勇于担当
在面对问题时,首要的是培养一种负责任的动机。这意味着,当挑战或错误出现时,我们应主动站出来,而非逃避或寻找借口。这种动机源于对工作的热爱、对团队的忠诚以及对个人成长的追求。
在软件开发领域,当发现缺陷时,我们应迅速采取行动,分析原因,制定解决方案,并采取措施防止类似问题再次发生。这种积极的应对态度不仅有助于提升软件质量,还能增强团队的凝聚力和信任感。
2、意识:强化责任观念,共筑质量长城
除了动机,对责任的意识同样重要。当问题出现时,我们应迅速调整心态,摒弃寻找借口和推卸责任的想法,转而专注于解决问题。作为团队的一员,我们都有责任为产品的质量贡献力量。
团队应强调整体质量意识,鼓励成员在每次代码变更时都要考虑潜在的质量风险,并主动采取措施预防。同时,当发现缺陷时,团队成员应共同协作,共同寻找解决方案,为提升产品质量贡献自己的力量。
3、面对:积极应对挑战,从失败中汲取力量
最后,以积极的心态面对问题是培养责任感的关键。我们应勇于承认错误,并从中学习。失败并不可怕,可怕的是无法从失败中汲取教训,导致同样的错误一再发生。
当我们说要为质量负责时,意味着无论遇到何种问题,我们都能保持冷静和积极的心态,深入分析问题的根源,并采取有效的措施进行改进。这种勇于面对挑战、不断学习和改进的精神是提升个人和团队责任感的关键所在。
四、实现高效率协同,保障质量管理
软件开发作为一项复杂的社会活动,涉及业务、开发、测试和运维等多个领域,这些领域之间的充分沟通与协作是实现项目成功的关键。高效的协同工作能够确保项目按时、高质量地完成,同时提升团队的整体效率和满意度。。
1、组织结构:
-
保持独立测试组:
-
目的:确保测试工作的独立性和专业性,提高测试质量和覆盖率。
-
实施:测试人员归属于测试组管理,但派驻到研发团队中,与开发人员紧密合作。
-
-
优化测试组与研发团队的关系:
-
派驻机制:测试人员不仅作为测试的执行者,还要作为研发团队的“质量顾问”,参与到需求分析、设计评审等环节,确保测试工作与研发工作无缝对接。
-
定期交流:组织定期的测试与研发交流会,分享测试经验、讨论测试策略,增强团队间的理解和信任。
-
2、沟通协作:
-
增加知识库:
-
目的:建立共享的知识库,方便团队成员查阅和学习,减少重复沟通和知识传递的成本。
-
内容:包括项目文档、技术资料、常见问题解答、测试案例等。
-
维护:指定专人负责知识库的更新和维护,确保信息的准确性和时效性。
-
-
优化沟通渠道:
-
即时通讯工具:利用即时通讯工具(如钉钉、企业微信等)建立团队沟通群,方便团队成员随时交流和协作。
-
定期会议:组织定期的项目会议,包括周会、月会等,汇报项目进展、讨论问题和解决方案。
-
面对面沟通:鼓励团队成员之间的面对面沟通,通过直接交流来增进理解和信任。
-
-
强化协作文化:
-
团队协作:倡导“一起解决问题”的协作文化,鼓励团队成员之间互相支持、互相学习。
-
目标一致:确保团队成员对项目目标有清晰的认识和共同的理解,形成合力推动项目进展。
-
五、标准化指导,构建质量管理体系
1、研发流程的标准化
在标准化的研发流程中,团队应持续监控各个环节的效率与效果,一旦发现瓶颈或不适应新团队现状的流程,应立即进行详细分析并采取相应的调整和改进措施。
-
持续改进机制:建立持续改进机制,如定期回顾会议,鼓励团队成员提出改进建议,并对这些建议进行评估和实施。
-
流程优化:在保持核心流程稳定的基础上,根据项目特点和团队变化,灵活调整细节流程,确保流程的高效性和适应性。
里程碑节点 | 交付件 | 描述 |
需求调研 | 需求调研文档 | 需求调研后的总结文档 |
方案设计 | 产品设计方案 | 产品设计方案:干系人拉齐系统共识,确定系统建设目标,范围;根据方案给客户报价及建设周期 |
产品设计方案评审结论 | 客户对设计方案的评审结论 | |
项目立项 | 项目可行性分析文档 | |
项目立项文档 | ||
需求分析 | 界面原型评审文档 | 客户评审过的原型文档 |
UI设计评审文档 | 客户评审过的设计文档 | |
需求规格说明书 | ||
系统研发 | 架构设计文档 | 系统涉及的技术论证及需要遵循的规则 |
数据库设计文档 | ||
版本转测文档 | ||
接口文档 | ||
系统测试 | 测试计划 | |
测试用例 | ||
质量报告 | ||
产品验证报告 | 产品验收后需出验收报告 | |
系统发布 | 客户验收表 | |
项目发布申请表 | ||
培训实施 | 用户手册 | |
培训实施文档 |
2、测试策略的标准化
针对不同的开发流程,需要有对应的组织级标准化测试策略。组织级测试策略是个统一的指导方向,不同的产品线和不同的项目团队也需要有自主调整的空间,以更好地定制化适配的策略。
2.1 指导性原则:团队为质量负责
(1)质量为核心,团队共担责任
-
质量内建原则:质量不是检测出来的,而是内建在每个开发环节中。团队应致力于通过质量内建(或质量内嵌)的方式,确保软件产品的内、外部质量。这包括自动化测试和手动测试的结合,以及跨功能测试(如安全、性能等)的全面考虑。
-
全面测试覆盖:自动化测试应从单元、组件到端到端等多个层次进行编写和执行,成为部署流水线的一部分。手动测试则关注需求验证、演示、可用性测试和探索式测试等,确保整个项目过程中的质量保障。
-
质量度量与反馈:从外部质量(用户反馈、问题数量)、内部质量(code review、静态代码质量检查)和内建质量(测试环境、生产环境缺陷,各环节反馈)三个维度来度量软件产品的质量。质量是快速反馈、精力集中、团队信心和责任感的体现。
(2)避免质量疏忽,全面关注细节
-
深入需求分析:确保需求分析过程充分且参与人员角色多样,以全面理解业务上下文和关键场景。
-
代码质量优先:在交付新特性的同时,关注代码质量,及时进行重构,避免技术债的累积。
-
充分测试覆盖:确保测试覆盖足够广泛,避免新增代码破坏已有功能。
-
系统可扩展性:在项目初期就考虑系统功能的可扩展性,避免随着业务发展出现性能瓶颈。
-
技术选型审慎:审慎选择技术,及时改进开发困难的问题,避免一错再错。
-
第三方组件评估:充分评估第三方组件的可靠性和性能,确保线上环境能够承载。
-
全局考虑:开发和测试都应考虑当前功能模块对整体系统的影响,避免局部优化导致全局问题。
-
跨功能需求关注:关注跨功能需求,如安全、性能等,确保系统整体质量。
-
线上环境了解与日志记录:充分了解线上环境,并记录足够的日志信息,以便快速定位和解决线上问题。
(3)持续优化与改进
-
自动化测试策略调整:随着项目业务和技术架构的演进,及时调整和改进自动化测试策略。
-
持续学习与提升:团队成员应持续学习新的测试技术和方法,提升测试能力和效率。
-
质量意识培养:加强团队成员的质量意识培养,确保每个人都对质量负责。
-
反馈循环建立:建立有效的反馈循环机制,及时收集和处理用户反馈,不断优化产品。
2.2 测试策略与实践
(1)测试左移
测试左移强调在软件开发生命周期的早期阶段就开始测试,特别是在需求分析阶段。这要求团队不仅要构建正确的产品,更要确保构建的是满足业务需求和市场期望的正确产品。测试左移通过以下方式实现:
-
需求验证:在需求分析阶段,与业务团队紧密合作,确保需求的准确性和可行性。
-
早期测试设计:基于需求文档,设计测试用例和测试策略,确保在开发过程中能够及时验证功能的正确性和稳定性。
-
持续集成与持续测试:将测试集成到开发流程中,通过自动化测试工具在代码提交时立即执行测试,确保问题能够早期发现并及时修复。
(2)精益测试
精益测试以业务价值为导向,力求以最小的成本交付高质量的软件。它强调有效覆盖和减少浪费,通过以下象限和分层来实现:
测试象限
-
Q1(面向技术、支持团队的测试):主要由开发人员执行,包括单元测试、集成测试等,验证单元模块的正确实施。
-
Q2(面向业务、支持团队的测试):由测试人员执行,包括功能测试、用户故事测试等,验证功能是否满足验收标准。
-
Q3(面向业务、评价产品的测试):由业务验收人员和测试人员共同执行,包括探索式测试、用户验收测试等,验证功能是否满足业务和终端用户需求。
-
Q4(面向技术、评价产品的测试):由测试人员执行,项目团队配合,包括性能测试、安全性测试等,验证产品是否符合非功能性要求。
测试分层
遵循测试金字塔原则,将测试分为单元测试、服务测试和UI测试三层,分别投入不同比例的精力,确保测试的效率和有效性。
(3)测试右移
测试右移是一种将测试活动延伸到生产环境下的质量保证策略。它充分利用生产环境的数据,包括日志、用户行为、用户反馈等,来分析和优化业务及开发流程中的开发和测试工作,旨在形成开发与生产环境信息分析的良性循环。
a直接在生产环境测试
虽然直接在生产环境进行测试存在风险,但蓝绿部署等技术提供了折衷方案。蓝绿部署通过运行两个相同的生产环境(蓝环境和绿环境)来减少停机时间和风险。在任一时刻,只有一个环境是活跃的,为所有生产流量提供服务。新版本先在闲置的绿环境中部署并进行测试,确保无误后,再进行蓝绿环境的切换。
b监控预警机制
虽然不能直接在生产环境进行测试,但可以通过监控手段获取所需信息,并对异常情况进行预警。
-
日志分析:
-
利用Splunk等工具分析生产环境和测试环境的错误日志,监控不同功能的性能,确保日志记录标准化。
-
通过Google Analytics等工具分析操作系统和浏览器使用情况,对比QA测试与用户真实行为的差异,提炼关键业务场景,优化测试覆盖。
-
-
性能监控:
-
监控系统性能变化趋势,及时发现并规避性能风险。
-
确保分析工具能够统计到所有关键功能的使用情况。
-
c用户反馈收集与分析
-
定期沟通会议:QA团队定期与运维和业务人员沟通,了解用户反馈,调整预生产环境的测试关注点。
-
运维人员培训:指导和协助运维人员利用鱼骨图等方法分析用户反馈,找出测试过程的薄弱环节,并据此改进测试策略。例如,针对频繁出现的浏览器或用户权限问题,加强相关测试覆盖。
-
生产环境Bug调查与跟踪:帮助重现和调查用户反馈的生产环境Bug,跟踪修复和验证过程。对于难以重现的问题,通过添加日志监控来收集和分析日志信息,找出问题根源。
-
业务需求梳理:在新功能开发过程中,QA团队积极参与业务人员与用户的沟通会议,收集第一手需求信息。对于不确定的功能需求,发布MVP版本供用户使用,并根据用户反馈梳理更具体的用户需求。
3、质量目标和度量策略标准化
3.1 质量目标清晰化
为了构建有效的组织级测试体系,我们需要设定清晰的质量目标。这些目标不仅应涵盖系统使用方面的质量要求,还应与业务目标紧密关联,确保以业务价值为驱动。
-
系统使用质量要求:确保软件的功能完整性、性能稳定性、安全性等满足既定标准。
-
业务目标关联:将质量目标与业务目标相结合,如提高用户满意度、降低故障率、提升业务效率等。
3.2 度量策略阶段化
针对软件生命周期的不同阶段,采取不同的度量策略,以确保度量的有效性和针对性。
-
迭代内度量:
-
需求阶段:关注需求质量、迭代划分的合理性,以及需求变更的频率和影响。
-
实现阶段:评估实现方案的有效性、复杂度,以及对需求的工作量预估的准确性。
-
测试阶段:分析缺陷趋势、缺陷分布和引入时机,以及测试覆盖率和测试效率。
-
上线和运维阶段:监测系统稳定性、响应时间、故障恢复速度等关键指标。
-
-
跨迭代度量:
-
0-1阶段:采用定性分析为主,关注需求质量、工作量预估的合理性,以及团队内部反馈。
-
迭代阶段:结合定性和定量分析,确保新增功能可用,已有功能稳定,并评估迭代效率和质量。
-
变更阶段:进行全面度量,包括功能变更的影响分析、风险控制等,确保变更的顺利进行。
-
维护阶段:持续优化已有度量指标,提高度量效率,减少资源浪费。
-
3.3 度量过程可视化
通过可视化的度量过程,可以更好地监控和评估团队的工作效果,及时调整度量策略。
-
度量维度与迭代:以迭代为横坐标,度量维度为纵坐标,展示每个迭代内的度量结果。
-
健康度指示:使用红绿灯等视觉元素表示度量结果的健康度,便于快速识别问题。
-
关键事件标注:在度量图上标注关键事件,如重大缺陷的发现与修复、团队结构的调整等,以便分析这些事件对度量结果的影响。
-
多迭代对比:通过对比多个迭代的度量结果,可以观察团队的工作趋势和变化,及时发现并解决问题。
-
横坐标是度量维度,纵坐标是迭代
-
红绿灯代表健康度,文字表示该度量点上的关键事件
-
每一行代表一次迭代内的所有度量及效果
-
多行结合看,可以观察多个迭代的度量变化,以及团队关键事件如何影响度量
3.4 全生命周期的定性分析
在软件开发的全生命周期中,定性分析作为一种快速评价和初步判断软件质量的方法,具有其独特的价值。以下是对访谈、根因分析、成熟度评估、回顾和复盘这五种定性分析方法
3.4.1 访谈
-
明确访谈目的:在访谈前,需要明确访谈的目的和期望获取的信息,这有助于设计更有针对性的问题。
-
设计结构化访谈提纲:访谈提纲应包含访谈目标、问题列表、访谈流程等,确保访谈过程有条理地进行。
-
内外结合:内部访谈关注团队成员的工作状态和心声,外部访谈则收集项目干系人和直接用户对软件质量的反馈。
-
注重倾听与反馈:在访谈过程中,要注重倾听被访者的意见和建议,并给予积极的反馈和回应。
3.4.2 根因分析
-
采用科学方法:如5Why法、鱼骨图等,这些方法有助于深入挖掘问题的根本原因。
-
解决问题为导向:根因分析应聚焦于解决问题,而非追责,避免引起团队成员的防御心理。
-
内外因并重:在寻找原因时,既要考虑内部因素,也要考虑外部因素,避免片面性。
-
关注可控因素:多关注可以改进的做事方式,少关注不可控的主观因素,提出切实可行的改进措施
例1:分析为什么让重大缺陷逃逸到生产环境,找到根因并改进,进行反向验证。
例2:分析为什么引入这个重大缺陷,找到根因并改进,进行反向验证。
在做根因分析的时候,首先要朝着解决问题的方向分析,举一个反例:“为什么生产环境遇到重大缺陷?因为开发/测试水平差。” 这就不是解决问题的角度,而是为了追责,容易引起团队成员的防御心理,造成分析失效。其次要同时寻找内因和外因,“都是我的错” 和 “都是你的错” 是在根因分析时需要避免的误区。最后要找可控的因素进行分析,多关注可以改进的做事方式,少关注不可控的主观因素。
3.4.3 成熟度评估
-
选择合适的评估模型:根据团队实际情况选择合适的成熟度评估模型,如CMMI、DevOps成熟度模型等。
-
定期评估与持续改进:定期进行成熟度评估,观察成熟度曲线的变化,制定持续改进计划。
-
避免横向比较:不同团队的上下文和限制条件不同,因此应避免无意义的横向比较。
-
持续观察与跟进:质量成熟度的提升需要一段时间的作用和磨合,因此改进之后的持续观察很有必要。
3.4.4 回顾
-
定期举行回顾会议:在关键节点后举行回顾会议,如迭代结束、季度末、大型版本发布后等。
-
总结与梳理:总结过去的闪光点、待改进的事项、疑惑和问题,并制定出下一阶段的改进项。
-
明确责任人与截止日期:改进项要落实到责任人和截止日期,确保改进措施得到有效执行。
3.4.5 复盘
-
设计复盘流程:复盘应包含问题收集、根因分析、改进措施制定等环节,确保复盘过程全面且深入。
-
综合运用多种方法:复盘可以综合运用访谈、根因分析、回顾等方法,提高复盘效果。
-
注重过程设计与引导:复盘过程需要精心设计和引导,确保参与人员能够积极参与并深入思考。
-
跟进与传递经验:复盘后要及时跟进改进措施的执行情况,并将复盘经验传递给团队成员和相关方,促进团队整体能力的提升。
3.5 全生命周期的定量分析
定量分析在软件开发的全生命周期中扮演着至关重要的角色,它能为团队效能的提升提供坚实的数据支撑,帮助我们精准识别浪费点,从而提出切实可行的改进措施。
3.5.1 交付目标层次的深入理解
在追求高质量交付的过程中,我们需要明确三个层次的交付目标:
-
第一层:项目交付
-
特点:以项目思维为主导,注重短期目标的达成,如按时完成项目并上线。
-
改进方向:虽然一过性的应付上线可能满足短期需求,但长期来看,应注重项目质量和可持续性。
-
-
第二层:价值交付
-
特点:以产品思维为主导,从业务价值出发,确保软件交付能够满足客户需求和业务目标。
-
改进方向:加强与业务团队的沟通,深入理解业务需求,确保软件交付能够为客户创造价值。
-
-
第三层:轻松高效的高质量价值交付
-
特点:既满足客户需求,又能为团队带来美好的体验,实现轻松高效的工作状态。
-
改进方向:优化工作流程,提升团队效能,确保高质量交付的同时,也能让团队成员享受工作的乐趣。
-
3.5.2 三维四类定量建模的优化
在定量建模过程中,我们需要从组织、实现、时间三个维度出发,结合四类指标(通过率、数值、效率、覆盖率)来构建度量体系。
-
通过率
-
优化点:除了构建通过率和缺陷逃逸率外,还可以引入代码审查通过率、测试用例通过率等指标,以全面评估代码质量和测试效果。
-
-
数值
-
优化点:除了千行代码缺陷数和发布回滚数外,还可以考虑引入缺陷密度(每千行代码中的缺陷数)、代码变更频率等指标,以更精细地度量代码质量和稳定性。
-
-
效率
-
优化点:除了需求研发时长和缺陷处理率外,还可以引入代码提交频率、构建速度、测试执行速度等指标,以评估团队的工作效率和响应速度。
-
-
覆盖率
-
优化点:除了需求覆盖率和测试覆盖率外,还可以考虑引入代码覆盖率(如语句覆盖率、分支覆盖率等)、安全测试覆盖率等指标,以确保软件在功能和安全方面的全面覆盖。
-
3.5.3 针对问题选择度量指标
六、规范化实施,确保质量管理落地
1、定义实践活动规范
参考下列博文:
DevOps业务价值流:以项目立项为起点
https://blog.csdn.net/heijunwei/article/details/143484116?spm=1001.2014.3001.5502
DevOps业务价值流:版本规划的最佳实践
https://blog.csdn.net/heijunwei/article/details/143565887?spm=1001.2014.3001.5502
DevOps业务价值流:需求设计最佳实践
https://blog.csdn.net/heijunwei/article/details/143575490?spm=1001.2014.3001.5502
DevOps业务价值流:架构设计最佳实践
https://blog.csdn.net/heijunwei/article/details/143590527?spm=1001.2014.3001.5502
Devops业务价值流:软件研发最佳实践
https://blog.csdn.net/heijunwei/article/details/143597396?spm=1001.2014.3001.5502
Devops业务价值流:敏捷测试最佳实践
https://blog.csdn.net/heijunwei/article/details/143614209?spm=1001.2014.3001.5502
Devops业务价值流:版本发布最佳实践
https://blog.csdn.net/heijunwei/article/details/143621793
2、沉淀新的优秀实践
-
分享与试用:鼓励团队分享新的实践活动,推荐大家试用,并收集反馈。
-
规范化与沉淀:经过多个团队验证的优秀实践,可以规范化并沉淀到组织级实践库中。
-
淘汰与剔除:对于不再适用的实践活动,及时进行淘汰和剔除,保持实践库的更新和优化。
3、定制化成熟度模型
3.1 质量内建
-
强调在软件开发的每个环节都融入质量意识,通过预防缺陷的产生来显著降低修复成本。
-
优化指标:除了关注各阶段发现bug的数量占比外,还可以引入缺陷密度(每千行代码中的缺陷数)、缺陷修复周期等指标,以更全面地评估质量内建的效果。
-
实践建议:在需求分析阶段就进行质量风险评估,制定针对性的预防措施;在编码阶段实施代码审查、静态分析等质量保障活动;在测试阶段采用多种测试策略,确保软件质量。
3.2 快速反馈
-
确保每个环节的任何变化都能迅速反馈给相关人员,以便基于最新信息做出明智的决策,从而降低风险。
-
优化措施:建立持续集成/持续部署(CI/CD)流程,实现自动化构建、测试和部署;采用符合测试金字塔结构的自动化测试体系,确保每一层的测试都能快速、准确地反馈问题。
-
实践建议:定期回顾测试反馈的准确性和及时性,不断优化测试策略和工具;加强与开发团队的沟通,确保问题得到及时解决。
3.3 全员参与
-
利用不同角色的领域知识和思维模式,提高测试质量和资源利用效率,实现价值最大化。
-
优化活动:除了bug大扫除、质量例会等常规活动外,还可以引入质量挑战赛、质量改进提案等激励机制,鼓励全员参与质量保障活动。
-
实践建议:建立跨部门的质量协作机制,确保各角色在质量保障过程中的有效配合;定期收集和分析全员参与质量保障活动的反馈,不断优化活动内容和形式。
3.4 测试作为资产
-
实现测试代码和产品构建代码的协同管理,促进测试资产的复用和持续优化。
-
优化策略:利用版本控制管理工具(如Git)将测试代码和产品构建代码一起管理,确保测试资产的版本一致性;建立测试资产库,方便不同项目间的复用和共享。
-
实践建议:定期评估测试资产的质量和复用价值,对不再适用的测试资产进行淘汰和更新;加强与业务团队的沟通,确保测试资产能够满足业务需求的变化。
3.5 更快的交付
-
将测试活动融入软件开发生命周期的每个环节,缩短产品上市时间,提高企业投资回报率。
-
优化路径:采用敏捷开发方法,实现快速迭代和交付;在测试阶段采用自动化测试、持续测试等策略,缩短测试周期和反馈时间。
-
实践建议:建立与业务目标紧密相连的交付计划,确保每个迭代都能交付有价值的功能;加强与客户的沟通,确保产品能够满足市场需求和期望。
3.6 清晰一致的测试视图
-
建立清晰、一致的测试视图,确保所有相关人员对测试活动有共同的理解和期望。
-
优化措施:制定统一的测试术语和流程规范;建立测试视图可视化工具,方便相关人员随时了解测试进度和结果。
-
实践建议:定期回顾和更新测试视图,确保其与业务需求的变化保持一致;加强与团队成员的沟通,确保测试视图得到准确理解和执行。
3.7 优化业务价值
-
基于业务优先级和风险进行测试策略调整,确保测试活动能够最大化地支持业务目标的实现。
-
优化方向:采用基于风险的测试方法,根据业务优先级和需求变更情况动态调整测试计划;在生产环境下进行质量监控和数据分析,为业务优化提供有力支持。
-
实践建议:建立与业务团队紧密合作的机制,确保测试活动能够紧密围绕业务需求展开;定期评估测试活动对业务价值的贡献度,不断优化测试策略和方法。
4、定期治理与持续改进
-
强化培训与意识提升:加强对团队成员的培训和教育,提高大家对质量保障重要性的认识和理解。
-
建立激励机制:建立质量保障相关的激励机制,鼓励团队成员积极参与质量保障活动,提高工作积极性和质量意识。
-
加强跨部门协作:加强跨部门之间的沟通与协作,确保需求、开发、测试、运维等环节之间的顺畅衔接和高效配合。
-
持续跟踪与反馈:建立持续跟踪和反馈机制,及时发现并处理质量问题,确保产品质量的持续提升和优化。
七、自动化支撑,提升质量管理效率
-
流程管理:全生命周期的软件交付流程,通常需要有流水线的支撑--devops
-
测试框架:各种自动化测试框架,以及与持续集成流水线的关联--MeterSphere
-
数据分析:可视化各种数据及其分析结果,包括日志信息和度量指标数据等--ELP、Google Analysis
-
监控预警:实时监控团队和产品状态,对质量风险和严重缺陷进行智能预测和告警 --Zabbix
软件流程管理系统
pingcode,飞书微表格 等
测试工具 / 框架
Selenium IDE,Postman,JMeter、JUnit,REST ,MeterSphere 等
测试管理系统
TestLink,Cucumber Studio 等。
代码质量工具
通义灵码、checkStyle、findbug、sonar、阿里编码规范
代码管理系统
比如 Git,Gitlab 等
CI/CD
Jenkins,Gitlab,Sonar Qube,docker,k8s,harbor、等
安全相关工具与系统
Fortify,Metasploit,Snort,Kali Linux 等
六、质量赋能,推动质量管理持续优化
1、树立新时代软件质量价值观与组织文化
-
深化质量意识:在新时代背景下,不仅要强调软件的功能性质量,还要关注其性能、安全、可用性等非功能性质量,以及用户体验和业务价值。
-
全员参与与责任:推动多角色深度融合,确保从需求分析、设计、开发、测试到运维的全链条人员都能为质量负责,形成全员关注质量的良好氛围。
-
价值导向:将质量视为交付价值的重要组成部分,通过高质量的产品和服务提升客户满意度,增强企业竞争力。
2、推进全流程标准化与质量成本降低
-
分阶段实施:采取分步走的策略,先定义核心流程的标准,再逐步扩展至整个软件开发生命周期。
-
实践验证与推广:通过试点项目验证标准的可行性和有效性,逐步推广至整个组织,形成组织级标准。
-
质量门禁与持续改进:利用工具支撑设置质量门禁,确保标准得到有效执行。同时,建立持续改进机制,根据反馈和评估结果不断优化策略标准和实践规范。
3、强化质量基础设施建设与自动化规模扩大
-
测试体系完善:加强测试自动化和流程自动化的基础设施建设,确保测试活动的全面覆盖和高效执行。
-
工具选型与集成:选择适合组织需求的自动化测试工具和流程管理工具,并实现它们的集成和协同工作。
-
数据驱动决策:利用自动化测试产生的数据进行分析和决策,持续优化测试策略和流程。
4、加强人员能力建设与学习型文化营造
-
组织级人才培养:制定针对不同角色的能力模型和提升路径,通过培训、实践、导师制等方式有计划地提升人员能力。
-
社区建设与知识共享:鼓励社区建设,促进知识共享和交流,营造学习型文化氛围。可以建立内部论坛、知识库、技术分享会等平台,方便员工自主学习和提升。
-
激励机制与职业发展:建立与质量相关的激励机制,如质量奖、优秀测试案例评选等,激发员工参与质量保障活动的积极性。同时,为员工提供清晰的职业发展路径和晋升机会,鼓励他们在质量领域不断深耕和发展。
暂时无法在飞书文档外展示此内容