我对敏捷测试的总结

刚来广州上班的第一份测试工作就是用敏捷开发模式。对此，想写一点关于自己一年半时间的敏捷测试总结：

一、晨会

敏捷开发模式中的一个重要部分我感觉就是晨会（只是对我来说），晨会的主要目的就是一个小组的人围在一起，说明一下昨天做了哪些工作，遇到什么问题，今天做哪个工作。很简单，但我觉得它的好处甚多：

1、可以锻炼我们的表达能力与锻炼我们演讲的勇气。很多做IT的人，一般话不多，只埋头于技术，不大注重自己的沟通、交际能力，而这种一堆人站一起，大家一起听你说，其实是一个很好的锻炼自己表述能力的机会。我原是一个很胆小的人，但是就是每天的晨会，让我的胆子渐渐大了一来，由原先害怕当着那么多人的面说话，到现在表达自然，确是归功于敏捷的晨会；

2、晨会上描述昨天做了哪些工作，遇到什么问题，可以将问题提出来大家一起帮你解决；说明一下今天要做哪些事可以每天给自己一个明确的目标，让自己做的事情更具方向感，更能很好的完成工作，也让手上一些紧急、不紧急、重要、不重要的事有一个安排顺序。

二、迭代

敏捷开发是一个迭代开发的过程，记得当时我们特别开了一会讨论敏捷开发过程中迭代的好处，我们总结了以下几点：

1、客户的需求是变化的需求，有紧急的需求，也有一些优先级比较低的需求。如果我们在拿到需求的时候，直接开发。到后来可能会遇到客户原先需要的需求已开发完成，却被暂时搁浅、而有些紧急的需求还没开发。这样不仅造成资源的浪费，也对客户造成诸多不便。迭代开发就是将一个版本周期划分为多个迭代，将一些优先级较高的需求排入最早开发的迭代，如迭代一、次优先级的放入迭代二或迭代三等等，这样就保证紧急需求先开发，而一些不重要的需求排入较后

2、对于一些不重要、不紧急的需求排入后面的迭代，如果客户变需求或不要此需求了，也可不用造成资源的浪费

三、故事墙

将一个需求分成多个故事与多个任务，开发由不同的人完成。每个人分一些任务和故事，这样更有利于分工合作

四、需求负责人（MDEG）ShowCase

与会人员有需求负责人、开发、测试、资料、测试分析。我非常喜欢这个，因为有时候光看MDEG写的0级方案还是有些地方不明白，在MDEG ShowCase的时候就可以提出来解决；这也是敏捷测试中将测试融入整个软件开发过程中最好的一个模块。开发那里，看文档可以因为理解上的不一致，导致开发出来的东西不是客户想要东西，MDEG是与客户唯一的接口人，在这里就给出一个相应的解决方案，让开发出来的东西最大程度上符合客户的要求。如果对方案有异议，MDEG也与客户确认后，再通知大家。

五、开发ShowCase

开发ShowCase就是一个转测试的过程。开发人员完成开发后，通知测试、MDEG、资料人员一起ShowCase。将主要功能模块演示给其他人看（主要是测试人员），确认所有功能都开发完成后，将任务交接给测试。这个过程完成一个工作交接；以前的开发完成后，直接通知测试去测，这可能导致有些代码没提交或者是一些主要功能模块都没实现就叫测试去测，浪费大家时间。

.....

先说这么多......未完待续