敏捷测试

 

1. 敏捷开发测试背景知识

敏捷是什么？

一种软件开发的实践

开始于敏捷宣言

敏捷宣言

个体与交互胜过过程和工具

可用的软件胜过完备的文档

客户协作胜过合同谈判

响应变化胜过遵循计划

尽管右边的同样有价值，但是敏捷认为左边的更有价值。

1.1 Scrum过程

Scrum概览

- Scrum是一种兼顾计划性与灵活性的敏捷开发过程，原词来自于橄榄球中的“带球过人”。在橄榄球比赛的每次冲刺前，都将有一个计划安排的过程，但冲刺开始后则由队员在原计划的基础上随机应变。

敏捷测试流程图

- 不同于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段，Scrum将整个开发过程分为多次迭代（称为Sprint，冲刺），一般为期2～4周。

- 在日常工作时，产品负责人会维护一个按优先级排序的“产品待开发项”（Product Backlog），即从客户价值理解和描述的产品功能条目。

- 在每次迭代的第一天，召开迭代计划会(Sprint Planning Meeting)。产品负责人会逐一挑选最高优先级的部分进行讲解。团队可就需求细节、完成标准等进行询问，并逐条估算，放入本次迭代的开发任务中，直至任务量饱和。一旦迭代开始，这些任务将不会发生大的变化。

- 在迭代期内，团队将决定任务分配、所需的技术等，逐一完成任务。每天团队会进行一个简短的站立会议即每日立会 Daily Stand-up Meeting，沟通当前进度、下一步任务和当前存在的问题，以借助团队的力量解决。团队还维护一张“燃烧图”（Burn Down Chart），即所有任务的累积剩余时间随开发进程与日递减的图形，以观察和预测所有任务是否会按期完成。

- 在每个迭代的最后一天，团队会召集评审会(Review Meeting)，邀请产品负责人等参加，对已经完成的产品功能条目进行评审，后者做出判断并给出改进反馈。当天还会召开反思会(Retrospective Meeting)，对本次迭代的成功与失败做出总结，并在以后迭代中进行改进。

两个清单

`Product Backlog`

产品待开发项 Product Backlog是从客户价值角度理解的产品功能列表。

功能、缺陷、增强等都可以是待开发项。

一般以条目化的方式描述。

客户和用户必须能够理解。

描述怎样使用而非怎样制造。

整体上从客户价值优先级排序。

总工作量一般需要0.5～10人/天。

高优先级的条目应有较详尽的描述，低优先级的条目可只有一个名称。

 

`Sprint Backlog`

冲刺待开发项 Sprint Backlog是从开发技术角度理解的迭代开发任务。

>在简单的纯软件环境中，可以直接把产品待开发项当作冲刺待开发项分配到迭代中。

在复杂的开发环境中，可以把一个产品待开发项分解为Web/后台……软件/硬件……程序/美术……等开发任务。

三个角色

`Product Owner`

Product Owner（产品负责人）负责产品需求的提炼、条目化、优先级排序。

// 现实世界的产品负责人：

部门经理、产品经理、策划人员等都可能做产品负责人。

产品负责人是产品的指路人，必须对产品有长远的规划和深入了解，因此不能简单地选择销售人员甚至客户作为产品负责人。

大型产品如嵌入式产品和网络游戏，常常使用有层级的产品负责人团队，来解决广度与深度的矛盾，如产品总监-产品经理 / 主策划-策划团队。

 

`Scrum Master`

Scrum Master（Scrum“大师”）负责维护Scrum方法的秩序，并协助解决非技术问题。

// 现实世界的Scrum Master：

Scrum Master的工作方式是靠领导力(leadership)而非权力工作，因此首先应服务于团队。

一种人选是原来的项目经理转型，保留原有的管理和技术职能，但弱化指派任务、下达时间点指令等内容，而增强其组织协调能力。

另一种人选是企业原有的过程改进人员，协助不太了解Scrum的项目经理按照Scrum的方法工作，可以每人负责多个项目，接近全职的Scrum Master。

 

`The Team`

Team（团队）以“自组织”的相对扁平方式进行管理，负责完成开发工作。

// 现实世界的开发团队：

实际团队常常不是“扁平的”，而是仍有项目经理、小组长等职位。

工作中他们以“共同估算”、“跨职能工作”、“共同跟进”等方式自组织工作，而不是完全依赖层层指令。

项目经理、小组长的领导、指导、协同职能大于其指令职能。

四个仪式

`计划会：Sprint Planning Meeting`

// 迭代计划会在每个迭代第一天召开，目的是选择和估算本次迭代的工作项。

产品负责人逐条讲解最重要的产品功能。

开发团队共同估算故事所需工作量，直到本迭代工作量达到饱和。

产品负责人参与讨论并回答与需求相关的问题，但不干扰估算结果。

 

`每日立会：Standup Meeting`

// 队员认领任务（或由组长协商分发），独立或与别人一起完成任务。

团队内部利用每日立会来沟通进度。

开发团队利用燃尽图来展示整体进度。

如无特殊原因，迭代期内无变更。

 

`评审会：Review Meeting`

// 小组向产品负责人展示迭代工作结果。

产品负责人给出评价和反馈。

以用户故事是否能成功交付来评价任务完成情况。

 

`反思会：Retrospective Meeting`

// 在每个迭代后召开简短的反思会。

总结哪些事情做的好，哪些事情做的不好。

制定改进计划。

1.2 用户故事

• 用户故事：描述具体的需求的卡片。

  按作为一个……，可以……，以便……样式和思路写成的用户需求，就是用户故事。

  这种样式是技法层面的东西，它保证了无需太多思考，用户故事中即可全面包含角色、功能、价值这三个要素。

要想写好用户故事，要改变那种面向功能而非客户需求的纯技术观念。

角色：切记不要总是写“作为一个用户”，而是要把用户区别对待。这样才能更好地理解他们使用什么功能，如何使用，为何使用。

功能：即用户能亲自执行的操作。应区分用户操作和产品功能之间的关系，因为产品功能可能也提供了用户所需的价值，但却极可能不便于操作。

价值：是完成操作后，客户所得到的好处。价值里边，常常要带有一点褒义词，或有一些吸引人的内容，比如“高效地……”“……可以节省话费”等。

• 需求分解为任务，由开发完成，实现功能。

• 需求费解为用例，有测试完成，验证功能。

1.3 敏捷日常跟进

`看板`

看板又叫任务版，对于Sprint进度的沟通，看板是一种简单而强大的方式。从形式 上看，看板显示的是Sprint冲刺待开发项随时间的进展状态。

故事板简单说就是把所有正在工作的内容，张贴到一个板状空间中。

看板（Kanban）一词来自日语，指的是制造业中的一种可视化方法，有相当复杂的思想和流程。由于两者看上去很类似，两个词汇经常混用。

 

`燃尽图`

>在Sprint执行的每一天，团队成员都要更新未完成任务的剩余工作量估算。我们可以创建一个表来是使数据可视化，就是燃尽图

根据整个团队的剩余工作总量，每天进行更新，就可以得到燃尽图。

2. 计划会

2.1计划会准备的内容

// 每个人准备做（测试）哪几个需求？

`手工

自动化测试UI

APP测试`

// 自动化测试（验收、回归、批量）方案？

// APP测试

`Android模拟器

Android真机（adb） iphone真机（手工）`

2.2计划会的步骤

PO 产品负责人 产品经理

// 业务背景介绍

1.整体的介绍产品的业务

产品可以做什么事情

产品有多少种平台：Web (B/S)、PC (C/S)、Android、iOS

2.产品有什么样的版本：免费版、PRO版（付费）

3.有多少种竞争的产品：Worktile、明道、Leangoo、teambition、trello

 

// 准备 product backlog （更新产品待开发项）

产品经理登录禅道

创建产品

提需求，构成产品待开发项

 

// 挑选 sprint backlog （选择该迭代要做的 冲刺待开发项）

项目经理登录禅道

创建迭代（项目）

关联产品

关联需求（从第二步创建的需求中，选择一部分，构成冲刺待开发项）

团队设定

 

// 讲解 sprint backlog 的具体需求（用户故事）

产品经理讲解每一个被关联的需求

确定验收标准

PM 项目经理 Scrum Master 敏捷教练

// 确定 sprint 周期长度 1 week？ 2 weeks？

2周/Sprint

 

// 认领 sprint backlog，预估时间

需求（开发，xxx，多少时间；测试，xxx，多少时间）

项目经理登录禅道

选择本次迭代

打开需求

依次选定每一个需求 | 编辑

编辑备注：开发：XXX，2h；测试：YYY，3h

 

// 确定 评审会的 日期

开几次？

每次评审什么需求？

确定演示会的次数

确定每次评审会的需要评审的需求

确定每次评审会的时间

 

// 每日立会开会时间

09:05每天

计划会输出文档

• sprint 开始日期，结束日期

• sprint 周期

• 每日站会时间

• 评审会表格：日期、评审需求

3. 每日立会

3.1汇报内容

1.我昨天做了什么事情（完成什么需求的测试？开发？）

2.我今天准备做什么事情

3.我目前有什么用的困难（挑战）

4.缺乏数据库权限

5.缺乏服务器系统用户权限

6.技术问题

7.业务问题

8.时间问题

3.2燃尽图

统计需求：产品本身的需求（或者需求分解的任务总数） + 产品级对应的测试任务数

• 每日站会中，每个团队成员需回答3个问题。通过这3个问题，我们可以得到两个层面的信息：

团队内信息的透明度，整个团队的进度以及距离Sprint目标还有多远；

同时是否存在障碍

每天团队都会得到反馈，并可以根据得到的反馈做出调整。

• 如果不是每天开站会，那么就可能：

  1.团队内有些信息会隐藏。有的团队反映说团队小（比如4-5人）并且大家都坐在一起，随时都会沟通，没必要每日站会。而实际上团队内的沟通在多数情况下只有相关2-3人一起，而不是整个团队一起。因此每日站会还是非常有必要的（同步、透明化信息）；

  2.团队错过最佳的调整机会。每日站会中，团队可以得知距离Sprint目标有多远，是否存在障碍或者问题。尤其存在障碍时，需要整个团队共同努力，来想办法解决。这不是说发现问题了只有在每日站会才说出来，而是发现问题马上暴露，但每日站会需要正式得让整个团队得知情况（一般这类信息容易在2-3人之间讨论）；

  3.团队没有仪式感。每日站会可以让团队形成规律，每天固定时间、固定地点所有团队成员凑在一起同步信息和进度，很容易团队成员可以形成仪式感，这是一个非常重要的事情。

4. 项目迭代

Web手工测试准备

自动化测试环境搭建

APP测试准备

SVN配置

Measure

Measure