TMMi测试成熟度模型.概念总结
TMMi(Test Maturity Model Integration测试成熟度模型集成)是由TMMi基金会开发的一个非商业化的、独立于组织的测试成熟度模型,它是与国际标准相一致的、由业务驱动(目标驱动)的。其是测试过程改进的详细模型,借鉴了TMM、CMM、CMMI、Gelperin&Hetzel过程演进模型、IEEE829、ISO9126、ISTQB等国际成熟标准体系。.........
TMMi(Test Maturity Model Integration测试成熟度模型集成)是由TMMi基金会开发的一个非商业化的、独立于组织的测试成熟度模型,它是与国际标准相一致的、由业务驱动(目标驱动)的。其是测试过程改进的详细模型,借鉴了TMM、CMM、CMMI、Gelperin&Hetzel过程演进模型、IEEE829、ISO9126、ISTQB等国际成熟标准体系。
TMMi为测试过程改进提供了指南和参考框架,以解决测试经理、测试人员和软件质量专家关注的一些问题。TMMi属于阶段型改进模型,它包括阶段或级别,组织可以通过它们使测试过程从临时的和未管理的状态进化为已管理、已定义、已测量和优化的状态。在TMMi中有5个级别,规定了成熟度级别和测试过程改进的路径。每个级别都有一组过程域,组织需要实施这些过程域来达到对应的成熟度级别。
1. TMMI框架
TMMi,英文全称是“Test Maturity Model Integration”——“测试成熟度模型集成”,是由TMMi基金会开发的一个非商业化的、独立于组织的测试成熟度模型,用来评估一个组织测试管理和实践的成熟度。
首先,TMMi是一个团体标准,由惠普中国最早引入国内,是面向企业的认证。其次,TMMi在软件生命周期中,是专属于测试领域的认证,如下图所示。
TMMi标准5级的划分
TMMi是测试过程改进的详细模型,遵循了在 IT 行业具有广泛支持的过程改进模型——能力成熟度模型集成(CMMI),将组织的测试成熟度分为五个级别,分别为“1级-初始级”、“2级-已管理”、“3级-已定义”、“4级-已策略”、“5级-优化”,共包括16个过程域。不同级别对应的不同的过程域,以此来区分组织的测试能力成熟度。
TMMI的16个过程域5+5+3+3:
1级:关键字:混乱 | 测试过程是混乱,不明确的过程,组织里没有稳定的测试过程,依赖于组织中人员的能力和英雄主义。 |
2级:关键字:有序 | 测试是多级别的:有组件、集成、系统和验收测试级别,具有测试策略和计划,测试被监督和控制,以确保它是按照计划来执行。包含的过程域: |
3级:关键字:组织级、非功能、评审, | 基础是组织的标准测试过程集,被明确定义并随着时间的推移而改进。 拥有独立的测试团队,并且有特定的测试培训方案,测试被视为专门的职业。实施了正式的评审程序,测试设计和测试技术扩大到包括非功能测试。 |
4级:关键字:可度量, | 实现TMMi 2级和3级的目标后,测试可以成为一个可测量的过程,可以用来评估测试过程的质量,评估生产率,并监督改进。 包含的过程域: 4级 4.1 测试测量 |
5级:关键字:预测、预防、持续改进, | 在5级,组织基于统计控制过程的定量认知,具备了持续过程改进的能力。建立缺陷预防过程域,通过质量控制过程域来进行统计管理,引入了微调机制,不断改进测试。 包含的过程域: 5.1 缺陷预防 |
TMMi标准的结构
TMMi标准框架非常清晰,分为16个过程域,每个过程域包含特殊目标和通用目标,过程目标下一层级是特殊实践,通用目标下一层级是通用实践,每个特殊实践会包含子实践和典型工作产品。
上图所示的内容,在TMMi被称之为“组件”。TMMi将组件区分为必需组件、期望组件和信息组件。解释如下:
- 必需组件 描述一个组织为了满足一个过程域而必须实现什么。一个组织的过程必须明显实现这些要求。
- 期望组件 描述一个组织通常为实现一个必需组件而将要实施什么。期望组件引导过程改进和评估。
- 信息组件 提供一些详细信息以帮助组织开始考虑如何实现必需组件和期望组件。子实践、典型工作产品、说明、例子和参考信息都是信息组件。
下表是上图所示组件的详细解释,以及组件的性质。
企业为什么要做TMMi认证?
首先,TMMi标准在行业内的认可度非常高,涵盖了测试管理和实践的方方面面,尤其是对于很多已经通过了CMMI认证的企业,TMMi在测试领域对CMMI具有非常好的补充和融合。
其次,企业在通过TMMi认证的过程中,借助于咨询公司的输入,对标TMMi标准,梳理、补充并完善自身的测试管理体系,形成组织级的测试管理流程和制度,在企业范围内开展实践并进行推广。
再次,企业可以借鉴行业内的最佳实践和经验,在提升过程中,普及并推广软件质量意识,培养自身专业的测试人才,从而全面提升软件质量。
在数字化转型的大趋势下,随着DevOps工程实践的普及,企业对于软件质量和测试自动化的要求水涨船高,测试的提升是大势所趋,这也对测试领域的从业人员提出了更高的要求。在此背景下,TMMi标准为企业指明了测试能力提升的方向,也指明了测试过程改进的演进路线。
2. 案例1 基于风险的测试体系建设与应用——宁波银行TMMi实施
1.建立基于风险的全生命周期测试体系
为了让测试工作能更有针对性,提升测试的投入产出效率比,在外部咨询师的协助下将现有的测试工作进行适当左移,测试人员更多参与需求分析和评审工作。 //参与需求分析和评审
在需求评审的过程中,与利益干系人站在产品质量的角度上有效识别产品风险,将识别出来的产品风险进行分析;再根据风险分析结果制订合理的测试计划。--需求评审识别风险;
在整个测试项目进行过程中,对风险进行有效监控和缓解,并且将产品风险的测量结果作为投产上线的重要依据之一。---测试过程中,监控缓解风险
在测试收尾阶段,根据风险在整个项目中的变化对风险进行归档,持续保持最新、最全的风险资产库,以促进风险可以得到有效地复用(见图2)。
图2 风险管理与测试全过程的融合示意图
2.优化测试体系,完善质量门禁
在本次基于TMMi改进项目前,制订的测试体系对于质量门禁的针对性不强,且落地实施的效果一般,在实际测试项目中对于测试出入口准则的把控,部分依赖于测试人员的个人经验判断,使得产品质量无法得到有效保证,返工事件也时有发生,定义一个利益相关方都认可的质量门禁并在项目中严格执行就变得非常重要。
在测试计划、测试分析、测试执行、测试结束四个阶段结合实际情况制订合理的质量门禁,保证质量的出入口要求可以有效落地实施。
同时,对于原有测试体系中不明确的地方建立详细的指导手册,为具体的测试活动提供指导,让测试体系真正为测试项目提供帮助。
3.实施测试目标解码,定义高阶性能指标
测试中心核心骨干员工对业务目标、IT目标进行战略解码,经过深入讨论后形成测试组织的目标并对目标设置合理的高阶性能指标,在整个组织进行宣贯,成为指导测试的指挥棒,协调关键资源在重要的工作中的配置,最大化输出测试的价值。
4.加强测试理论的培训,培养合格的测试人才
在经过深入的行业调研后,选择最适合测试人员的国际软件测试工程师(ISTQB)和聚焦测试过程改进TMMi专业人员认证。整个项目中培养通过ISTQB和TMMi认证的专业测试人员近百人,初步建立了具备测试理论基础和实践经验的测试专业团队,为我行测试工作进一步提高奠定了坚实的人才基础。
测试工作未来发展的方向
经过实施TMMi认证,积累了大量的经验,在测试过程改进的过程中,发现了一些尚待改进的问题,未来将在紧密围绕测试提质增效的基础上,实现需求和测试的一体化。进一步引入更多的国际和国家标准体系,并将其融入现有的体系中,培养更多具有理论基础和实践经验的专家团队。提升测试与需求、测试与研发的协同,实现业务需求驱动研发和测试,进一步实现测试过程管理平台化、可视化、智能化,向数字化银行的目标奋勇前进!
3 案例2 基于TMMi的测试管理体系建设与实践分享--华夏银行
挑战与目标
华夏银行2018年成立金融科技子公司并于2019年4月在济南组建了测试中心,与信息科技部业务测试室形成了“一室一中心”的测试架构体系,在这种模式下可充分站在业务和用户视角进行测试工作,推动业务与测试的高效协同,从而提升软件产品的竞争力和质量。
但在实施的过程中仍然遇到不少的问题和挑战,如下:
● 尚未形成统一的测试方针和目标,“一室一中心”在异地模式下,协同能力有待提升;
● 缺少一套完善的组织级测试管理体系作为参考指南对测试管理和实施工作进行有效指导;
● 无法找到有效的实践以提升质量信心;
● 测试管理和决策工作主要依赖于主观经验判断,而非客观数据分析结果;
● 测试人员实践经验丰富,但没有专业的体系理论支撑。
基于上述挑战,华夏银行希望通过TMMi以及专业咨询团队,带来行而有效的实践和丰富的经验,能够在“一室一中心”的异地模式下加强工作协同,同时能够进一步保障质量,持续提升测试成熟度水平。
改进提升理念
在TMMi项目实施过程中,华夏银行充分结合“道、法、术、器、势”的理念,创建切合科技发展需要的一体化、标准化的测试管理体系和实践,以有效地保障软件产品质量。
1.道以明向
“道”:在应对“一室一中心”异地工作的模式下,需要提升协同效率,故基于TMMi目标驱动的理念,以及行内测试组织对业务目标和科技发展目标的深入解读和分析,形成了华夏银行组织级的测试方针,以助力公司业务发展目标的实现以及响应金融科技发展战略的需要,体现测试价值、提升价值认同感,同时“一室一中心”能够聚焦在同一目标上进行协同工作,是测试组织开展日常工作的依据以及未来可持续发展的基础。
2.法以立本
“法”:在项目整体解决方案中,我们充分参考了国际先进的标准,将TMMI(测试成熟度模型)、ISTQB(国际软件测试认证委员会)带入华夏银行,打造以客户为中心“端到端”的质量保障体系,并且结合行内现状,通过融合、创新、试点、持续优化等工作,建立了一套一体化、标准化、规范化的测试管理体系,为测试决策、测试管理和测试实施建立了相关的原则和参考指南。
3.术以立策
“术”:在项目实施过程中,通过相应的标准和实践,将改进的方法论、专业知识等进行资产沉淀,并且运用这些方法在相关场景中落地实践,如IDEAL、GQM、SMART等方法论。在测试管理体系中所包含的指南和实践,是站在测试视角最大程度上保障质量,例如建立基于风险的测试策略、完善质量门禁、优化评审机制、建立测试质量评价机制和组织可持续改进的能力等,这些指南和实践将指导测试人员有效地开展工作。
4.器以成事
“器”:为了能够更好地支撑“道、法、术”,测试组织需要更好地利用工具平台,以提升测试效率并且促进测试管理体系更有效地落地运行,将测试过程透明化、可视化、协同化,从而做到贯彻“道”、遵循“法”、活用“术”,会用“器”。
5.势以立人
“势”:所谓时势造英雄,在华夏银行科技发展的快速通道上,需要一支符合金融科技发展所需的专业人才队伍,“道、法、术、器”最终落实离不开人员的经验和能力,故需要对行内测试人员在专业知识领域上进行整体提升,以支撑更为高效和专业的工作。华夏银行对标国际标准,将人员进行了专业化认证培训,鼓励测试人员持证上岗,不仅需要丰富的实践经验,同时也需要专业的知识体系支撑,才能更好地支撑测试组织可持续发展以及成熟度进一步提升。
过程改进实践
通过以“道、法、术、器、势”为体系建设理念和指导方针,通过落地有效的实践加以支撑,促使华夏银行测试管理体系能够更好、更有效地进行落地实施工作。
1.实现测试目标战略解码,测试价值输出高效
随着测试组织规模的逐步扩大,测试职责多样化,测试组织需要对未来发展方向和具体目标进行整体规划,以支撑测试组织可以有序稳步地提升和发展,但在实践过程中,我们发现测试规划缺乏有效的方法论支撑,测试组织的规划更多依赖于少部分人的经验以及领导的要求,目标不清晰且单一分散,对于目标的实现情况以及实现后的价值无法进行评估,未形成可持续的模式。
基于TMMi中目标驱动的理念,融合GQM方法和SMART原则,通过对企业业务目标和科技目标的深入学习和分解,使测试能够围绕业务目标和科技目标进行战略解码工作,形成了组织级的方针,其中包括:愿景、使命、价值观、目标、任务层、领域和性能指标等。
使华夏银行“一室一中心”模式有统一的指导方针,测试价值认同感得到有效提升,促进两地工作的协同高效。
2.建立一体化、标准化的测试体系
随着测试组织规模的逐步扩大,测试过程和人员的不稳定性会带来较大的风险,例如体系结构不统一、术语不一致、资产得不到有效沉淀等情况,无法通过标准化、规范化的体系有效支撑测试过程和质量,对于人员能力的依赖性较大,不利于组织管理者和决策者对测试工作进行统一管理和协调,尤其是两地的测试模式。
以“建立一体化、标准化的测试体系”为体系建设目标,首先需要对现有的测试体系进行梳理、整合和分层工作,使测试体系结构清晰化、结构化,测试流程透明化、合理化。
3.建立基于风险的测试策略,风险可控、保障质量
结合TMMi中“风险驱动”的理念,测试从本质上来说就是基于风险的过程,需要找到被测对象中潜在的风险和问题,并尽早进行规避和风险,以保障在生产环境上稳定运行,尽可能地避免在生产环境中发生生产事件,有效地控制风险。
很多金融企业通常依赖于基于需求的测试,往往忽视从质量风险的角度出发进行相应的测试工作,会导致测试重点无法突出、资源无法合理调配、问题往往在后期发现等问题,影响产品质量,增加返工的成本。
在本次项目中,我们充分借鉴TMMi中风险驱动的理念,明确产品风险(Product Risk)的定义建立了基于风险的测试策略,将风险应用融入到整个生命周期过程中。
基于风险的测试实践在需求评审的过程中,测试人员与利益相关方站在产品质量的角度识别有效的产品风险,并从风险发生的可能性和发生后的影响性加以分析,根据风险分析结果制定合理的测试途径(依据MoSCoW原则有效地对测试重点进行识别,并且分配合理的测试资源)以及风险应对措施,以缓解风险。
基于风险的测试可以在软件开发生命周期的过程中尽早、尽可能地发现和缓解被测对象中的潜在风险,并依据风险,识别测试重点、合理分配测试资源,从而保证软件产品的质量,为上线决策提供重要依据。
4.建立结构化的度量体系和质量评估模型,促进测试决策数字化
测试的主要职责是保证质量,但在实际情况中测试工作结束后并不能够对被测对象的质量进行有效评估,对质量的评估更多依赖于主观判断,且管理者和决策者也无法能够通过数据对被测对象的质量进行客观地衡量。同时,我行在早期自己试行测量工作中,由于没有专业方法论的支撑,导致存在指标堆砌、维度单一且零散等情况。
在本项目中,结合我们自身特色以及TMMi相关方法论,在专业咨询团队的指导下,建立基于目标驱动、面向用户的三层架构测试测量体系,使测试测量体系结构化、体系化,实现产品质量数字评价、数字决策,为评价产品质量即上线信心提供了数据支撑基础。
对于度量结果分析,我们结合5WHYS、石川鱼骨图等方法,分析通过度量数据所反馈出问题的根因,并制定消除根因的解决方案,进行持续改进工作。
5.重视人才培养,为金融科技发展需要打造一支专业化队伍
随着华夏银行金融科技发展的需要,对于人员能力的要求也越来越高,人才培养也受到了足够的重视。但由于培训目标不清晰,测试人员能力参差不齐,培训准备时间不充分等原因,导致培训的质量和效果差强人意,且不可进行衡量。同时,行内对专业的培训管理员以及系统化的培训体系支撑还有待加强。
结合iSQE(国际软件质量工程)的理念和实践,以提升测试人员专业理论知识水平和测试过程改进能力为目标,为测试人员提供IREB(国际需求工程)、ISTQB(国际软件测试认证委员会)、TMMi(测试成熟度模型集成)这3个专业领域实施专项培训,鼓励测试人员持证上岗。
“缺陷逃逸率”,Defect Escape Percentage,简称DEP | 是指软件产品发布后发现的缺陷数量与该软件产品在整个生命周期发现的所有缺陷数量的比率,通常用来衡量软件开发团队与测试团队对软件质量控制的水平。 缺陷逃逸率(DEP)= [R2 / (R1 + R2)] * 100% R1指的是产品发布前发现的缺陷数; R2是产品发布之后所发现的缺陷数。 |
缺陷检测率(DDP) | 缺陷检测率(DDP) = [R1 / (R1 + R2)] * 100%。 没错,缺陷逃逸率和缺陷检测率高度相关,理论上,它们二者之和应该是1,即: 缺陷逃逸率(DEP)=1-缺陷检测率(DDP) 因为软件测试不可能做到穷尽测试,且软件测试可以发现系统存在的问题,但是不可能证明系统中不存在问题,因此,即便是产品发布之后,我们也不可能在有限的时间内把产品中所有的逃逸缺陷都发现出来,因此,缺陷逃逸率(或缺陷检测率)的值可能会随着统计时间周期的增加而动态的发生变化。 在实际应用中,通常选定一定的时间周期对缺陷逃逸率(DEP)进行统计。这儿的时间周期通常是考核周期,例如1个月、3个月、半年或一年等。 缺陷逃逸率(DEP)=考核周期发现的生产缺陷数/(产品发布前发现的缺陷数+考核周期发现的生产缺陷数)×100% 根据行业中一些同行们披露的数据: 逃逸缺陷率如果在7%至10%,软件研发团队对软件质量控制的水平算作一般; 如果小于7%,软件质量控制水平算优秀; 如果大于10%,质量控制水平就比较差了。 |
开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!
更多推荐
所有评论(0)