敏捷测试实践

接触敏捷开发模式有一年多的时间，在此我谈谈我对敏捷的理解， 以及我们项目是如何开展的。

我的理解是，敏捷的核心是人，每个人都是独立的个体，每个人都是平等的，没有谁领导谁，以及被领导的情况，每个人都是自发的去完成自己的task，就像鸡和猪的故事里面提到的，各司其职，以task为驱动。当然，敏捷是为了适应快速变化的需求，让客户尽早的看到自己想要的东西，这就要求每个迭代的周期尽可能短（2-4周），如果模块比较大，在一个迭代内做不完，就尽可能的分解成多个小模块。对于测试来说， Qa会与开发同时介入到需求分析，当进入开发阶段， Qa会设计测试用例（手工和自动化），开始准备自动化测试，自动化测试并不是等开发完成以后才开始的，在一个迭代内，开发完成后， 留给测试的时间就很少了， 所以应尽可能早的开展测试，比如接口测试，你可以提前准备数据，写好脚本，等接口写好后， 稍微修改一下就可测试。开发完成后， Qa要做的就是全面的测试（包括手工和自动化的）。 Qa在这还起到一个作用，就是能促进项目进度，在一个迭代内，前期主要是开发， 后期主要是测试，如果开发占用时间长的话， 留给后期测试的时间就会减少，所以QA会及时跟踪开发进度，比便尽可能早的开展测试。

我所在的项目组有6个人， 2个前台，2个后台，2个QA，还有1个UI设计（跨项目），项目曾达到过12人（4个前台，2个后台，6个QA），后被拆成2个项目组，基本满足2个匹萨原则。

迭代周期是2周，下面我将介绍在一个迭代内的主要会议及每个人的活动。

首先介绍两个主要的角色， ScrumMaster和Product Owner， Scrum Master可以说是项目经理，为项目扫清障碍，协调工作，解决技术难题，使项目效率达到最高。 Product Owner相当于产品经理，是项目工作的方向， 解决项目需求问题。

在介绍一些术语。用户故事（User Story）， 相当于需求，从用户的角度来描述所要实现的功能，

任务（Task），对一个用户故事进行划分，工作的最小粒度，描述每个人所要完成的任务，以时间衡量大小，一般在8小时之内，

Story Point， 描述用户故事的难易程度，取斐波列数据为值， 0, ½, 1, 3, 5, 8, 13.。。。这个值在Voting Meeting 上通过投票取得。这个值与时间没有绝对的关系，一般point越大，所用的时间越多，point一般不超过13，如果太大的话，就要把用户故事进行拆分。

Backlog，顾名思义， 这用来存放备用的用户故事的地方，越靠上的用户故事优先级越高，每次迭代开始前， Product Owner会去backlog里面拉一些用户故事到下一次的迭代中。

Burndown Chart， 显示这一迭代任务的完成情况，多少没完成，多少被Accepted，多少被Blocked等

最后主要的活动，

站立会议（Standing up meeting），每个人都会参加，描述昨天做了什么，今天将要做什么，遇到了什么问题等。

Plan Meeting， 每个人都会参加，包括Scrum Master和ProductOwner。一般在迭代的第一天发生，计划这一迭代内将要做什么，了解需求。

Voting Meeting，对每个US的难易程度进行投票，一般在Plan Meeting的头一天发生。

Demo Meeting，在迭代结束的时候，展示一个这一迭代内所做的东西。

Retrospetive meeting， 在迭代结束的时候，总结着一迭代内哪些做的好， 哪些做的不好，对不好的有哪些改进意见等。

大致的过程就是这样的，大家多提意见，谢谢！