scrum敏捷测试流程

什么是敏捷测试

敏捷测试的定义

首先敏捷测试是敏捷一种测试，原有测试定义中通过执行被测系统发现问题，通过测试这种活动能够提供对被测系统提供度量等概念还是适用的。在传统的测试定义上，还需要添加

敏捷测试是遵循敏捷宣言的一种测试实践：

l 强调从客户的角度，即使用系统的用户的角度，来测试系统

l 重点关注持续迭代的测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。

l 建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。

什么是Scrum？

Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会

敏捷开发和scurm学习笔记

软件开发的生命周期

A、软件生命周期（SDLC）的一般步骤包括：确定问题、可行性分析与开发计划、收集需求、分析与设计、编码开发、测试、安装、维护。

B、典型的几种生命周期模式包括：瀑布模式、演化模式、螺旋模式、快速原型模式、喷泉模式和混合模式等。

瀑布模式：只有当一个阶段的文档获得认可才可以进入下一个阶段。

演化模式：用户先给出待开发产品的核心需求，并且在核心需求实现后，再提出反馈以支持系统的最终设计和实现（相当于多个瀑布式开发）。

螺旋模式：在瀑布模式的每一个开发阶段之前，引入非常严格的风险识别、风险分析和风险控制，知道采取了消除风险的措施后，才开始计划下一阶段的开发（它是瀑布模式和演化模式的结合，并加入了两者所忽略的风险分析所建立的一种软件开发模式；它是典型的迭代式生命周期模式）。

过程开发模式（混合模式或元模式）：是把几种不同模式组合成一种混合模式，它允许一个项目能沿着最有效的路径发展。

敏捷开发的起源

1976年出现了第一部敏捷开发的书籍《软件度量》，阐述了迭代和增量开发实践。 2001年2月，敏捷开发宣言后成立敏捷联盟。

敏捷开发模式：敏捷开发生命周期的典型代表是XP编程(极限编程)，是把传统的系统设计和实

Jira+confluence 敏捷化流程

演讲者：单应青2015/10/13

敏捷流程系统：

项目管理系统Jira：http://192.168.1.233:8080文档管理系统wiki Confluence ：http://192.168.1.233:8090项目代码管理系统Fisheye ：http://192.168.1.233:8060测试用例管理系统Testlink ：http://192.168.1.233:8010简述敏捷&JIRA：

Jira项目敏捷流程：epic 项目计划-> userstory 需求->task 任务->bug 缺陷

项目需求阶段：

项目需求由产品经理负责完善：

?1）收集各部门业务需求，并与业务部门领导确认需求点；

?2）针对各业务部门需求和研发内部需求编写“需求文档”，并按照优先级进行排序；?3）对整理的需求安排开发计划（开发时间必须控制：2~3周）；

?4）在confluence新增需求详细说明文档，需求文档命名统一格式为：V2.1 需求文档（开始：2015/10/1至结束：2015/10/15）；?5）其中在jira上创建一个对应Epic，（注：Epic就是版本的根需求）；

?6）细分该Epic有多少个userst

最近把之前学习 Scrum 的资料整理为一篇文档，在接下来的团队和项目开发中，根据项目的情况引入 Scrum 的一些实践，提高团队成员之间的协作能力和项目的交付质量。 参考资料：

? ? ? ? ?

《轻松Scrum之旅—敏捷开发故事》、《敏捷无敌》 硝烟中的Scrum 和 XP 火星人敏捷开发手册 Scrum-Checklists 维基百科：http://zh.wikipedia.org/wiki/Scrum Scrum 工具

? ?

禅道 JIRA+GreenHopper

Scrum 中的角色

Scrum Master——项目负责人、项目经理

保护团队不受外界干扰，是团队的领导和推进者，负责提升 Scrum 团队的工作效率，控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化，他确保所有的利益相关者都可以理解敏捷和尊重敏捷的理念。 Team——开发人员、测试人员、美工设计、DBA等全职能性团队

团队负责交付产品并对其质量负责，团队与所有提出产品需求的人一起工作，包括客户和最终用户

产品负责人（Product Owner）

主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工

作成果。

流程管理员（Scrum Master）

主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直

接驱动开发。

开发团队（Scrum Team）

主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，

但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。

Scrum流程图

//------------------------

下面，我们开始讲具体实施流程，但是在讲之前，我还要对一个英文单词进行讲解。

什么是Sprint？

Sprint是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要

把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。

如何进行Scrum开发？

1、我们首先需要确定一个Product Backlog（按优先顺序排列的一

敏捷测试人员的十条法则

敏捷团队里的每一个人都是一名测试人员，任何人都可能承担测试任务。如果这种说法是正确的话，那么对于一名敏捷测试人员来说有什么特别之处吗？如果我把自己看做是敏捷团队的测试人员，这到底意味着什么？敏捷测试人员相比传统团队里的测试人员需要不同的技能吗？有什么日常工作指南吗？ 本章将讨论敏捷测试思维，看一看敏捷价值和准则如何指导测试，对测试人员如何为敏捷团队创造价值做一个概述。

1、敏捷测试人员的定义

我们这样定义敏捷测试人员：专业的测试人员，适应变化，与技术人员和业务人员展开良好协作，并理解利用测试记录需求和驱动开发的思想。敏捷测试人员往往具有优秀的技术能力，知道如何与他人合作以实现自动化测试，同时也擅长探索性测试。他们希望了解客户在做什么，以此更好地理解客户的软件需求。

谁是敏捷测试人员？她是驱动敏捷测试的团队成员。我们知道许多敏捷测试人员刚开始的时候在从事其他工作。开发人员可能会爱上测试而超越单元测试的范畴。习惯以敏捷方式工作的探索型测试人员也会被敏捷团队吸引。其他角色的专业人士，比如业务或者功能分析师，也可能具有同样的特质并做同样的工作。

技能很重要，但态度更值得关注。Janet总是说：“如果态度

敏捷宣言如何看待规划？

预先的规划和设计是开始进行开发前不可或缺的一个阶段

计划把任何产品列表条目放入一个迭代之前，必须先要签收其细节 对领域知识发展变化的流动进行度量，能够更好的指导进行总的工作 敏捷项目不需要规划，因为项目关注的是当前状态。

Scrum Master

是产品愿景的监护人 是团队的 scrum专家

控制团队列表上的条目优先级顺序 创建 调整 并和团队交流客户需求

Sprint 评审的主要目的是？

让利益相关者可以“向团队施压” 以确保Sprint能够有所产出。 让产品经理得以向利益相关者展现进度

让利益相关者审阅团队所构建的成果。并未后续计划提供信息。 让团队可以审阅他们的工作，并决定要做些什么来完成下一批条目

ScrumMaster要用引导团队和产品负责人之间的交流，哪个技术是有效的方法？

引导他们之间的协作式会议

教团队在谈话中使用业务需求和目标术语 教产品负责学习Spint中用到的技术 如上所有

如下哪项是sprint列表的主要的目的？

团队用来管理sprint中所花掉的那些小时数 ScrumMaster用于sprint管理进展情况

产品负责人从中了解团队为sprint承诺

敏捷宣言如何看待规划？

预先的规划和设计是开始进行开发前不可或缺的一个阶段

计划把任何产品列表条目放入一个迭代之前，必须先要签收其细节 对领域知识发展变化的流动进行度量，能够更好的指导进行总的工作 敏捷项目不需要规划，因为项目关注的是当前状态。

Scrum Master

是产品愿景的监护人 是团队的 scrum专家

控制团队列表上的条目优先级顺序 创建 调整 并和团队交流客户需求

Sprint 评审的主要目的是？

让利益相关者可以“向团队施压” 以确保Sprint能够有所产出。 让产品经理得以向利益相关者展现进度

让利益相关者审阅团队所构建的成果。并未后续计划提供信息。 让团队可以审阅他们的工作，并决定要做些什么来完成下一批条目

ScrumMaster要用引导团队和产品负责人之间的交流，哪个技术是有效的方法？

引导他们之间的协作式会议

教团队在谈话中使用业务需求和目标术语 教产品负责学习Spint中用到的技术 如上所有

如下哪项是sprint列表的主要的目的？

团队用来管理sprint中所花掉的那些小时数 ScrumMaster用于sprint管理进展情况

产品负责人从中了解团队为sprint承诺

敏捷宣言如何看待规划？

预先的规划和设计是开始进行开发前不可或缺的一个阶段

计划把任何产品列表条目放入一个迭代之前，必须先要签收其细节 对领域知识发展变化的流动进行度量，能够更好的指导进行总的工作 敏捷项目不需要规划，因为项目关注的是当前状态。

Scrum Master

是产品愿景的监护人 是团队的 scrum专家

控制团队列表上的条目优先级顺序 创建 调整 并和团队交流客户需求

Sprint 评审的主要目的是？

让利益相关者可以“向团队施压” 以确保Sprint能够有所产出。 让产品经理得以向利益相关者展现进度

让利益相关者审阅团队所构建的成果。并未后续计划提供信息。 让团队可以审阅他们的工作，并决定要做些什么来完成下一批条目

ScrumMaster要用引导团队和产品负责人之间的交流，哪个技术是有效的方法？

引导他们之间的协作式会议

教团队在谈话中使用业务需求和目标术语 教产品负责学习Spint中用到的技术 如上所有

如下哪项是sprint列表的主要的目的？

团队用来管理sprint中所花掉的那些小时数 ScrumMaster用于sprint管理进展情况

产品负责人从中了解团队为sprint承诺

敏捷开发团队管理

作者：cheny_com

本系列会专门从团队管理的角度，一方面将曾经提到过的内容加以贯穿，另一方面则会提及之外的一些未提及的内容，比如产品团队与开发团队的互动，测试团队与开发团队的关系与工作方式，等等，以供专门从事团队管理的读者借鉴。

出发点：结果导向

敏捷开发团队的外在行为是“结果导向”，而内在支撑则是“团队工作”（TeamWork）。 所谓结果导向，就是直指结果，而不拘泥于形式。

可以被拘泥的“形式”各式各样，比如方式、方法、流程、文档、部门、分工、职责??都是形式。这些形式本来是设立来帮助实现更好的结果的，但是如果拘泥于此，则可能起到反作用。

如果仔细审视敏捷宣言中右侧的内容，就会发现他们都属于形式，而非结果： ? ? ? ?

个体与交互 重于 过程和工具 可用的软件 重于 完备的文档 客户协作 重于 合同谈判 响应变化 重于 遵循计划

这些形式曾经保证了众多早期军工、航天、航空项目的成功，但若在任何行业任何项目——比如敏捷开发出现时的互联网行业——拘泥于此，就可能导致失败。

可怕的是，左侧的4条，也是形式而非结果。所以对敏捷宣言的正确理解是：在现今的多数行业中，如果以结果导向为出发点，则左侧的形式胜过右侧的形式。