难道你不想揭开敏捷测试的神秘面纱吗?

目录

前言

定义

1.四大关键点

2.12条敏捷原则

3.全团队方法

4.测试人员的作用

5.三的力量

6.尽早和频繁的反馈

7.用户故事

8.分解需求(开发用户故事需求所需的操作)

9.编写用户故事的技术(投资技术)

10.举例(史诗般的用户故事):

11.Scrum

12.Scrum实践

13.每日标准会议

14.燃尽图

15.速度图

16.回顾会议

17.看板

结语


前言

       本文为整理记录学习《软件测试训练营》- 敏捷测试的笔记,如果发现任何错误,请随时指正。本文部分图片来源于网络,如有侵权,请联系删除

定义

       敏捷测试是一种在敏捷开发过程中应用的测试方法,旨在通过持续的反馈和协作来确保软件质量

       敏捷测试强调与开发团队的紧密合作,及时发现和解决问题,以及快速适应变化

       敏捷测试的目标是确保软件交付符合用户需求,同时保持高质量和快速交付的节奏

1.四大关键点

       ①个人和互动优于流程和工具

       ②工作软件优于全面的文档

       ③团队和客户之间的关系比他们之间的合同更重要

       ④在传统软件或传统项目中响应变化而不是遵循计划

2.12条敏捷原则

       ①首要任务是在早期和持续交付有价值的软件的过程中满足客户的需求

       ②频繁地交付可以使用的软件,交付的间隔在几周到几个月之间

       ③工作软件是进度的主要衡量标准

       ④接纳不断变化的需求,即使是在开发后期。敏捷流程利用变化为客户带来竞争优势

       ⑤持续关注卓越的技术和良好的设计

       ⑥敏捷过程促进可持续发展。发起人、开发人员和用户应该能够无限期地保持恒定的步伐

       ⑦简单性意味着任何事情或任何活动在我的项目中不会给我带来价值,我就不会做

       ⑧围绕有积极性的个人建立项目,给他们所需的环境和支持,相信他们能完成工作

       ⑨最好的架构、需求和设计来自自组织团队

       ⑩业务人员和开发人员必须在整个项目中每天一起工作

       ⑪在开发团队中,最有效率和效果的传递信息的方法是面对面的交谈

       ⑫每隔一段时间,团队就反思如何变得更有效率,然后相应地调整和调整他们的行为

3.全团队方法

       ①让确保成功所需的每个人都参与进来

       ②小团队(3人至9人)

       ③团队位于同一地点,共享同一块空间

       ④质量是每个人的责任

4.测试人员的作用

       ①支持并与业务代表合作,帮助他们创建合适的验收测试

       ②与开发人员合作,就测试策略达成一致,并决定测试自动化方法

       ③向其他团队成员传授和扩展测试知识,并影响产品的开发

5.三的力量

       三的力量,指的是测试人员、开发人员和业务代表共同参与所有功能讨论的重要性。他们各自拥有独特的视角和技能,通过合作和交流,可以更全面地理解功能需求、技术实现和商业目标。他们的合作不仅可以帮助发现问题和解决挑战,还可以促进团队的协作和创新,三方共同参与功能讨论是推动团队发展和产品成功的关键因素

6.尽早和频繁的反馈

       ①利于团队专注于具有最高商业价值或相关风险的特性,并且这些特性会首先交付给客户

       ②有助于更好地管理团队,因为团队的能力对每个人都是透明的

7.用户故事

       编写用户故事是为了从开发人员、测试人员和业务代表的角度捕获需求,用户描述必须同时解决功能性和非功能性特征

8.分解需求(开发用户故事需求所需的操作)

       ①主题:Scrum主题是故事层次结构的最高层。它描述了有形产品的视图或抽象目标(如性能调优)品负责人进一步将主题分解为一个或多个史诗

       ②功能:功能是提供给客户的新功能。功能是产品的一部分,在一个非常高的水平

       ③史诗般的用户故事:中等规模的需求,这些需求是从一个特性分解而来的

       ④用户故事:包含单个操作的需求

       ⑤用户任务:开发用户故事需求所需的操作

       以上任务应涵盖开发,测试,集成和部署的各个方面

9.编写用户故事的技术(投资技术)

       INVEST投资,“I”代表独立性,“N”代表可协商,“V”代表有价值,“E”代表可估计,“S”代表简单,“T”代表可测试

       ①独立性意味着我们的用户故事可以在其他用户故事之外编写,并且仍然有意义

       ②可协商意味着用户故事应该足够通用,以便开发团队和客户可以解决并可能改变实现该用户故事的方式

       ③有价值意味着你的用户故事应该为客户带来价值

       ④可估计的意味着用户故事是可以估计的

       ⑤简单意味着用户故事足够小,可以在短时间内开发

       ⑥可测试的,这意味着我,们的用户故事可以被测试,我们可以编写它的验收标准,当验收标准完成时,这意味着我们的用户故事已经完成

10.举例(史诗般的用户故事):

       例:“作为一个顾客,我想付账,这样我就能很快付清欠款”

       这个用户故事可以分解成更小的,比如:

       “作为客户,我希望能够看到该订单中所有项目的账单,这样我就能知道我的订单将

花费多少钱”

       “作为客户,我希望在查看账单时能够选择“立即支付”选项,以便能够立即支付账单”

       “作为客户,我希望能够输入VISA和MasterCard信用卡的付款信息,以便使用方便的方法付款”

11.Scrum

       团队角色:产品负责人,scrum master和开发团队

       1.产品负责人:对开发团队来说被认为是客户的代表,有责任最大化Scrum团队工作所产生的产品价值,还负责有效的产品待办事项列表管理,包括:①制定并明确传达产品目标;②创建并清晰地传达产品待办事项列表项;③对产品待办事项列表项进行排序;④确保产品待办事项列表是透明的、可见的和可理解的

       2.Scrum master:

         ①Scrum Master负责建立Scrum指南中定义的Scrum

         ②他们通过帮助Scrum团队和组织中的每个人理解Scrum理论和实践来做到这一点

         ③Scrum Master对Scrum团队的有效性负责。他们通过使Scrum团队能够在Scrum框架内改进其实践来做到这一点

         ④Scrum Master是服务于Scrum团队和更大组织的真正的领导者

       3.开发团队:开发和测试软件的团队

12.Scrum实践

       ①冲刺:Scrum将项目划分为固定长度的选代(称为sprint)(通常为两到四周)

       ②产品增量:每个sprint都会产生一个潜在的可发布/可交付的产品(称为增量)

       ③产品待办事项列表:产品负责人管理计划产品项目的优先级列表,产品待办事项列表发展到待办事项列表细化

       ④冲刺积压:在每个sprint开始时,Scrum团队从产品待办事项列表中选择一组最高优先级的项目。因为是Scrum团队,而不是产品负责人,选择要在Sprint中实现的项目,所以选择被称为基于拉动原则,而不是推动原则

       ⑤完成的定义:为了确保在每个sprint结束时都有一个潜在的可发布的产品,Scrum团队讨论并定义了sprint完成的适当标准。讨论加深了团队对待办事项和产品需求的理解

       ⑥时间限制:只有团队期望在sprint中完成的任务才是sprintbacklog的一部分。如果开发团队无法完成某项任务则将其移回产品待办事项列表中

       ⑦透明度:开发团队每天在一个称为daily scrum的会议上报告和更新sprint状态。这使得每个人都能看到当前进程的进展

13.每日标准会议

       在每日标准会议中,团队成员会依次描述他们昨天的工作进展,今天计划要完成的任务,以及可能遇到的任何阻碍或问题

       这种会议形式有助于团队了解彼此的工作情况,协调工作计划,及时解决问题,以确保项目顺利进行。通过分享昨天的工作内容,团队成员可以互相了解进展情况,避免重复劳动或信息不对称

       简而言之,每日标准会议就是描述昨天做了什么,今天要做什么以及任何阻碍他的问题

14.燃尽图

       衡量迭代进度的一个重要方法,燃尽图绘制了迭代中和迭代后将要完成的工作量,当我们在迭代期间取得进展时,它会比较预期完成的工作和实际完成的工作

       在燃尽图中,横轴通常表示时间,纵轴表示工作量(通常是任务数量或工作量单位)

       当实际完成的工作量超过预期时,燃尽图上的曲线会向下走,表示团队进度良好;反之,如果实际完成的工作量落后于预期,曲线则会向上走,提醒团队需要加快进度或调整工作计划

15.速度图

       速度图显示了团队在整个冲刺期间的状态,是敏捷项目管理中的一种工具

       速度图通常以任务数量或工作量单位为纵轴,以时间(通常是冲刺周期)为横轴,展示团队在每个冲刺中完成的工作量

       在速度图中,每个冲刺的工作量通常以柱状图的形式显示,团队可以清晰地看到每个冲刺中完成的任务数量或工作量单位。通过比较不同冲刺的速度,团队可以评估自己的工作效率是否稳定,是否有提升或下降的趋势

16.回顾会议

       回顾会议(Retrospective Meeting)是敏捷项目管理中的重要实践,旨在评估团队在整个冲刺或本次迭代中的表现,以便在未来的迭代中以更好的方式工作。这种会议通常在每次迭代结束时举行,团队成员会一起讨论项目的进展、工作过程中遇到的问题、成功的方面以及改进的机会

       在回顾会议中,通常会涉及以下内容:
       1. 成功的方面:团队会分享在本次迭代中取得的成功和成就,以鼓励团队成员,并确定哪些实践是值得保留和继续的
       2. 改进的机会:团队会讨论在本次迭代中遇到的问题和挑战,找出导致这些问题的原因,并提出改进的建议
       3. 行动计划:团队会制定具体的行动计划,确定需要采取的改进措施,并确保这些改进纳入到未来的迭代计划中

17.看板

       看板(Kanban)是一种敏捷项目管理工具,其理念是通过可视化工作流程,优化增值链内的工作流程,提高工作效率和质量。看板通常包含三个主要列:To do(待办)、Doing(进行中)和Done(已完成),每个列代表了工作的不同状态,团队成员可以将任务从一个列移动到另一个列,以反映任务的进展和状态

结语

       感谢所有美丽动人、帅气十足的小伙伴们,能够关注并阅读本文。您们的支持和关注是我不断努力的动力和鼓舞,希望我们可以一起继探索、学习和成长!

  • 22
    点赞
  • 16
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值