标签归档:敏捷测试

敏捷测试宣言与原则解读

敏捷测试宣言

解读

敏捷测试宣言表达的是我们对于敏捷测试的信仰和价值观,分别包括流程、团队合作、自动化和核心价值观四个维度。

在以往软件发布周期较长、需求变化频率较低、不同角色间的合作壁垒较高的环境下,传统的开发模式所采用的孤立的测试阶段、测试人员独立把关质量、回归式的全量自动化测试和质量检测,是有其价值的。但是,在敏捷开发模式下,敏捷测试则更强调左侧的价值观。

全程的测试介入

敏捷测试提倡测试左移和右移,从软件生命周期的早期(左侧)一直到产品发布上线后的生产环境,都需要有测试的介入和测试活动的开展。

左移是为了更好的理解和澄清需求,以减少需求理解不一致导致的浪费;而右移是充分利用生产环境的数据来优化开发和测试流程,以增强软件系统应对各种不可预测性的能力。

左移和右移并不仅仅是将测试活动移到两侧端点,更强调的是每个环节的参与,也就是全程测试介入,这是从流程上保障高质量软件交付的关键。

团队整体对质量负责

敏捷提倡全功能团队,团队的角色之间分工不再那么明确,不同角色间的协作更加密切,团队一起为质量负责,是敏捷测试需要遵循的指导性原则。

团队需要对质量目标有统一认识,在敏捷软件生命周期的每个环节有不同角色的共同参与,实现质量目标是每个角色的职责。

持续性的精准自动化测试

自动化测试是敏捷测试的基础,是快速反馈的必要手段。自动化测试不能一味的追求覆盖率,而是要追求有目的的精准覆盖。也就是说,自动化测试首先必须是有效的,是基于业务风险考虑的,才能真正实现快速反馈。

自动化测试需要能够在持续集成流水线上持续的运行,为每次代码提交提供反馈,以确保系统功能不会因为新代码的提交而被破坏;同时,随着功能的不断迭代,自动化测试需要相应的更新、增加,确保新功能是有有效自动化测试覆盖的。

质量内建

质量内建是敏捷测试的核心,需要将测试全程介入、团队为质量负责和持续精准的自动化测试结合起来,在敏捷软件生命周期的每个环节做好缺陷的预防,把质量融入到产品的开发构建中。

敏捷测试原则

  1. 我们的目标在于和团队一起尽快地交付高质量软件。
  2. 测试人员尽早参与软件早期阶段,与所有团队角色合作,通过实例化需求,确保对业务价值理解的一致性。
  3. 测试人员关注生产环境状态,收集数据,指导和优化前期的分析、开发和测试。
  4. 测试人员和开发人员同处一个产品项目团队,而不是独立的测试团队或部门。
  5. 测试人员负责探索性测试,和开发人员结对,设计、实现和维护自动化测试。
  6. 自动化测试在流水线中持续精准执行,快速发现每次代码提交对于已有功能的影响。
  7. 测试数据对于自动化测试是充分的,并能按需获得。
  8. 测试活文档化,和代码一起,作为知识资产进行版本化管理。
  9. 自动化测试需要有效的分层。
  10. 预防缺陷,而不是关注缺陷的数量。

解读

敏捷测试需要遵循如下10条原则:

1. 我们的目标在于和团队一起尽快地交付高质量软件。

敏捷测试的目标,所有的测试活动都围绕这一目标开展。敏捷测试人员要有思维上的转变,不再是关注于发现更多的缺陷,而是思考和采取相应的措施以帮助团队更快、更高质量的交付软件。

2. 测试人员尽早参与软件早期阶段,与所有团队角色合作,通过实例化需求,确保对业务价值理解的一致性。

测试左移,团队合作,需求的清晰表达,确保团队在做对的事情,拥抱变化的同时能够少走弯路。

3. 测试人员关注生产环境状态,收集数据,指导和优化前期的分析、开发和测试。

测试右移,由于生产环境的特殊性,并不能将测试活动简单右移到生产环境,只能通过收集和分析生产环境的数据,利用这些数据来优化开发、测试和业务价值,让生产环境和开发过程形成良性环路。

4. 测试人员和开发人员同处一个产品项目团队,而不是独立的测试团队或部门。

测试人员属于开发团队的一员,推倒角色之间的沟通壁垒,测试人员与开发人员进行密切的合作。

5. 测试人员负责探索性测试,和开发人员结对,设计、实现和维护自动化测试。

自动化测试不只是测试人员的职责,单元测试和接口测试主要由开发人员负责,而界面层自动化测试同样需要开发人员一起参与设计、实现和维护,这样才更高效;同时,可以让测试人员抽离出来去做更有价值的事情——探索性测试。

6. 自动化测试在流水线中持续精准执行,快速发现每次代码提交对于已有功能的影响。

自动化测试需要在持续集成流水线中运行,并且做到能够按需精准执行,在追求完备覆盖的同时还能高效运行,快速提供反馈。

7. 测试数据对于自动化测试是充分的,并能按需获得。

自动化测试应该有完备的数据集,包括正常和异常情况的覆盖、满足不同环境或不同平台的执行要求等;同时,需要有完善的数据创建和管理方案,确保不同需求下的自动化测试能够获得相应的测试数据。

8. 测试活文档化,和代码一起,作为知识资产进行版本化管理。

需求文档要跟自动化测试关联,变成可执行的活文档,并且要跟产品代码一起作为知识资产进行版本化管理。

9. 自动化测试需要有效的分层。

自动化测试要根据不同的测试对象进行有效分层。越往底层的测试实现成本更低、执行更高效、定位更准确,但覆盖范围有限,不能跟业务很好的关联;越往顶层的测试越接近业务、更能体现业务价值,但是执行速度、稳定性较差、定位问题较难。需要根据系统要求、技术架构等项目具体情况规划每层测试的合理占比,不能盲目的追求多而全的覆盖。

10. 预防缺陷,而不是关注缺陷的数量。

质量内建是敏捷测试追求的核心价值观,而质量内建本质上就是缺陷预防。敏捷测试需要团队把重心放在预防缺陷上,提高软件的内建质量,而只关注缺陷数量、甚至把缺陷数量当做考核指标的情况是违背这一核心价值观的。当然,对缺陷数量趋势的正确跟踪和对缺陷根因的深入分析,是帮助预防缺陷的有效手段,是值得推荐的。

敏捷测试的指导性原则

“这么多问题,你们是怎么测的?”

这是我们测试人员听到的最多的质问,也是传统的测试人员对质量把关的常见认识。

但是,事实上,就像著名质量管理专家戴明指出的那样:软件的质量不是测出来的,测试人员没法控制软件质量的好坏。尤其是在敏捷开发模式下,特别强调的核心是质量内建,而要做好质量内建,需要团队全员的参与,需要团队整体对质量负责,这是敏捷测试的指导性原则,我们在敏捷测试宣言里也有强调。

team-is-responsible-for-quality

01. 团队整体对质量负责有多难

团队整体对质量负责,这是个说起来容易做起来难的事情,很少有团队能够做的特别好。

那么,为什么这么难呢?

在我看来,多半情况是因为不是团队所有成员都清楚质量到底是什么,没有明确的质量目标,所以也就没法很好的对质量负责,要实现团队整体对质量负责,首先得搞清楚下面三个问题:

  • 敏捷里的质量是什么?
  • 通常容易忽视的质量有哪些?
  • 团队不同角色怎么为质量负责?

关于这部分内容,在《说好的团队为质量负责呢》一文里有详细的分享,感兴趣的同学请移步阅读。

下面将继续分享相关的两个话题:敏捷团队是否需要专职QA、能够整体对质量负责的团队有哪些特点。

02. 敏捷团队需要专职QA吗

既然团队整体对质量负责,肯定有人会有疑问:那敏捷团队还需要专职QA吗?

这是个有意思的问题,业界对于“去QA化”的讨论也是一波又一波的。甚至很多QA听到这个很是担心,觉得自己前途渺茫了。

QA-is-a-hat

其实,并没有必要那么纠结是否需要专职的QA,因为QA在团队所需要做的事情始终都是要做的,不管是不是有专职的QA,从团队的角度来讲,有人做那些事情不就ok了?我们可以把QA理解成一定帽子,不管哪个角色的人戴上这顶帽子,能完成QA的工作就可以了。但是,是不是什么角色的人都换个帽子戴上就能做QA的事情了呢?这个我相信大家还是比较清楚的,术业有专攻,肯定是专业的QA会做的更好。如果没有专职QA,对团队其他角色的要求就要高很多,不是每个团队都可以做到的。

因此,作为QA的我们,并不用担心是否“去QA化”真的会发生,倒是好好提升自己,多发挥应有的价值才是正道。

说到这里,推荐大家搞清楚敏捷团队的QA该如何工作,以及QA的职业发展之路是什么样的,可以参考如下文章:

03. 能够整体对质量负责的团队有哪些特征

除了前面讲到的清晰的质量目标、注意容易忽视的质量、团队成员的充分合作,要做到团队整体对质量负责对团队本身也是有要求的。从我的经验来看,能够整体对质量负责的团队通常有如下特征:

Healthy-team

信息共享

团队成员要能够为质量负责,首先得知道质量和质量目标是什么,而质量目标会受到众多因素的影响,每个项目每个阶段都会有不同的目标,及时将一些重要的信息分享给团队的每个人是至关重要的,包括客户的业务动态、生产环境系统的状态、终端用户的反馈、团队的工作重心、持续改进的状态、交付的压力和进度等等。

信息共享,有利于团队成员更好的发挥主观能动性,更好的真正为质量负责,这是健康团队最关键最重要的一个特征。

反馈机制

对于软件系统的质量,我们提倡持续集成、持续测试以获取及时的反馈;为了团队的健康,需要不断优化团队成员间的沟通与合作,同样需要有相应的反馈机制或渠道。团队需要营造反馈的文化,成员间应是平等的关系,任何人可以对任何人或事提供相应的反馈。

自动化测试提供的反馈有助于软件系统更加健壮,团队内的反馈机制则可以促进团队的健康发展,有助于团队整体对质量负责。

回顾会议

回顾会议是敏捷软件开发中非常有价值的一个实践,但有些团队的回顾会议流于形式,并没有带来什么效果。

好的回顾会议应该做到对事不对人,大家都能就日常工作中的事情发表自己的意见,做得好的方面继续发扬,需要改进的方面共同商讨应对策略,持续改进。

对于回顾会议讨论出的改进行动,一定要是可落地执行的,并且有相应的人员负责跟踪,不能光有行动的想法,但是并没有实际行动发生。

仪式感

“仪式感就是使某一天与其他日子不同,使某一时刻与其他时刻不同。” 日复一日的例行工作需要仪式感来适当的刺激,以增加团队成员的动力。

项目顺利上线、质量提高了一个档次、某事受到客户的表扬、解决了一个极为关键的生产环境故障等,都可以有一些庆祝的仪式让团队所有成员共享喜悦。

团队活动

除了有仪式感,团队还需要有定期的团队活动,比如一起出去吃午饭、一起去按摩、一起桌游等等,形式可以有很多,就算工作、生活太忙聚不全,一起简单吃个下午茶、聊聊八卦也是挺好的。

这种团队活动的目的主要是为了增进成员的凝聚力,一定要是轻松、愉快的形式,最好能够所有成员都参加。

04. 小结

团队整体对质量负责是敏捷测试的指导性原则,要做到这个,需要:

  • 明确质量目标,并且确保团队所有成员理解清楚各自需要为哪些质量负责;
  • 软件开发生命周期的每个环节都需要多角色的合作,发挥各角色所长,取得最佳效果;
  • 重视团队建设,组建健康的团队。

敏捷测试的核心

Q:质量内建跟敏捷测试的关系是什么?能分开吗?

A:我认为质量内建是敏捷测试的核心。

01. 传统测试

敏捷测试是相对于传统测试而言的,在聊敏捷测试之前,我们先看传统测试是什么样的。传统测试通常有如下的特点:

  • 独立的测试部门:测试人员跟开发人员不属于同一个部门,各自独立。
  • 测试工作主要由测试人员承担:功能与非功能测试,手动与自动化测试,冒烟测试、回归测试、发布测试等,基本都是测试人员的事情。
  • 详尽的测试用例文档:测试用例文档一般都要求详细的执行步骤。
  • 集中的回归测试:有独立的集中回归测试阶段,对所有功能进行全面的测试覆盖。
  • 发现更多的bug:测试人员的目的是发现更多的bug,甚至有些部门会把bug数量作为绩效考核的目标。

02. 敏捷测试

敏捷测试是伴随着敏捷开发过程的所有质量相关活动,有着如下的特点:

  • 不能独立存在,不是一种测试类型或方法
  • 敏捷测试不仅是测试人员的工作,敏捷测试是团队的活动
  • 抛开敏捷开发谈敏捷测试没有意义

敏捷测试的目标也不再是发现更多的bug,而是尽快的交付高质量的软件。

那么软件的高质量怎么获得呢?著名质量管理专家指出:质量不是检测出来的,产品生产出来质量已经在那里了。因此,通过加强测试保障没法提高软件质量,需要将质量内建到软件产品中。

03. 质量内建

软件的缺陷暴露的越晚,修复的成本就越高;前期对缺陷预防的少,后期发现的缺陷就会多;前期做好了缺陷预防,后面暴露的缺陷就会减少。因此,我们需要提前预防缺陷,而不是等开发完成了才发现很多的问题,这就是质量内建。

早在12年前接触敏捷测试的时候,有三个词深深的印在了我的脑海里“Test early,test often,test first(尽早测试、频繁测试、测试先行)”,其实,它们正好对应着质量内建的三个关键实践:测试左移、持续测试、测试驱动开发,是敏捷测试最核心的部分。

测试左移

测试左移要求测试在软件开发生命周期的左侧尽早介入,可以是需求分析阶段,也可以是更早的inception阶段。左移的测试人员可以做的事情可以有一起挖掘需求、分析需求、澄清需求、评审需求、参与技术方案讨论等,主要目的是利用测试人员独有的视角和对系统的了解,在各个环节进行必要的输入,确保团队对于需求理解的一致性,确保团队能够做正确的事情。

敏捷开发生命周期

测试人员参与需求分析的价值主要体现在下面两个方面:

业务价值

  1. 尽早的接触需求能够让测试人员更好的理解业务价值,从而为后续的系列测试工作提供帮助。
  2. 同时,需要测试人员更多的考虑业务价值,在各个需求环节能够从业务价值的角度提供输入,包括终端用户行为、业务流程、业务风险等维度的考虑。可以参考我的文章《敏捷测试如何优化业务价值》。

用户故事

用户故事作为敏捷开发过程中传递业务需求的载体,非常重要。对于用户故事的拆分和用户故事验收条件的描写都有很高的要求,测试人员参与可以帮助评审用户故事,提升用户故事的质量,以更清晰的方式在团队传递需求。要求测试人员能够透彻的理解用户故事拆分的“INVEST”原则,并利用这些原则来评审用户故事:

  • 独立的(Independent):要尽量避免故事间的依赖,做到相互独立,如果碰到两个依赖很强的用户故事,可能需要合并或者换一种拆分方式摆脱依赖。
  • 可讨论的(Negotiable): 故事是可讨论的,不是签署好的合同或者软件必须实现的需求。故事卡是功能的简短描述,细节将在客户团队和开发团队的讨论中产生。
  • 有价值的(Valuable):用户故事要对用户或者客户有价值。注意,有些用户故事可能不会给终端用户带来价值,比如信息配置类的故事,用户不会关心,但是对客户是有价值的。
  • 可估算的(Estimable): 开发人员没法估算某个故事可能的原因是开发人员缺少相关的领域知识或技术知识,也可能是用户故事太大了。对于前者,需要给开发人员讲述清楚业务上下文和相应的领域知识,并且要有相关技能的开发人员参与估算;如果是故事太大了,则需要进一步拆解成更小的可以估算的故事。
  • 小的(Small):故事太大不利于估算,可能需要拆解;故事太小也不利于计划,可能需要合并。故事的大小需要根据团队具体情况来定,但要尽量小一点。
  • 可测试的(Testable):用户故事必须是可以测试的,不然就没法验证开发人员实现的正确性。

持续测试

测试左移是为了让团队清晰一致的理解需求,从而做正确的事情;而持续测试则是在整个开发生命周期里的各个环节(生命周期最左侧,一直延续到最右侧的生产环境)的测试活动,以帮助快速收集反馈,从而正确的做事情。

持续测试的内容包括对持续功能测试,也包括性能、安全等的内建、持续测试;形式可以是静态分析、评审,也可以是动态的测试,包括手动执行的各种测试,以及持续集成流水线上的持续执行的自动化测试。下面我们从用户故事生命周期为例来看可以有哪些持续的测试活动:

故事生命周期

故事分析: 这个阶段主要是对故事的拆分、故事里的AC(Acceptance Criteria,验收标准)等内容进行评审,包括功能和跨功能需求的确认,看是否有需求遗漏或者不合适的需求,同时可以重点标注一些开发或者后期验证需要特别注意的点。

故事启动: 故事启动是在开发人员开始实现用户故事之前对需求进行澄清,确保业务、开发和测试对该用户故事要实现的需求达成一致的认识,包括功能和跨功能需求(安全、性能等)。

故事开发: 开发人员开始开发用户故事,并完成底层自动化测试(单元测试和接口层测试等);测试人员可以开始设计相应的测试用例和UI层功能自动化测试,同时可以将在测试设计过程中发现/想到的用户故事相关的问题反馈给团队。

故事验收: 故事验收是开发人员开发完成一个用户故事之后,对系统实现进行验收的环节,这个环节跟“故事启动”环节是对应的,同样包括对功能需求和跨功能需求的验证。

故事测试: 完成相应的功能自动化测试,让其在持续集成流水线上按需执行;同时,需要基于该用户故事执行相应的探索性测试。

故事演示: 将开发完的功能演示给客户,一般以特性为单位,需求、开发或测试人员来负责演示都可以,目的是尽早收集到客户的反馈,是客户验收的环节。

测试驱动开发

测试驱动开发就是大家所熟知的TDD,常见的有两种测试驱动开发,分别是:

单元测试驱动开发(UTDD): 在编写产品代码之前,先写单元测试,由单元测试驱动出产品功能代码,主要是为了保证设计的完备性,更好的实现质量内建。单元测试一般都是开发人员来实现的,测试人员不参与实现,但可以在故事验收阶段对开发编写的单元测试进行评审,确保单元测试覆盖的有效性。

验收测试驱动开发(ATDD): 除了单元测试之外,还可以先实现自动化的功能验收测试,在功能开发完成之后,要求所有验收测试都是能通过的。这样做可以尽早利用功能自动化测试收集反馈,更好的保证功能需求实现的正确性。验收测试可以由开发人员和测试人员结对完成或者测试人员独自完成。

说到ATDD,我们通常很容易联想到行为驱动开发(BDD),常被人们混为一谈,有必要再次说明一下。其实,BDD强调的是不同角色之间的协作,更好的理解和澄清需求,确保需求理解的一致性。BDD不是关于测试的,可以没有测试,但是可以指导测试,我们通常可以基于BDD的方式实现自动化测试。而ATDD是关于测试的,必须有测试。更多关于BDD的内容,可以参考我的文章《说起BDD,你会想到什么》。

04. 总结

质量内建
  1. 敏捷测试的核心是质量内建,而质量内建就是缺陷预防;
  2. 测试左移、全阶段的持续测试、测试驱动开发是质量内建成功的关键。

敏捷测试如何优化业务价值

提到敏捷测试就会提到优化业务价值,优化业务价值是敏捷测试的原则之一,敏捷测试的系列活动都要围绕交付价值服务,那么具体的到底要怎么做才能真正优化业务价值呢?

我们需要从四个不同维度来思考和组织相应的测试活动以实现优化业务价值,如下图示:

四个维度
四个维度

01. 从终端用户角度进行测试

从终端用户角度进行测试是基本的测试思维,是测试人员必备的技能要求。

在思考、设计测试用例并执行测试的时候,不能简单的套用用例设计方法去机械的进行,而是要考虑用户可能的行为习惯、使用场景等。

下面来看两个例子:

  • 场景一:我们在使用移动设备的时候,一般会设置自动锁屏。当测试某个移动App时,测试人员觉得移动设备的自动锁屏功能会导致测试很不方便,于是关掉了自动锁屏功能,结果后来在一台测试人员自己使用的设置自动锁屏的手机中发现了一个缺陷,就是在每一次锁屏并开启后,充值选项会新加载一遍,可以导致多个重复的充值选项存在。
  • 场景二:测试移动设备断网的情况,通常会采用调成飞行模式或者关闭数据网络的方式,这两种方式对于iOS7以下的版本通常都需要离开所测的App去设置,这样的操作会导致某些功能不可测或者很多问题不能被发现。如果在移动中测试,也就是说打开App测试过程中,测试人员移动到一个没有网络的地方(比如电梯),将有可能发现很多意想不到的缺陷。

上面两个典型的用户场景都是我们不容忽视的,根据这些真实场景去测试,把自己想象成终端用户,就能容易发现用户可能遇到的问题。

除此之外,还要考虑终端用户的体验,比如说页面的布局、配色、易操作性、页面加载时间等都是在测试过程中需要考虑的因素。这样,有助于交付一个增强用户体验的系统,对优化业务价值是有帮助的。

在敏捷开发生命周期的需求分析、特性启动(Feature kickoff)、用户故事评审、用例设计、故事验收和故事测试等环节都可以体现出从终端用户角度考虑的价值。

02. 以业务为重点的测试

单个终端用户的操作可能只是业务流程的一部分,除了从终端用户角度去测试,还需要看到更高一点,那就是业务流程的合理性、流畅性和完整性。这就要求能够真正理解企业的业务,以业务为重点来测试。

下面来看一个业务流程的简单例子:

  • 某购物网站提供搜索、查看详情、收藏商品的功能,用户可以将看中的商品添加购物车,并下单购买。最初的时候,只能从搜索的结果列表和商品详情页面添加购物车,而收藏是非常重要的一个功能,用户如果想把收藏的商品添加购物车还必须得一个个点开详情页面去添加…
购物流程
购物流程

这个例子中的搜索、收藏、查看详情和添加购物车本身的功能都没有问题,但是从整个流程来看就会发现缺失掉的场景:从收藏列表添加购物车。

敏捷中的用户故事只是覆盖其中某一个非常小的功能,对于用户故事的分析、评审、开发和测试,需要把所有相关故事串起来,甚至需要跟系统其他关联的特性或者第三方系统集成起来看,从整个业务流程角度去思考,以保证整个业务流程的合理性和相关功能的正确性,确保真正满足企业业务需求。

对于复杂业务情况下要发现缺失的路径可能没前面例子那么容易,需要敏捷团队各个角色都能加强这方面意识的培养。QA和Dev都能在敏捷开发生命周期需求分析阶段介入,尽早接触需求,有利于更好的理解业务流程。深刻理解业务流程、以业务为重点的测试,能够更容易发现关键业务流程中遗漏的点或相应的缺陷,测试带来的业务价值又上了一个台阶。

03. 映射业务影响

保证了每个业务流程的流畅性,还需要综合企业多个业务来看企业业务的优先级,能够区分哪些是关键业务和外围业务,要能理解每个业务对于企业的影响、给企业带来的价值。

举例说明:

  • 某公司的系统为税务和移民两块业务服务,在报税忙季,跟报税相关的业务最关键,优先级最高;而在淡季的时候可能报税业务的优先级就要比移民相关业务优先级低。当我们在测试该系统的时候需要关注这种优先级的变化,测试策略上需要有相应的调整。
  • 某公司的系统提供一种通过观看录播视频进行咨询的功能,但是由于制作视频比较费事费力,公司并没有准备马上把这个功能投入使用。这个功能目前并不完善,还有很多要改进的地方,但是由于不是当下的关键业务,它的优先级低了不少。测试人员在测试过程中,也不用投入太多精力去关注这个功能。

在测试过程中需要把系统的质量状况跟业务紧密关联起来,需要能够识别出系统缺陷对业务带来的影响,包括可能影响到的用户数、具体的影响是什么、有没有可以绕过的方法不至于中断业务的开展等。如果影响到最关键的客户,那么相同严重性的bug,对于只影响少量不怎么重要的客户来说,优先级也是完全不一样的。

下面几个方面可以帮助我们开展测试活动的时候更好的考虑业务影响:

  • 定期跟PO等关键业务人员沟通,以保证大家对业务优先级的一致认识,测试策略、测试计划要考虑基于业务优先级来制定。
  • 对于任何代码变更,不能是盲目的无重点的回归测试,要基于业务风险来测。
  • 对于自动化测试,需要权衡成本和收益,更需要基于业务风险来考虑,不能盲目覆盖、事倍功半,要以最小业务风险实现最佳测试覆盖。
  • 利用生产环境下的QA技术,收集生产环境数据并分析,我们可以更好的理解业务关键性和优先级。
映射业务影响
映射业务影响

04. 关联业务指标

除了前面三个维度,在度量项目/产品的测试或质量的时候,不能仅局限于项目/产品范围,要跟企业的业务指标相关联,跟踪、量化测试活动对业务指标的影响。这个维度是非常重要的。

测试不再是考虑发现尽量多的缺陷,而是要基于如何快速将产品投递到市场的战略,尽快让企业能够借助产品盈利。

做到这个维度,需要:

  • 从相关干系人那里确认业务指标,定期跟各干系人沟通,收集对于业务指标的反馈并更新。
  • 收集和分析生产环境的真实数据和模式,反馈到开发过程去更精确的预防缺陷,提高内建质量。

05. 小结

以业务为导向的测试,主要的是思维方式的转变,各个环节要加强对业务的关注。基于前面四个维度去思考,有利于帮助我们把优化业务价值落地。

聚焦测试,驱动卓越

在经历了“七年之痒”后,蓝鲸项目进入第八个年头,项目的一切趋于稳定。团队倡导持续改进,可大家的感觉是已经尽力做到最好,这个时候似乎没有什么可以改进的了。为了突破这个局面,项目重新聚焦测试,从质量和测试的角度对现状进行了一次评估。

评估采用的是基于软件测试原则的模型,本文就是跟大家分享一下这个模型。

测试原则

Testing principles

2012年澳大利亚敏捷大会(Agile Australia)上ThoughtWorks的非常资深的测试实践带头人Kristan Vingrys分享了如上测试原则,这些原则是ThoughtWorks的同事们在多年软件测试经验基础上总结出来的。

1. 质量内建(Build quality in)

You cannot inspect quality into the product; it is already there.
— W.Edwards Deming

著名的质量管理专家戴明指出:产品质量不是检测出来的,从产品生产出来后质量就已经在那了。这同样适用于软件产品。

缺陷发现的越晚,修复的成本就越高。质量内建要求我们做好软件开发每个环节,尽早预防缺陷产生,以降低缺陷出现后的修复成本,要减少对创可贴式的补丁(hotfix)的依赖。

Cost of change

推荐实践: TDD、ATDD等

2. 快速反馈(Fast feedback)

每个环节的任何变化都能最快的反馈给需要的人,从而可以基于当下最新信息做出明智的决定,降低风险。这要求我们对系统进行频繁的测试,缩短回归测试的周期。

推荐实践:

  • 符合测试金字塔结构的自动化测试,让每一层的测试都能发挥尽可能大的价值,给出最快速的反馈;
  • 持续集成,尽早排查集成引起的问题,降低集成所带来的风险。
3. 全员参与(Involve everyone)

— 这次上线好多bug,QA是怎么测的?!
— 那个xxx组在上线前发现了很多的bug,他们的QA真给力!

成也QA,败也QA…如果还是这样的认识,那是极为片面的。测试不仅仅是QA的事情,团队成员要一起为质量负责,软件开发生命周期的测试相关活动需要全员的参与。

全员参与的好处是利用不同角色的不同领域知识和不同的思维模式,不仅可以使得测试的质量更高,同时还能最优化利用测试资源,做到价值最大化。

推荐实践:

  • 自动化测试:QA和BA结对用DSL编写测试用例,QA和Dev结对编码实现测试,生成业务人员可读的测试报告;
  • Bug bash(bug大扫除):团队不同角色一起参与的一个找bug的测试活动
4. 测试作为资产(Tests as asset)

自动化测试帮助我们验证系统功能的正确性,好的自动化测试还有文档的功能,是宝贵的资产。如果每个项目都构建自己独立的自动化测试,没有跨项目共享,其浪费显而易见。

这个原则要求把自动化测试的代码跟产品开发的代码一起,当做资产管理起来,在不同项目间做到尽可能的复用。这笔宝贵的资产能帮助我们更好的统计跨项目的测试覆盖率,更好的优化测试。

推荐实践:利用版本控制管理工具把测试代码和产品构建代码一起管理,都作为产品的一部分。

5. 更快的交付(Faster delivery into production)

任何一个idea越快做成软件产品交付给用户,给企业带来的价值越大。

该原则要求我们把测试活动融入软件开发生命周期的每个环节,不要在后期进行长时间的集中测试;同时测试人员的关注点不再是发现更多的bug以阻止不符合质量要求的产品上线,而是把目标放在如何能够帮助团队尽快的让产品上线,让企业投资回报更早,也就是更快的赚钱。

推荐实践:自动化构建流水线、关注平均恢复时间、发布与部署解耦等。

Pipeline
6. 清晰一致的测试视图(Clear and consistent view of testing)

可视化的报告给客户和内部团队展示测试的状态和产品内外部的质量,对项目的质量和风险把控是非常有帮助的。不同项目各自采用五花八门的图表样式,将不利于项目间的信息共享和比较,无端增加复杂性,带来浪费。

因此,我们需要把状态报告做的尽可能简单、清晰,并且保持跨项目的指标一致性;同时,我们不应该为了让某个指标变得好看而改变我们的行为,整个报告要诚实开放,这样才能真实反映出项目的状况。

7. 优化业务价值(Optimize business value)

开发软件无疑是要给客户的业务带来价值,软件测试也需要为这个目标服务,测试要跟业务价值保持一致,帮助客户优化业务价值。要求做到:

  • 测试不仅是保险,不仅是保证软件质量的;
  • 要有目的的关注变化的特性,不要盲目的散弹枪式的对任何特性进行测试,要有优先级;
  • 要能帮助企业驱动新的特性和功能;
  • 帮助客户创造安全的尝试新点子的环境,提供快速的反馈。

推荐实践:

  • 基于风险的测试,根据业务优先级需要调整测试策略,在测试过程中尽可能规避给业务带来的风险;
  • 生产环境下的QA,通过收集生产环境的真实用户行为和应用使用数据,对业务的优化做出贡献。

评估模型以及在项目中的应用

评估模型就是将上述七条原则的每一条细化,列出该原则对应的实践和行为,并给每个实践或行为设定0-5分的不同评分标准,最后统计各个原则的总分,形成类似下图的结果报告:

Result Model

在项目中的应用

以Cristan分享的模型为基础,由Tech Lead和几个DEV、QA成立一个评估小组。

第一步:分别根据各自的理解给项目打分,结果是很有意思的,请看下图:

结果对比图

根据这些结果,可以看出大家的认识是不太一致的。

第二步:评估小组对模型中的每条细节进行review,做适当修改以更符合项目情况,并且在评估小组内大家达成共识。其中,所做的修改包括修改原有的实践评分指标、增加新的更适合项目和当前技术趋势的实践、删除过时的或者不符合项目特点的实践。

第三步:根据更新过后的模型指标对项目上的一个Team做评估试点,详细分析该team对应到测试原则各个维度的well和less well部分,由评估小组成员一起打分,得到该team的评估结果图。

第四步:根据评估结果并结合项目目标排定需要改进的优先级,制定出改进action,并更新给试点team执行。

后续:试点一个周期后再次评估,并重新review评估模型,再推行到整个项目。同时,周期性的进行新的评估和制定新的action,以做到持续的改进和优化。

总结

图片来自网络

应用程序的质量、测试的快速性、以及上线后轻松自信的更新服务的能力,是帮助企业业务价值最大化的关键因素之一,一直是我们所追求的。

基于测试原则的评估模型,可以帮助我们在追求这个目标的道路上少走弯路,帮助我们持续的改进,以驱动出更加卓越的软件。