敏捷实践 敏捷测试漫谈

CKL的思考 · 2021年07月28日 · 2090 次阅读

在聊敏捷测试之前,有必要先聊聊敏捷。最近几年,XXOps 不断的提起,被不断的赋于新的含义,DevOps,TestOps,SafeOps 等等。现在的软件工程不说敏捷都不好意思提。在早期的瀑布式研发模式下,软件工程定义好了研发环节的各种要求,引入了比如 PMP 项目管理,比如 CMMi 成熟度模型等内容,这是很明显的 “工程思维”。工程思维要求我们必须按既定的规划(需求文档),根据工程设计图(概要设计、详细设计)进行施工(编码),然后进行严格的验收(测试),最后交付(发布运维)。看着好像没有什么问题,也一直执行了好多年,对吧(类比如下图)。

但是,软件研发和工程研发是不一样的。比如建筑工程,必须严格按照设计图纸来施工,出现偏差后果很严重,但是软件一定要按概要设计来么?在编码过程中如果发现了更好的设计模式,更优秀的框架,为什么不能引入呢?后来,有一群开发人员聚在一起讨论和研究这个问题,倒腾出来了敏捷宣言(本文不展开讲,有兴趣的自行查找),以服务的思维重新梳理了研发模式。服务思维的核心是:用户满意。在服务的过程中,我们需要的是拥抱变化、持续反馈并加以修正。最终让用户满意,让市场满意。需要注意的是,敏捷的最终目标不是快,而是持续反馈(一个典型的例子,就是之前有人说汉武建方仓,是敏捷实践的最佳案例,看完就想打人,那是标准化的威力)

回到敏捷测试,敏捷测试并不是一种新的测试方法(白盒测试、性能测试之类的),也不是一种新的测试技术(探索性测试)。在我看来,敏捷测试更多的是一种思维上的转换,而不是实施层面的问题。原来的测试方法和测试技术,在敏捷测试中一样可以应用,并没有区别。我对敏捷测试的理解有以下三点:

敏捷测试是一种有效的反馈,越早越好

我们都知道问题越早暴露越好,所以我们提倡测试左移,推行 ATDD,BDD 等等,都是为了更早的发现问题,并快速反馈,让团队减少返工和浪费。
在需求澄清阶段,需要注意:以终为始,确保需求输入质量,首先要讲解业务目标,其次操作及操作流程,再次是业务规则。需求不是方案,而是用户的价值。只有我们从价值开始,层层分解,从业务到实现层面充分沟通,才能保证后面交付的质量。有人会觉的测试人员无法接触到真正的客户,无法理解什么真正的用户价值,认为这是产品经理需要做的事。在这个阶段,测试人员可以做两件事:

  1. 尽可能多的参与产品的规划,了解需求背后客户真实的想法(用户群反馈、竞品分析、自己真实使用感受等等都可以获取价值)
  2. 协助产品经理完成业务流程的梳理,评估需求对现有流程的影响,是否存在互斥的因素,新业务对原有业务是否有影响。是否有遗漏的场景等等。 如果 TDD(Test Driven Development)在团队的落地可能会存在困难,我们可以尝试使用验收测试驱动开发(ATDD,Acceptance Test Driven Development)在需求分析时就确定需求(如用户故事)的验收标准,并记录在故事卡片上。从需求的角度去准备验收标准和测试用例。同样可以保障从开发的开始就有较高的质量

自动化测试是敏捷测试的一种必要手段

想要做到快速反馈,必然要依靠大量的自动化测试。

新模式的测试金字塔下,除了顶端的探索性测试、体验测试等活动外,其它的测试均可做到自动化测试。最好能够做到端到端的自动化测试,保证更多的覆盖面。如果暂时做不到,至少接口测试和服务间集成测试需要保障,否则无法保障交付质量。需要警惕的是不要让自动化测试流于形式(如没有断言,不可被 CI 集成,事后补用例 等等)。持续多个迭代后,好的自动化自动化测试 ROI 会让你感到惊喜。
Vol.3

敏捷测试必须是一种可持续的活动

在开展测试活动(不管哪类测试)时,我们可能会受制于各类客观因素,如无法快速构建测试环境(特别是微服务的框架下,如何快速构建对应分支的测试环境成为很大的一个痛点),无法快速生成测试数据(业务链路长,前置数据准备要求多,数据结构复杂等)。这些问题需要整个研发团队一起努力解决,业内现在也有比较成熟的解决方案可供参考(如环境标签、链路配置等方案解决环境问题,数据工厂、数据中台等解决全平台的数据生成问题)。
同时,我们要保证在任意节点,都可以快速开展测试(自动化脚本能够区分颗粒度的被不同研发阶段调用),只有可持续的测试,才能持续的反馈,比如开发提交代码后,就能触发单元测试,进行分支合并后,进行接口测试。
综上,敏捷测试不是测试手段的创新,是思维的转换,需要我们更早的参与测试,更早的提出反馈。基于以上三点理解,我们就可以有效的构建起团队的质量文化,也就是所谓的内建质量,当每个环节的产出都能够得到有效的保障,就可以减少等待,让研发环节尽快的流动起来,最终交付到用户手中,得到最终的反馈。

补充:全文多处提到反馈。这是敏捷思维中非常核心的观点。如果不能及时反馈,我们就无法修正问题,交付的价值就可能产生偏差。敏捷最大的好处就是缩短了反馈路径。其实生活中,我们也要尽可能的做到快速反馈,这样才能更好的解决问题

暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册