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 周期
表格【sprint backlog 列表；任务认领 + 估算】
每日站会时间
评审会表格：日期、评审需求

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

敏捷测试