质量内建是规模化敏捷(规模化研发交付)的核心

质量内建的基本含义

(来源公众号:JFrog杰蛙DevOps)

内建质量作用在开发过程中,要求软件生命周期之间参与的各个角色都需要实时的对软件的质量负责。确保软件在交付到下一环节前已经有了基础的质量保证。其核心目的就是减少因为质量问题导致的返工,而浪费大量人力成本。

SAFe中的质量内建:质量内建是实现连续价值流的必要条件

内建质量是规模化敏捷SAFe的核心价值观。

检查不能提高质量,也不能保证质量。检查已是太迟。产品的质量,无论好坏,都已经发生了。产品或服务的质量不能靠检验;质量必须内建。

- W•爱德华兹•戴明

a613f7c4dda44a5a1f9d300a37423c3d.png

下面这一段摘自SAFe网站:

质量内建实践确保每个解决方案元素,在每个增量上,在整个开发过程中满足适当的质量标准。企业以最短的持续交付时间交付新功能并适应快速变化的业务环境的能力取决于解决方案质量。因此,毫无疑问,质量内建是SAFe的核心价值之一,也是敏捷宣言的原则之一,“持续关注技术卓越和优秀的设计增强敏捷性”。质量内建也是精益敏捷思想的一个核心原则,它有助于避免与召回、返工和修复缺陷相关的延迟成本(cod)。SAFe的质量内建理念,运用系统思考优化整个系统,确保整个开发价值流的快速流动,让质量成为每个人的工作。所有团队,包括软件、硬件、运维、产品营销、法律、安全、合规等,都共享质量内建的目标和原则。


质量内建时代的QA转身

(来源公众号:敏捷和CMMI)

1.       作为某个领域的质量专家(如:合规),加入到团队中,作为团队一份子,提供和提升该领域方面的质量(如:法律法规、证监会、银监会、组织管理等)需求,具体工作有:

·      研究质量(合规),并提出质量(合规)方面的需求作为Backlog统一管理

·      自己实施质量(合规)工作或协助其他组员实施质量(合规)

·      利用专业的质量(合规)领域知识,进行质量(合规)测试和验收

·      组织领域专家进行质量(合规)确认

2.       转型为团队的敏捷教练,在保证敏捷仪式的过程中落地质量内建保证工作,具体讲就是:

·      把质量要求融入到敏捷团队的工作流程,每道工序都有明确的质量标准,包括合规性、安全要求、质量要求等

·      辅导团队执行带有质量内建标准的流程,并及时回顾、纠偏

3.       转型为服务支持团队,和其他服务支持团队一起,如:PMO,过程改进小组,桌面支持,安全合规等等,主要工作有:

·      打造组织范围内的“质量内建的价值观”,通过培训、面谈、宣传等方式;

·      制定并维护组织级质量方面的标准,各个敏捷团队可以参考执行,以便达到质量内建的能力;

·      配合监管要求,定期组织并实施组织级在质量方面的质量审计。

·      收集和分析质量方面的数据,并发现改进机会,制定改进计划,从而持续改进质量内建

某团队质量内建的角色分工

(来源公众号:DevOps)

1)开发角色

用例执行效果不理想:有些用例不执行或者用例不完全按照测试步骤执行。

解决方案:

  • 整理测试用例覆盖的bug数据,每个迭代关注数据督促开发执行。

  • 将测试用例覆盖出现的bug数作为考核指标引起重视。

在本地或开发环境自测,自己构造数据导致测试结果不一致。

解决方案:

  • 统一到测试环境,开发完成后部署完先自测,完成后在进入测试阶段。

  • 数据保证从业务层面构造,不能通过修改数据库等方式略过业务场景,无法发现问题。

  • 开发对测试数据有疑问的,测试同学帮助构造业务数据,熟悉业务的数据流程。

开发每人负责一个模块,业务边界或流程上的没人负责。

解决方案:

  • 明确组长或某个角色负责有交叉的业务自测验证。

对测试用例的理解与测试同学不一致。

解决方案:

  • 进入测试前,测试与开发沟通测试用例(一对一)+测试用例评审。

2)测试角色

测试用例不能及时提供:刚开始推行,既要写用例,提测后又要验证每条用例,测试时间并没有因为这种模式缩短,反 而更长了,且由于之前迭代的遗留测试任务,总是不能及时交付,加班也很难赶上开发的节奏。

解决方案:

  • 短期改善期是会比之前更忙,是不可避免的,过渡期。

  • 逐步来,提供用例的需求覆盖度,从20%开始,逐步增加到80%。

  • 优化简单的需求开发自测保证,大家共同努力。

  • 跟开发沟通需求和测试点后,先提供能覆盖各种场景的测试点和粗略的预期结果,在开发完成代码时提供全部的测 试用例。

用例场景考虑不全,用例不充分。

解决方案:

  • 测试用例评审。

提供的测试用例,颗粒度问题。

解决方案:

  • 和开发团队约定一个大家都可接受、理解的程度。

3)产品角色

需求不明确,细节没有写清楚,影响测试输出的质量和时间。

解决方案:

  • 测试给出需求规约,由产品针对规约进行细化补充确定需求规范,并按照规范执行。

  • 流程上约定测试同学先过一遍需求文档,符合评审要求才进迭代。

需求文档给出不及时,没时间充分的需求分析以及用例输出。

解决方案:

  • 约定给出时间。

需求插入或变更没有同步到测试,导致测试用例无效、返工。

解决方案:

  • 约定需求变更截止点+要求同步到测试。

质量内建与持续部署

(来源公众号:DevOps)

DevOps and Release on Demand is one of the five core competencies of the Lean Enterprise. It provides the enterprise with the ability to deliver increasingly valuable solutions to end users with optimal frequency. By systematically reducing time in the development cycle with Built-In Quality approaches, SAFe’s leaner and more Agile approach to the delivery process helps establish faster development flow.

DevOps和按需发布是精益企业的五大核心竞争力之一。它使企业能够以最佳频率向最终用户提供越来越有价值的解决方案。通过质量内建的方法系统地缩短开发周期的时间,SAFe更精简、更敏捷的交付流程方法有助于建立更快的开发流。

SAFe describes the four basic sub-dimensions of Continuous Deployment, as Figure 2 shows: deploy to production, verify the solution, monitor for problems, and respond and recover: 

  • Deploy to production covers the skills necessary to deploy a solution to a production environment 

  • Verify the solution covers the skills needed to make sure the changes operate in production as intended before they are released to customers 

  • Monitor for problems covers the skills to monitor and report on solutions 

  • Respond and recover encompasses the skills to quickly address any problems that happen during deployment

SAFe描述了持续部署的四个基本子维度,如图2所示:部署到生产环境,验证解决方案,监控问题,以及响应和恢复:

  • 部署到生产环境包括将解决方案部署到生产环境所需的技能。 

  • 验证该解决方案涵盖了在将更改发布给客户之前确保更改在生产中按预期运行所需的技能。 

  • 监控问题包括基于解决方案的监控和报告的技能。 

  • 响应和恢复包含快速解决部署期间发生的任何问题的技能。

Once the deployed changes are verified and operable as intended in the production environment, they are one step closer to being able to release. Four skills help drive verification: 

  • Production testing – the ability to test solutions in production when they are still ‘dark’

  • Test automation – the ability to test repeatedly via automation 

  • Test data management – managing the test data in version control to create consistency in automatic testing 

  • Testing nonfunctional requirements (NFRs) – system attributes such as security, reliability, performance, maintainability, scalability, and usability must also be thoroughly tested before release

一旦部署的改动在生产环境中按照预期进行验证和操作,它们就能够更快地发布。四种技能有助于推动验证测试:

  • 生产环境测试 – 当解决方案仍处于“黑暗”时,在生产环境中测试该解决方案的能力。 

  • 测试自动化 - 通过自动化反复测试的能力。 

  • 测试数据管理 - 在版本控制中管理测试数据以在自动测试中创建一致性。 

  • 测试非功能性需求(NFR) - 系统属性(如安全性,可靠性,性能,可维护性,可伸缩性和可用性)也必须在发布之前进行全面测试。

本文汇编自各大公众号,已逐一注明出处。特别致以感谢。

  • 0
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值