前言
敏捷研发在领域内已经火了不是一天两天了,其具体内容与优势无须赘述.从研发团队的角度来说,转换一种新的研发模式必然是因为想达成之前的模式无法达成的目标,通常,我们会将这个目标定义为”加速交付”.这个目标比较笼统,从字面上理解,”加速”是核心,即我们追求更快的速度,但是从”交付”的定义上看,在追求效率的同时,我们会优先确保合格的质量.
如何确保质量?与传统研发模式一致,依赖研发过程质量控制.
敏捷模式下的质量控制的特点
敏捷模式与传统模式的区别在于迭代频度更高,反馈效率更快.因此对于研发过程中的质量控制活动来说,也需要更快速的提供质量反馈从而实现快速响应.这有赖于后面会提到的自动化手段.
除此之外,传统的瀑布模式从组织上会更明确开发团队和测试团队的概念,而忽略研发团队的概念.举例来说就是开发人员负责开发,测试人员负责测试,我们并不否定这种职责划分,但是在敏捷研发模式下,这种界限会相对模糊,因为两者的工作会有大量交集,过于清晰反而不利于质量控制活动的开展.
质量控制策略如何制定
基于缺陷修复成本理论,缺陷越早发现修复成本越低,所以不管是传统模式还是敏捷模式,我们的质量控制策略都是会基于尽早发现问题为导向,一切延误问题发现时机的做法我们都将摈弃,一切加速问题发现时机的做法我们都建议引入.
冲刺中的质量控制如何做
将传统模式下的交付周期缩短,即单个交付节点划分成多个更短的交付节点,是敏捷实施的第一步,每一个交付阶段我们称之为”冲刺”.在每一次完成的冲刺中,我们会完成传统模式的所有主要活动,包括设计,编码,测试等,所以我们的质量控制活动主要集中在每个”冲刺”中.
- 质量控制第一步:明确交付标准
质量的定义非常丰富,针对不同产品展现的形式都不同.质量控制活动与研发活动类似,都是通过一系列手段最终达成质量目标或交付目标.因此要实现有效的质量控制,首先必须明确质量标准,例如一个产品如果没有性能的要求,而在制定质量控制策略时却大量考虑性能相关的要求,就属于无用功了.
多数情况下,产品人员仅会提供一个较为笼统的交付标准,仅考虑功能要求(包含性能),而没有其他方面(如安全,代码健壮性等)的要求,而往往产品的质量需要考虑以上产品人员会考虑到的那些.因此,产品的交付标准依赖于整个团队(包括产品,开发,测试,运维)共同制定.
常见的交付标准包括:1.单元测试覆盖率100%;2.单元测试分支覆盖率30%+;3.代码合格率90%+;4.功能测试通过率100%等.
- 质量控制第二步:分解交付标准
按照传统模式的做法,第一步梳理出的交付标准,通常会通过投产之前的一次集中大扫除来达成.且不论项目进度是否允许团队能够腾出这样一段时间来集中做这件事,这种在项目投产前对代码做大量变更的做法,从风险管控上也是存在很大问题的,所以为了避免风险,通常的做法是临时将交付标准降低,之前制定的交付标准基本失效.
敏捷模式下会将交付标准进行分解,将质量控制工作分散到研发过程中的多个环节,从而减轻上线前修改代码的压力.
常见的分解方法是将代码质量控制活动放在代码提交前和代码合并前,将测试质量控制活动放手工测试前和投产上线前,即需满足一定交付标准才允许下一步操作.
- 质量控制第三步:将质量控制活动自动化
传统模式下的质量控制活动之所以滞后,很大一部分原因是因为质量控制活动成本过高,在研发过程中如果加入的质量控制需要耗费大量时间,严重影响研发进度.在敏捷模式下,由于迭代频度提升,质量控制活动更频繁,若还是采取以前的手工方式,成本必然无法承受,因此建议将质量控制活动自动化.
根据我们的实施经验,可自动化的质量控制手段包括静态代码扫描,自动化测试.
- 质量控制第四步:制订质量控制过程规范
在实现了质量控制活动的自动化后,我们就可以考虑将以上的质量控制活动加入到过程规范中了.我们将选取几个关键节点作为质量控制点:
- 1.代码提交;
- 2.代码合并;
- 3.手工测试;
- 4.投产发布;
我们将之前分解的交付标准分解到这几个关键节点,即将必须满足一定交付标准作为这几个阶段的准入条件,举例来说:代码合格率必须达到90%以上才能提交成功,控制过程依赖我们上面实现的自动化.
- 质量控制第五步:严格按照过程规范执行
在做完以上准备工作之后,团队应该按照过程规范严格执行.在实际实施过程中,可能发现之前分解的交付标准不太合适,例如将静态扫描放在每次代码提交前,由于项目的代码量过多,导致每次扫描时间过长,开发人员无法忍受长时间等待,这种时候,首先应该考虑的不是先跳过这次检查,而是通过技术手段解决,例如模块化扫描或增量扫描.在通过技术手段仍无法解决时,才考虑交付标准的重新分解.
交付标准分解的建议
- 建议一:根据耗费时间长短对应操作节点
我们都知道代码质量控制的相关活动都可以通过SonarQube工具扫描来完成,但实际的研发过程中,如果将代码质量控制的相关活动都放在一个节点完成,必然造成每一个节点耗费时间过长.因此建议将交付标准按照耗费时间长短进行分类,操作频繁的节点上只加入耗费时间较短的质量控制活动,而将耗费时间较长的活动加入操作不频繁的节点上.
例如在研发过程中,代码提交的动作会相对比较频繁,因此像静态扫描分析单元测试覆盖率的活动(如何代码量大的话),就不适合添加在这一环节.
- 建议二:根据交付标准优先级对应操作节点
质量要求对应的交付标准应该区分优先级,以功能要求和性能要求举例,功能是否可用肯定优先于系统最大能承受的用户数.在交付标准分解时,建议将优先级高的交付标准尽量往前,对应相对靠前的操作节点,而将优先级低的交付标准尽量往后,对应相对靠后的操作节点.
例如建议将自动化测试进行分类,自动化冒烟测试对应产品的主要功能,自动化回归测试对应产品的历史功能.自动化冒烟测试应该加入每次手工测试之前,而自动化回归测试只需要加入每次投产上线之前.这样做的目的在于在项目进度要求较紧的情况下,对质量控制活动做取舍时能够更加从容.
关于手工测试的策略
以上的交付标准主要通过自动化实现,但是覆盖范围有限,团队仍然需要依赖大量的手工测试保障功能要求.不管是敏捷模式还是传统模式,我们都建议测试人员在测试开始之前都能够制定测试策略.
测试策略应该如何制定?建议至少考虑以下三方面的内容.
需不需要测
这一点与传统模式有比较大的区别,之前已经提到过,敏捷模式下的开发和测试的界限非常模糊,因为两者的工作有大量交集.我们也希望通过敏捷的实施,能够让开发角色和测试角色相对模糊,开发人员也可能承担一部分测试的工作.是否所有的功能都需要提交给测试人员进行测试呢?一些简单功能是否只需开发自测就可以呢?已有的自动化测试是否已经可以覆盖呢?能够提炼出部分不需要测试人员进行手工测试的内容,也是研发团队充分自信的表现之一.
应该先测什么后测什么
测试工作的核心目标是尽快找出最重要的缺陷,因此我们的测试策略制定应该严格参考这一原则.我们应该将测试对象按照优先级分类,优先级的分类应该参考功能模块的业务复杂程度(缺陷出现的概率),商业角度的重要性(遗漏缺陷对客户的影响程度),客户的使用频度(遗留缺陷的概率),代码实现的复杂性(缺陷修复的成本)等方面考虑.
应该如何测试
自动化or手工?采用什么工具?是否有现成工具?
总结
敏捷模式下的质量控制策略与传统模式的最大区别是更一体化.将质量交给测试控制的做法已经”过时”了.敏捷的实施希望能够让团队对产品质量有一个统一认识,并一起规划质量控制活动.