作者归档:林冰玉

关于林冰玉

软件质量分析师,软件质量倡导者。

敏捷测试宣言与原则解读

敏捷测试宣言

解读

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

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

全程的测试介入

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

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

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

团队整体对质量负责

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

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

持续性的精准自动化测试

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

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

质量内建

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

敏捷测试原则

  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. 小结

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

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

业务价值驱动的测试

在《敏捷测试如何优化业务价值》一文中分享过测试人员对于如何优化业务价值的几个思考维度:

  • 从终端用户角度进行测试
  • 以业务为重点的测试
  • 映射业务影响
  • 关联业务指标

接下来,将跟大家分享业务价值驱动型的测试及其相关落地实践。

01. 业务价值驱动的测试跟传统测试的对比

业务价值驱动的测试和传统测试在以下几个维度的关注点都有不同:需求的关注、计划与执行、应对缺陷、测试人员角度、目标、生产力、指标的关注、有效性,详细对比如下表。

business-value-driven-testing-vs-traditional-testing

从表中可以看到:

  1. 业务价值驱动型测试要关注业务的需求,而不仅仅是功能需求;
  2. 业务价值驱动型测试以追求快速高质量的交付价值为目标,单纯的测试覆盖率和缺陷数量不再是考核的因素。
  3. 业务价值驱动型测试不是不关注缺陷,要以预防缺陷为主,正确跟踪缺陷并进行深入分析是帮助缺陷预防的必要的手段。
  4. 业务价值驱动型测试不再简单的根据数量来考核生产力,可以从多个维度评估测试的成熟度,以驱动出持续改进的方案。这个可以参考我的文章《聚焦测试,驱动卓越

02. 如何阐明业务价值

业务价值可能比较抽象,似乎不是那么好理解,况且要跟具体的测试活动对应起来更是有些难度。先给大家分享一个我们项目上的实践,我们通过下图所示的流程将业务目标、业务价值传递给团队:

articalate-business-value-practice
  1. 定期或者按需跟PO进行catch up,收集该时间段的业务目标、确定业务方向;
  2. 将业务目标跟系统功能关联起来,确认测试方面要关注的重心;
  3. 设计相应的测试方案,在方案里标明对应的业务目标;
  4. 跟PO沟通测试方案,收集反馈,并最终确认方案;
  5. 讲确认的测试方案更新给团队,确保团队所有角色理解一致;
  6. 方案执行后,对结果进行分析和总结,回顾做得好的和需要改进的,持续改进;
  7. 把总结分析的结果更新给PO,如此循环,一步步的优化。

每个项目的情况并不会相同,下图是一个比较通用的流程,可以根据项目团队具体情况调整:

articalate-business-value-general-process

03. 优化业务价值的测试实践

业务价值有效传递给了团队,那么就需要在测试实践中关注业务价值,从而帮助优化业务价值。下面的这些测试实践,都是可以帮助优化业务价值的:

共同创建测试方案

测试方案在创建之前,需要跟业务人员沟通清楚对应功能特性的业务目标、业务价值,需要跟开发人员沟通相应功能模块的技术风险,基于风险的测试才是最能体现价值的。

测试左移

测试左移的目的就是为了更早的澄清和确定需求,确保团队清晰一致的理解需求的业务价值,做正确的事情。

测试右移

测试右移利用对终端用户行为和生产环境数据的分析,帮助优化业务、优化质量内建过程,提高交付软件的质量。

精益测试

精益测试要求测试能够做到恰到好处,减少浪费,从而加速软件开发流程,快速交付。

渐进式的自动化测试
optimize-business-value-testing-practice

自动化测试要随着软件开发的进度渐进式的增加,而不是等功能开发完成再来写,可以提高ROI,让一开始就有自动化测试帮助提供反馈。

测试资产的管理和复用

测试资产跟产品代码一起用版本控制工具管理,尽量复用原有测试资产,不要重复造轮子。这样可以提高测试效率,加速价值交付流程。

增强的测试技术

采用智能测试技术和分析技术,提高测试的精准度和有效性,更高效的帮助业务价值的交付。

缺陷预防

利用对缺陷模式的分析,在软件开发生命周期每个环节更好的做好相应的测试工作,帮助有效的预防缺陷,降低成本,加速交付。

持续改进

整个软件开发生命周期的测试活动始终以目标驱动,实时度量,并持续改进。

测试人员能力建设

加强测试人员对于业务理解能力的培养,建立业务价值思维,提高业务敏感度,将有利于更好的理解业务价值。

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. 测试左移、全阶段的持续测试、测试驱动开发是质量内建成功的关键。

软件测试人员的职业发展之路

在《关于软件质量,大家都在关注什么》一文中,我们了解到软件测试领域新的关键趋势主要体现在以下几个方面:

  • AI的发展与软件测试
  • 敏捷与DevOps
  • 自动化测试
  • 环境和数据
  • 成本与效能
图片来自网络(https://unsplash.com/)
图片来自网络(https://unsplash.com/)

在这样的趋势下,测试人员的职业发展之路有什么变化呢?我们先来看看测试人员的技术发展方向有哪些。

技术方向

基于前面提到的新趋势,测试人员的职责由单一的测试软件系统是否工作、是否满足业务需求变得更加多样化,测试人员可以全流程参与软件开发,让测试活动贯穿软件开发整个生命周期。因此,测试人员的职业发展技术方向有:

  1. 敏捷测试专家
  2. 高级测试开发专家
  3. 专项测试专家
  4. QAOps专家

1. 敏捷测试专家

敏捷测试强调的是尽早测试和频繁测试,测试人员需要能够从需求分析阶段开始介入,全流程参与,跟整个团队一起实现团队为质量负责。对敏捷测试专家的技能要求有:

领域测试能力:测试人员需要丰富的业务知识、较强的业务敏感度和业务理解能力,熟悉各种不同类型的业务模式,包括新兴业务IoT、智能服务、区块链等,能够制定相应的测试策略,有效协助团队做好质量内建,实现交付价值最大化。

自动化测试能力:自动化测试是敏捷开展的必要条件,自动化测试技能是测试人员的必备技能。成为敏捷测试专家,要求测试人员了解不同的自动化测试框架的优缺点,能够指导项目自动化工具的选型;了解测试分层的思想,能够帮助团队制定合适的自动化测试策略;能够实现业务功能层的自动化测试,能够跟开发人员一起参与底层自动化测试(接口测试、单元测试等)的评审工作;了解持续集成工具,能够在持续集成流水线上配置和运行自动化测试。

沟通协调能力:敏捷测试要求团队为质量负责,测试人员作为主力,需要承担起质量的分析者和协调者的角色,要求有很好的跟不同角色沟通和协调团队合作的能力。

2. 高级测试开发专家

高级测试开发专家的必备技能要求有高级自动化测试、白盒测试、开发和平台构建能力,要求有很强的测试代码编写能力,能够自行开发自动化测试工具、搭建自动化测试框架、构建自动化测试平台和服务。

同时,最好还有AI应用的基础算法应用能力和自然语言处理技能,需要了解和掌握AI相关知识,以及AI知识在测试中的应用,以帮助实现自动化测试的智能化。

3. 专项测试专家

专项测试技能集包括安全、性能等跨功能测试技能,需要有扎实的计算机基础知识,了解安全问题的类型、安全测试工具的优缺点,能够提供安全测试解决方案;熟悉性能影响因素、性能测试关注点以及提供性能调优方案等。

专项测试技能也包括测试数据和测试环境的管理,要求熟悉虚拟化、云计算技术、数据匿名化等数据处理技术,能够提供测试数据和环境管理的方案。

4. QAOps专家

测试右移已经越来越被重视,这意味着测试活动需要右移到生产环境,需要测试人员跟Ops人员更紧密的合作,QAOps专家也应运而生。QAOps专家需要了解基础设施相关技术与实践,了解日志管理、日志监控以及日志分析技术,同时还要有用户行为分析能力,通过跟Ops的合作,充分利用生产环境的各种类型的信息来优化软件开发和测试流程,以实现最终优化业务价值的目标。

图片来自网络(https://unsplash.com/)
图片来自网络(https://unsplash.com/)

管理方向

管理岗位在新的趋势下有些将不复存在,一般在相对传统的组织架构下才会有,但是目前来看还是有相当的企业是适用的,在此也简单聊一下。根据每个公司的情况不同,测试人员直接相关的管理岗位也会有些不同,大体有如下这些:

  1. 测试组长
  2. 测试经理
  3. 项目测试负责人
  4. 测试总监

1. 测试组长

测试组长一般带几个测试工程师, 负责任务分派和人员管理等工作。除了必备的测试技能外,测试组长需要的管理技能有:

任务优先级识别能力:需要能够识别任务的优先级,并根据当前工作合理分配给不同的人去完成。

培养团队成员的能力:带领团队需要对团队成员进行培养和发展相应的能力,需要能够识别不同人员的自身特点,有针对性的培养相应的技能。

沟通协调能力:要带领好团队,较强的沟通协调能力必定能事半功倍,让团队工作更顺畅。

2. 测试经理

测试经理一般是管理一个测试部门,下面可能有多个测试小组。测试经理除了需要关注技术外,还需要关注部门的发展、绩效等。需要的相应技能有:

技术洞察力:测试经理需要对技术趋势和先进测试工具有较多了解,需要能够帮助团队确定测试技术和测试工具的研究和使用,以提高团队的工作效能。

风险识别能力:测试经理需要能够很好的理解业务需求、识别项目风险,负责制定测试策略和具体的实施方案,并能进行总结、报告,及时反馈项目质量状态。

培养团队成员的能力:团队成员的能力培养非常重要,测试经理跟测试组长一样需要这个技能。

沟通协调能力:测试经理不仅需要协调测试部门内部的各种情况,还需要横向跟公司其他部门进行沟通协调,沟通协调能力更加重要。

3. 项目测试负责人

项目测试负责人主要负责一个项目的质量保障工作,需要有跟测试经理相似的技能:技术洞察力、风险识别能力和沟通协调能力

4. 测试总监

测试总监是测试经理的延伸,属于质量部门的最高负责人,需要负责公司所有项目的质量活动,所要求的的技能跟测试经理类似。

图片来自网络(https://unsplash.com/)
图片来自网络(https://unsplash.com/)

易转型方向

除了测试直接相关的管理岗位外,根据测试人员的职业特点,以下两个岗位是比较适合转型的方向:

  1. 项目经理
  2. 产品经理

1. 项目经理

测试人员,尤其是敏捷团队的测试人员,涉及到项目质量相关的方方面面,自然有着能纵观大局的机会,成功转型项目经理的例子非常常见。相应的技能要求有:

团队管理能力:管理团队,包括人员风险识别、协调沟通等方面,需要掌握一定的人际关系相关的软技能。

客户关系管理能力:项目经理除了要搞定团队,还有最为关键的是要处理好跟客户的关系,客户关系管理技能特别重要。

决策能力:决策能力是一种综合的判断能力,即面对几个方案或错综复杂的情况,能够做出正确的判断并采取行动。

2. 产品经理

软件测试人员都需要能够很好的理解业务需求,一般都有很强的业务能力,转型当产品经理是一个不错的方向。产品经理相应的技能要求有:

用户需求挖掘能力:产品经理需要有包括挖掘潜在用户需求、确定需求优先级、构建用户画像的能力。

多维度思考能力:产品经理需要能够从基本维度、外在维度、核心维度和商业价值维度思考的能力。

抽象能力:产品经理不仅要能从事物本身进行抽象,还需要能够考虑不同层次的抽象;抽象完后,还需要把抽象的对象回归到展示层面,需要有抽象回归具象的能力。

图片来自网络(https://unsplash.com/)
图片来自网络(https://unsplash.com/)

三个转变

测试人员要培养前面介绍的技能,首先需要实现下面三个转变:

1. 对测试的认知

测试活动不仅是验证系统功能,可以更加的多样化。比如,测试左移就包括对需要的澄清和验证,测试右移则包括生产环境的监控和信息收集等。

测试人员不是质量的把关者,好的质量意味着要交付更多的价值,而不是没有缺陷那么简单,测试人员不再是发现缺陷越多越有成就,而是要想着如何跟不同角色高效合作,使得交付的产品能够优化业务价值。

2. 对技术的关注

由于测试活动的多样性,不能只关心测试相关技术,要把视野扩展到软件开发过程中各个环节接触到的领域知识和不同类型的技术,不同业务类型、技术架构和基础设施等都会对测试有不同的影响和要求。

3. 测试不可以独立存在

测试不能再以独立部门自居,需要跟不同的角色更多的沟通和合作。比如,需求分析阶段需要跟需求人员有密切的沟通,实现自动化测试过程中可以跟开发人员结对或其他方式的深度合作,生产环境下的测试需要跟Ops人员紧密合作等。

同时,测试人员对于系统所采用的技术架构、技术方案的设计思路都需要有所了解,从而更好的理解开发的工作、理解架构演进对于测试的影响,更好的开展测试工作。

最后

了解了发展方向,如何才能让自己的职业生涯更圆满呢?更多的学习建议可以参考我去年在BQConf的演讲《BQConf演讲:软件测试人员该何去何从》里提到的那几个方面:

  1. 确定方向,目标驱动
  2. 持续学习,把知识变成技能
  3. 勇于突破,系统思考

愿各位测试同仁的职业发展之路更加顺畅!

速度(Velocity)不背这个锅

01. 那些对速度(Velocity)的误解

图片来自网络(https://unsplash.com/)

误解1 – 点数跟天数对应?

用户故事的估点跟天数对应,1个点的故事对应2天的工作量;

统计每个用户故事所耗费的天数,如果点数对应的天数到了,先标记为“开发完成”,第二天Desk check就不用增加天数了;

为了赶进度,由结对改为不结对,原来结对的两人并行做不同的task,天数还是按照结对的情况来统计…

问题:

  • 虽然按照故事点来估算,但是每个点都跟天数对应起来,而且不是理想人天,是实际耗费人天;
  • 把这种估算当做一种承诺,要求故事需要在点数对应的天数内完成;
  • 用户故事的只是关注开发完成。

到底该如何估算?点数又该如何使用呢?

误解2 – 做不完了给用户故事涨点?

如果用户故事没有在预定的天数内完成,需要涨点,那么得先说服客户;

列出涨点原因并且跟客户解释不是一件容易的事情,团队有时候宁愿加班加点按照原来的估点完成也不要去跟客户解释…

或者,为了避免以后涨点的各种麻烦,在估算的时候多估一些点,导致估点不准确…

问题:

  • 开发团队的估算不应该受到外部因素的影响;
  • 虚估点导致的估算不准确失去了估算原本的价值和意义。

估算的意义是什么?什么时候需要调整点数进行重估?

误解3 – 速度驱动一切?

周报里的速度保持稳定,每周每对pair在2个点上下;

性能调优,客户觉得目前看不到价值不给点,所以团队就不做了;

技术改进,同样的,客户看不到价值不给点,就不做了;或者团队实在无法忍受想要改进,那就从别的功能用户故事里多估算一些点来留时间给做技术改进;

目前组内开发速度不够,用户故事都做不完了,生产环境的support能给别的组就给别的组做吧,那个太耽误开发进度了!

问题:

  • 一切围绕速度,如果比较顺利,满足了速度要求,团队可能就放松了,不一定会做更多的特性开发;如果不顺利,速度赶不上,那就可能面临着加班或者愁着怎么能给故事涨点以增加速度;
  • 不再是业务价值驱动,不会正常的从价值的角度去考虑工作的优先级,速度被严重的误用。

速度有什么用?又该如何利用呢?

带着这些误解中引发的疑问,我们一起来探讨一下。

02. 两种估算方法

图片来自网络(https://unsplash.com/)

1. 基于故事点的估算

故事点是纯粹对用户故事大小的相对度量,不应该跟任何的天数或者工作量等关联。

用户故事本身的大小属性不会发生变化,基于故事点的估算不会过期,不会受到团队技术能力和业务领域熟悉度的影响而发生变化。比如,一个点数为3的用户故事,它的复杂度相对于那个点数为1的基准故事来说不会发生变化,不管谁、也不管用什么技术来开发这个用户故事。

故事点的大小是指团队所有角色工作加一起的统一估算数值,需要多个角色一起合作讨论才能得出这个估算,因此,故事点的估算方法有利于帮助团队实现跨功能合作的行为。特别注意,不应该按照开发的点数、测试的点数去估算用户故事的大小,需要结合一起给出一个唯一的数值。

2. 基于理想人天的估算

理想人天的估算需要基于这样的假设:

  • 所估算的故事是唯一要做的工作
  • 所有需要的东西在故事开始前都会准备好
  • 故事开发过程中不会被打断。

在不考虑其他因素的情况下,这种理想人天的估算是类似于故事点的估算方法,同样是一种相对大小的估算。

理想时间跟耗用时间是不同的。比如一场NBA比赛的理想时间为12分钟一小节,但是实际比赛耗用时间需要比这个时间长很多,因为中间有暂停、死球等时间。理想人天的估算是基于理想时间的,在软件开发过程中会有多个因素导致实际耗用时间跟理想时间会有很大的不同,比如开会、讨论等。

理想人天的估算方法很容易让人根据一个故事所需完成的任务多少去估算,而不是从这个故事跟其他故事的相对大小角度去考虑;不同人估算的理想人天也会有不同,导致估算可能会不太准确。这在估算的时候是需要特别注意的。

在团队不熟悉故事点估算方法的初期,理想人天的估算方法更容易开始;理想人天的估算对于团队外部人员更容易解释清楚,也更方便预测速度。

哪种方法更好

从前面的介绍可以看到,两种估算方法各有利弊,都是对于用户故事大小的相对度量,不能跟实际完成天数关联起来。通常,更推荐使用故事点的估算方法,根据团队自身情况也可以选择采用理想人天。

03. 什么情况需要重估

前面提到的误解里对于用户故事没有在预定的天数内完成考虑给故事涨点,也就是重估,这种以进度来驱动重估的做法是不对的。没有在估算天数内做完可能有两个方面的原因:
1. 估算不准确,低估了;
2. 被其他工作所打断,或者团队技术原因导致进度较慢…

发现估算不准确的情况可能需要调整,但不能是因为做不完赶不上进度而调整。当所有用户故事的相对大小是准确的时候,不需要重估;只有当其中一个或多个用户故事的相对大小不准确的时候,需要调整该部分用户故事的点数大小。

我们来举例解释这个问题:

1. 不需要重估的情况

假设一个团队有4个复杂度相当的用户故事,原本估算均为3,预计能够在一个迭代完成的。在第一个迭代结束后,只完成了其中的两个用户故事,也就是完成了6个点,团队感觉这两个用户故事比预估的要大,想调整为原来点数的两倍,由6变成12;由于四个用户故事的大小相当,剩下的两个用户故事也需要调整为原来的两倍,剩下的工作量也变成了12,同样的可能还需要一个迭代才能完成。这样的重估就没有意义。

因此,如果只是发现用户故事实际耗费时间比原来预测的要多,但是故事的相对大小并没有问题的时候,不需要重估,而是要去回顾和分析耗费时间长的原因,并采取相应的措施去改进。

2. 需要重估的情况

假设团队由A、B、C、D四个用户故事,刚开始给每个故事的估点均为3。在开发故事A的过程中发现A比原来估算的值要大,需要调整为5才合适,另一个类似的故事B也是一样,需要调整为5;但是C和D跟它们不一样,估算值应该是准确的,还可以保持为3。这种情况下对A和B的重估是有价值的,因为相对大小发生了变化。

图片来自网络(https://unsplash.com/)

04. 速度的作用

速度是对团队的进度生产率的度量,可以通过计算团队在一次迭代中完成的用户故事所分配的故事点数的总和来得到。比如,完成5个3个点的用户故事,速度是15;如果完成了2个5个点的用户故事,速度是10。关于“完成”的定义不能只是到“开发完成”,而应该是“交付完成”,开发完成不能说明什么,可能后续测试还不能过关、有很多缺陷需要修复等情况。

速度可以修正计划的误差。估算把对工作量的估算和对工作时长的估算完全隔离开来,将必须完成的所有用户故事的点数总和除以迭代的速度,可以推算出迭代的次数,也就是项目持续时间。我们通过一个例子来看速度如何修正误差:

假设团队估算出项目中包含了200个故事点的工作,一开始认为可以在每次迭代中完成25点,也就是将用8次迭代来完成工作。但是,在项目开始以后,团队发现速度只能达到20点。这样,不用对任何工作进行重估,就可以正确的认识到项目需要10次迭代,而不是8次。

速度不会是稳定不变的。根据团队对技术和业务领域知识的熟悉程度,速度可能会增加;而随着团队人员调整,有新人加入以后,速度可能会下降。在故事点估算准确的情况下,速度正好是反映团队状态的一个参数。不应该为了保持速度的不变去调整估算的结果,而应该根据速度的变化来观察和分析团队的健康程度。

05. 估算与计划

估算是为了更好的做计划,通过估算推算出的持续时间是一种可能性,而不是对交付时限的一种承诺。估算的是用户故事固有的属性,其大小不应该受到交付时长的干扰。老马在文章《WaterfallProcess》里讲到敏捷开发里的计划应该是适应性的,而预测性的、承诺性的计划不属于真正的敏捷。我们需要认真做好估算,尽量的准确,利用速度并根据团队状态和其他项目因素来适时地调整、修正计划。

适应性计划(https://martinfowler.com/bliki/WaterfallProcess.html)

客户都会希望更短的时间交付更多的功能,但是不要让客户只把目光关注到进度上,要引导客户更多的关注交付的业务价值。因此,在考虑任务的优先级的时候,需要以价值为导向,而不是进度为导向。比如,重构等技术改进、性能调优、生产环境的支持,这些可能比新的特性开发带来的价值更大、有着更高的优先级。

06. 小结

  • 不管是故事点还是理想人天的估算方法,估算的都是用户故事的相对大小,跟实际完成时间没有直接关系。
  • 不能因为用户故事没有在预期的时间内完成而进行重估,只有相对大小发生变化的时候需要重估。
  • 估算是为了更好的计划,不能把估算当做一种承诺;速度是可变化的,可以用来修正计划的误差。
  • 始终要以价值为导向,更多的关注质量而不仅仅是进度,计划应该是可适应性的。

07. 参考文献

  1. 《敏捷软件开发实践:估算与计划》,作者:Mike Cohn,译者:金明
  2. 点之殇》,作者:冉冉,https://insights.thoughtworks.cn/story-point/
  3. WaterfallProcess》,作者:Martin Fowler,https://martinfowler.com/bliki/WaterfallProcess.html

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

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

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

四个维度
四个维度

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

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

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

下面来看两个例子:

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

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

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

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

02. 以业务为重点的测试

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

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

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

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

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

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

03. 映射业务影响

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

举例说明:

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

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

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

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

04. 关联业务指标

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

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

做到这个维度,需要:

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

05. 小结

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

一页纸测试策略

【摘要】测试策略文档通常是篇幅较长、文字为主的形式,编写成本较高,并且写完了很少有人去看,形存实亡。本文介绍可视化的方式,将测试策略用图来表达,并且在一页纸上搞定,这样的策略图非常清晰,关键信息一目了然,并且提供更大的讨论空间,防止僵化,真正能够发挥策略的作用。


“测试策略是什么样的?”

“测试策略嘛,还不是包括#&~+-=~*-+$这些…”

“你们项目的策略有什么特别的吗?”

“我们项目嘛,测试策略的内容有点多,从哪说起呢?”

前面那个场景有没有似曾相识?你是否清楚目前你们正在使用的测试策略是什么样的?

01. 常见测试策略

测试策略的内容与形式

我们都知道,测试策略包括以下两方面的内容:

  1. 测什么(What)? 测什么是指质量需求是什么、需要关注质量的哪些方面,比如应用的功能范围、性能、安全、易用性等非功能需求。
  2. 怎么测(How)? 怎么测就是采用什么办法来帮助系统实现质量需求,而不仅仅是手动和自动化的测试方法,也包括一切为质量保障服务的流程、环境、基础设施和人员等。

为了描述清楚要测的内容以及如何来测,测试策略通常篇幅较长的文档,包含多个章节;以文字描述为主,只加上少量的配图。

常见测试策略目录结构

【图片来自网络:https://wenku.baidu.com/view/17b9b03067ec102de2bd89ee.html

测试策略的痛点

长篇大论的文字给人带来居多不便:

1. 编写困难

篇幅较长的测试策略文档要写好还真不是件容易的事情,尤其是对于理工科出身的不是那么擅长写作的测试人员来说,更是比较麻烦,成本较高。

2. 不易阅读

长篇大论的测试策略文档,要从中快速找出关键信息可没那么容易,可能一不小心错过的细节就是最关键的部分,因为篇幅太长,通常不太重要的信息挺多的。

3. 维护、更新痛苦

策略文档不可能一成不变,这种篇幅较长的文档要更新和维护简直是噩梦。往往刚开始还好,随着时间推移,更新和维护越来越麻烦。

4. 失去了策略的价值

由于不易阅读,也不易维护和更新,事实上团队可能有很多人并不是很清楚策略文档上的内容,这样的策略文档形存实亡,不能真正起到策略的指南作用。

5. 反敏捷

敏捷开发强调的是缩短反馈周期,快速交付高质量的软件产品。花费太多精力编写、维护一份不能起到策略作用的长篇幅文档,显然是不利于敏捷的,也是非常痛的。

测试策略的重要性不言而喻,是否可以找到一种更好的表达方式,让测试策略不那么痛呢?Jamie McIndoe在“Testing Stuff – A One-Page Test Strategy”中首次提出可以把测试策略图视化,用一页纸来搞定。

我们都知道,图示化的表达方式直观、清晰,容易识别关键信息,并且易于记忆。如果能够用图示化的方法将测试策略在一页纸上搞定,一定非常棒。

下面一起来看看图示化表达的测试策略是什么样的。

02. 图示化测试策略

一页纸搞定

顾名思义,图示化就是用图来描述测试策略的内容,但并不是把原来文字描述的每个章节直接翻译成图。我们考虑用图来表示测试策略的各个关键组成部分,并且绘在一页纸上。

当然,一页纸的测试策略只是将关键信息以图示化的方式呈现出来,并不是整个测试策略的全部,在一页纸的背后是团队的充分沟通和对策略各个方面达成的一致认识,是需要团队一起来做很多工作的。这种高度简化的呈现形式,是为了给团队更多的讨论空间,一页纸也更易于修改,从而更能适应变化,真正满足需求。

基于Jamie McIndoe的可视化测试策略思想,我建议的测试策略图包含下列信息:

  • 指导性原则:团队为质量负责
  • 如何测:测试左移、精益测试、测试右移,涵盖测试流程、测试类型、测试方法等
  • 测什么:包括功能、性能和安全等

下面将以蓝鲸项目为例来介绍这几个部分的内容。关于蓝鲸项目,是一个历经10年的离岸交付项目,采用的是敏捷开发的模式,每四到五周一次发布,遵循敏捷开发的各种实践。

例如,蓝鲸项目的测试策略如下图所示:

蓝鲸项目测试策略图

各部分详细介绍

下面,我们来看看该测试策略各组成部分的具体含义。

1. 指导性原则

蓝鲸项目采用的是敏捷开发模式,质量不是某个单一角色的事情,团队为质量负责是项目质量保障的指导性原则,需要所有团队成员对此有一致的认识,人人都要有关注质量的意识。更多关于团队为质量负责的内容,请参考我的博客文章说好的团队为质量负责呢

2. 测试左移与质量内建

敏捷测试最关键的两点就是尽早测试和频繁测试(Test early, test often),也就是测试左移与质量内建的思想。

测试左移要求在需求分析阶段开始对需求本身的合理性进行验证,不仅要正确的构建产品,更重要的是构建正确的产品,这就需要把好源头需求这一关。因此,我们可以看到策略里的流程是从需求分析开始的。

质量内建则是在软件开发生命周期的每个阶段都有质量相关的活动,把质量融入到开发的每一个步骤,通过CI/CD等方式获取快速反馈,做好软件缺陷的预防,以减轻缺陷暴露太晚带来的大量修复成本。

蓝鲸项目的开发生命周期主要体现在下图的七个环节,每个环节都有相应测试活动的开展,并且每个活动都有不同角色的参与。

蓝鲸项目开发生命周期的测试活动

3. 精益测试

精益测试可以理解为以业务价值为目标,以尽量少的成本交付高质量的软件,也就是说测试要测在能体现价值的点上,要做到有效覆盖、减少浪费。蓝鲸项目的策略图里有两个框架帮我我们更有效的测试,分别是测试象限和测试分层。

测试象限

在Lisa Crispin和Janet Gregory合著的书籍《敏捷软件测试:测试人员与敏捷团队的实践指南》中,我们看到了敏捷测试象限的介绍。由于该象限框架所起到的作用不仅局限于敏捷的环境,我在这里称之为测试象限。

测试象限矩阵一共四个部分,称为四个象限。下侧是面向技术的测试,上侧是面向业务的测试;左侧是支持团队的测试,右侧则是评价产品的测试。

1) 支持团队的测试

支持团队的测试是用来告诉团队要写什么代码,起到明确需求、辅助设计的作用。其中,第一象限是面向技术的支持团队的测试,主要是TDD,帮助构建产品的内部质量,也就是代码质量的保障,比如单元测试和API测试等;第二象限则是面向业务的支持团队的测试,从更高层次以业务专家可以理解的方式确定系统期望的行为,做到产品外部质量的保障。

这两个象限的测试能够快速提供反馈信息,并确保快速的解决问题,既指导了功能的开发,又提供了防止重构和新代码的引入而导致不期望行为发生的安全网。

2) 评价产品的测试

程序员编写的代码可以使得左侧面向业务的测试通过,但也可能没有产生客户真正想要的东西,因此还需要第三、第四象限的评价产品的测试。

第三象限是面向业务的评价产品的测试,通过模仿真实用户使用应用的方式,帮助确认是否构建了真正需要的产品;第四象限是面向技术评价产品的测试,主要采用工具和相应的技术来评价产品的性能、健壮性和安全性等非功能特性,并且在开发周期的每一步都要考虑这些测试的开展。

这两个象限的测试中产生的信息应该反馈到象限矩阵的左侧,并用于创建新的测试来驱动下一步开发,形成良性的增强环路。

3) 测试象限的使用

象限的顺序跟测试执行的顺序无关,敏捷开发往往开始于客户测试(面向业务的测试)。与测试执行时机相关的因素通常有:

  • 产品发布的风险
  • 客户方对产品目标的要求
  • 是基于遗留系统的开发还是从零开始构建的新系统
  • 可利用的测试资源等

测试象限提供一种需要哪些测试来保障质量的思考框架,可以根据项目具体情况,结合考虑以开展对应的测试。策略图所示蓝鲸项目的测试象限体现的测试类型跟Lisa书里介绍的就不太一样,这是根据项目当前跟客户的合作方式、业务需求、质量要求等来确定的当下需要执行的测试,比如其中的安全测试就分为业务部分和技术部分。

测试分层

关于测试分层的思想,大家可能比较熟悉的是测试金字塔,主要是针对自动化测试,根据测试所能覆盖的范围分成不同的层。金字塔的含义是测试比例的多少,体现为底层单元测试较多,越往上层测试比例越少,呈现为金字塔结构。

越往底层的测试越接近代码,编写成本更低、执行速度更快、定位问题也更准确,但是离业务较远,不能很好的体现业务价值;越往上层的测试越接近业务,更能反应业务价值,但有着不够稳定、执行速度慢、实现成本较高的不足。因此,需要权衡利弊,根据项目具体情况,真实的目标来确定每层测试的比例。

至于具体的比例是金字塔结构,还是蜂巢结构或其他,并不是一定的,也不会是一成不变的,可能受到价值目标、痛点、质量要求、技术架构、技能水平等因素的影响。

蓝鲸项目的策略图里的是当前的测试分层结构,类似于蜂巢机构,那是因为基于微服务架构的特点,蓝鲸项目更多的自动化测试是保障服务间连通性的API测试部分,而对于单元测试和端到端测试的比例则都有减弱。更多的关于蓝鲸项目测试策略的详情,请参考我的博客文章微服务测试的思考与实践

4. 测试右移

由于软件系统所处生态环境越来越复杂,技术架构的演进、业务复杂度和数据量的增加、基础设施的发展带来更多的不确定性,软件系统的质量保障在测试环境已经搞不定了,我们需要把目光右移到生产环境。这就是测试右移的思想,其实也就是生产环境下的QA(QA in Production)。

生产环境有着不同于测试环境的特点,生产环境的QA并不是测试环境的QA的直接后延,而是需要利用其特点通过技术手段收集生产环境一切可利用的数据,包括日志、用户行为、用户反馈等,利用这些数据来分析和优化业务以及开发过程的开发和测试工作,形成一个开发过程与生产环境信息分析的良性循环系统。

蓝鲸项目在这方面做了不少工作,更多相关的详细内容,请参考我的博客文章生产环境下的QAQA与Ops通力合作打造反脆弱的软件系统

5. 测什么

之所以把这个放到最后介绍,是因为前面介绍“怎么测”的各个部分都已经涵盖到要测试的内容,蓝鲸项目的测试内容主要有:功能、性能和安全。

这三个方面的测试类似,都是从需求分析到生产环境每个环节都要考虑相关测试,做到质量内建、安全内建和持续的性能测试。关于功能方面的质量内建,前面【测试左移与质量内建】部分有介绍,对于安全和性能方面的策略,可以参考如下图示,由于篇幅有限,本文不做赘述。

蓝鲸项目的跨功能测试

03. 测试策略的正确打开方式

一页纸搞定的测试策略,优势非常明显,比传统策略文档更加简洁、清晰,关键信息一目了然。我们再来看一下测试策略图示化以后,还有哪些需要注意的方面。

目标驱动

虽然上网搜索能找到很多测试策略模板,但测试策略不应该是千篇一律的,不可以死搬硬套通用的模板。测试策略受到多种因素的影响,比如:业务价值、质量要求、当时痛点、技术架构、技术能力、工作重心、绩效要求、项目状态等等。

制定测试策略需要明确目标,综合考虑各种因素,权衡利弊,找到最适合自己项目当前状态的策略。也就是说,测试策略应该是目标驱动的。

演进式

项目处于不同阶段会有不同的质量目标,同时随着架构的演进和业务的发展,对软件系统的质量保障工作也需要随之调整。因此,测试策略还应该是演进式的、随需调整的。

图示化的测试策略是高度精简的,具有更大的讨论和发挥空间,在防止僵化、保持演进方面的优势明显。

04. 总结

测试策略举足轻重,内容很重要,需要以价值目标驱动,持续度量,并根据项目特定情况适时调整、演进。策略文档不要拘泥于形式,利用图示化的方法,直观、清晰的表达,是非常好的组织形式,能有效克服常规文字为主的文档所带来的痛,推荐大家使用。

05. 延伸阅读

  1. Jamie McIndoe的Testing Stuff – A One-Page Test Strategy:https://making.stuff.co.nz/testing-stuff-a-one-page-test-strategy/
  2. 说好的团队为质量负责呢:https://www.bylinzi.com/2019/07/14/everyone-is-responsible-for-quality/
  3. QA in Production:https://martinfowler.com/articles/qa-in-production.html
  4. 蓝鲸项目测试策略之微服务测试的思考与实践:https://www.bylinzi.com/2018/06/28/microservices-testing/
  5. 生产环境下的QA:https://www.bylinzi.com/2016/06/13/qa-in-production/
  6. QA与Ops通力合作打造反脆弱的软件系统:https://www.bylinzi.com/2018/10/15/qaops/

我的节奏,由我掌控

01

图片来自网络(https://unsplash.com/)
图片来自网络(https://unsplash.com/)

作为一个重度季节性过敏性鼻炎患者,每年的春季都是非常难熬的,2019年的春天感觉尤其严重,含激素的抗过敏药成为了最好的陪伴。这样的后果就是食量大增,体重飙升,到达了一个自己不敢正视的数值。

4月份,跟朋友一起大吃了一顿红油火锅之后,突然觉得非常腻,再也不想摄入大油的食物。其实是身体在给我发出警告,告诉我需要做点什么了。

2019年4月,开始了我的减重之旅。

方法:调整饮食+适量运动

我一直不喜欢节食,因为挨饿太难受。调整饮食结构很简单,主要是控制主食和油脂类的摄入,把我最爱吃的白米饭换成了五谷杂粮饭或者荞麦面,戒掉肥肉和大油食品,多吃瘦肉、鱼类、蔬菜和豆制品,适当控制饱餐程度、少吃撑。

另一方面是运动。为什么说适量运动呢?其实,我有断断续续跑步运动多年,但是效果不好,运动完不是舒服的感觉,而是很容易生病。后来我才知道,那是因为那些运动超出了身体的负荷。这回开始关注运动时的心率,跑步不再追求速度和跑量,而是控制在自己感觉相对舒服的心率范围。天气冷热适中的秋季,我坚持了两个月晨跑,其他时间保持每周一到两次运动。

八个月以来,我并没有挨饿,也没有很大的运动量,但效果是不错的:体重成功的减少到十年前的水平,睡眠质量更好了,精力也变得更加充沛。

这是我分享的第一个故事,也是我2019年最有成就感的一件事情。我真正找到了自己健康的节奏!

02

图片来自网络(https://unsplash.com/)
图片来自网络(https://unsplash.com/)

作为曾经在学生时代最害怕写作文的我,工作之后竟然喜欢上了写文章。技术文章可以没有太多的文采,只需要对技术实践进行总结和提炼,每一次写作自己都能有很大的收获。慢慢的写多了,看待事情的角度和深度都会发生变化,从而会引出更多的思考。

从2015年的第一届博客大赛开始,我保持每届大赛都有输出,但是写出文章首先需要积累,需要不少时间和精力去阅读大量资料、进行各种实践,每一篇文章的出来并不轻松。另一方面,每一次写作都有点即兴的味道,并没有太系统的体系,也没有很持续的节奏。

同样是在2019年4月,我创建了自己的个人博客网站,也开启了个人公众号。同时开始整理自己的知识体系,希望能够更加系统化的输出。

比不了洞见帝的更新频率,也比不了台长文章的访问量,我只是尽量持续的总结分享一些我的经验和想法。

八个月以来,感谢各位朋友的关注,收到不少对我文章的肯定反馈,给我带来很大的激励我前行的动力。

这是我分享的第二个故事,2019年的这段经历让我不再那么着急和焦虑。我渐渐的找到了自己成长的节奏。

03

图片来自网络(https://unsplash.com/)
图片来自网络(https://unsplash.com/)

刷刷抖音,逛逛朋友圈,还有各种励志鸡汤文,别人的生活是多么的幸福美好;而自己,面临的是工作、生活的压力,还有孩子的教育问题……就这样,人们都特别的容易焦虑,出现各种浮躁和沉不住气。

在这样的大环境下,找到并掌控自己的节奏,非常重要!

“我的节奏,由我掌控”是一个非常远大的目标,不知道什么时候才能实现,也许根本没法实现。但是,并不妨碍我们从能掌控的事情开始,脚踏实地,少些浮躁,尽力去做好自己能做的一切,包括学习、工作和生活。

写于2019年底,与大家共勉!

新一代支持BDD的测试框架Gauge+Taiko

BDD是什么

BDD,Behavior Driven Development,行为驱动开发。

如果你不是很了解BDD,可以参考我四年前的一篇文章说起BDD,你会想到什么,其中介绍过BDD的理论和应用。

我们可以这样来概括BDD:

  • BDD采用统一的领域特定语言(DSL)来描述业务场景和用户行为,让团队各个不同角色对业务需求有一致认识,从而做到更有效的沟通和更高效的协作
  • BDD的目的不是自动化测试,但是BDD可以有效指导自动化测试,基于BDD的自动化测试相当于维护了一份需求活文档,对项目需求的维护和管理非常有价值。

BDD应用框架之Cucumber

BDD的应用

BDD是为解决下面三个方面的问题而生:

  1. 协作:多个角色在一个团队,如何从一致理解需求开始高效协作?
  2. 语言:不同的角色业务、开发和测试人员分别说自己的语言,如何统一语言,更有效的沟通?
  3. 文档:编写和维护的成本都很高,如何低成本的维护一份有价值的文档?

Cucumber是一款支持BDD的框架,有助于帮助团队解决以上问题。

Cucumber支持用自然语言描述业务场景,需要遵循Given-When-Then的格式,这样就可以容易的对应到自动化测试的3A步骤Arrange-Act-Assert,从而实现业务场景的自动化测试。

Cucumber的理想是将可执行的需求规范、自动化测试和活文档有机的结合,如下图所示:

理想很丰满,现实很骨感。Cucumber在实际应用中的情况又如何呢?

Cucumber的痛点

Cucumber框架实现Web自动化测试包括两个部分:Feature(特性)文件和Step Definition(测试实现),在实际应用中人们普遍感觉到它的复杂。

  • Cucumber特别强调的是协作,Feature文件通常由偏业务的人员来编写,要求遵循Given-When-Then的格式。这种固定的语法对编写人员要求较高,写起来比较费劲,尤其对新人不友好,很多团队反映要写出好的Feature文件特别费时费力。
  • Cucumber支持多种语言实现测试代码,但它本身并不能实现自动化,对于Web自动化测试需要跟其他自动化工具结合,比如Selenium-WebDriver。实现代码不仅复杂,还有着元素定位难、执行时间长、不够稳定的痛点。

Cucumber-js+Selenium WebDriver实现的代码长这样:

Feature定义:

Feature: Google Search
  Scenario: Finding some cheese
    Given I am on the Google search page
    When I search for "Cheese!"
    Then the page title should start with "cheese"

Steps实现

Given('I am on the Google search page', async function () {
    await driver.get('http://www.google.com');
});

When('I search for {string}', async function (searchTerm) {
    const element = await driver.findElement(By.name('q'));
    element.sendKeys(searchTerm, Key.RETURN);
    element.submit();
});

Then('the page title should start with {string}', {timeout: 60 * 1000}, async function (searchTerm) {
    const title = await driver.getTitle();
    const isTitleStartWithCheese = title.toLowerCase().lastIndexOf(`${searchTerm}`, 0) === 0;
    expect(isTitleStartWithCheese).to.equal(true);
});

新一代BDD框架

蓝鲸项目曾经就是用Cucumber+Selenium WebDriver实现的UI层自动化测试,由于上述痛点,大家觉得UI自动化测试越来越难写,我也因此对BDD丧失了信心。

自从遇到了两款新的工具Gauge+Taiko,我又重新对Web系统的实现基于BDD的自动化测试燃起了希望。

Gauge

Gauge是一款开源的轻量级跨平台自动化测试工具,它的愿景是用更少的代码、更少的维护工作实现更多的自动化测试,有如下特性:

  • 采用Markdown格式,支持用自然语言编写Spec,语法自由,编写工作简单易上手,不管是对业务人员还是技术人员都很友好;写出来的文档格式清晰,很好维护。
  • Gauge本身可以实现对Web页面的访问和控制,支持多种语言,各种API封装的很好,代码实现部分比Selenium要简单很多,尤其对于编程技能不是那么强的QA来讲非常友好,易上手,代码的可读性也更强一些。

Taiko

Taiko也是一款开源浏览器自动化测试工具,它的特性如下:

Taiko – REPL
  • 交互式的录制体验。Taiko提供类似于irb的REPL,直接输入命令,可以看到浏览器执行结果,同时后续还可以把成功执行的命令直接生成JS代码,非常方便。
  • Taiko不仅提供常见UI自动化测试工具那样根据Id、name、CSS、Xpath等方式选择页面元素的功能,还提供智能选择器(Smart selector),支持直接根据显示的文本来定位各种类型的页面元素,同时还有支持上、下、左、右这种根据某个元素的相对方位去定位元素的API,很好的解决UI测试页面元素定位难的问题。
  • Taiko采用隐式的等待(Wait)方式,也可以手动设置超时时间以防有些访问等待时间过长。这种隐式等待相比其他自动化工具需要手动设置等待时间的显式等待方式要更高效、更稳定。
  • 与Gauge的完美结合:Taiko在REPL里执行的浏览器操作步骤,可以通过一个简单的命令直接生产Gauge支持的Step,只需要再去简单的加上step名称就可以,操作及其简单。

Gauge+Taiko的代码长这样:

Spec定义

# Google Search

This is an executable specification file. This file follows markdown syntax. 
Every heading in this file denotes a scenario. 
Every bullet point denotes a step.
To execute this specification, use
    npm test

## Finding some cheese
* Goto Google search page
* Google for "Cheese!"
* Page title starts with "Cheese"

Steps实现

step("Goto Google search page", async function() {
    await goto("www.google.com");
});

step("Google for <query>", async (query) => {
    await write(query);
    await click("Google 搜尋");
});

step("Page title starts with <content>", async (content) => {
    await title().then((pageTitle) =>{
        assert.ok(pageTitle.startsWith(content));
    });
});

总结

协作是人的问题,工具可以起到辅助作用,但是不能解决根本问题,过于严格的工具缺乏灵活性,反而阻碍了高效协作的可能。

Gauge不强调协作,可以作为自动化测试工具独立存在,同时又支持高效协作、支持实现BDD,是一款灵活性更好的框架。它的秘密武器Taiko是一款优秀的Web UI自动化工具,两者的结合堪称完美,让需求规范、自动化测试和活文档的有机结合真正成为可能。

本文只是将Gauge和Taiko跟Cucumber框架从对BDD的角度做简单的对比,更多的关于Gauge和Taiko的高级特性,请参考【延伸阅读】部分相关文章。

延伸阅读