敏捷开发的最大特点是：积极响应用户的需求，快速高质量的交付软件。
所以很多需求会按照用户需求程度以及模块之间的关联程度划分为多个迭代，这里的迭代你可以看做是一个小的完整的版本周期，每个迭代包含多个story，一个story相当于一个功能点，一个小的需求，而一个大的完整的发布版本一般由几个迭代版本组成。
OK，下面就开始写测试是从什么时候介入以及有哪些工作的。
1、story澄清会议（即需求澄清），参与人员：开发人员、资料开发人员、测试人员、TSE、需求接口人等。目的顾名思义就是让所有参与项目的人员更深入的了解需求，会议上任何参与者都可以发表疑问，对不理解的地方要及时问清楚，实践证明这个会议能尽早的发现开发人员遗漏掉的功能点以及功能实现的方式对其他模块的影响等。这个阶段开发输出的文档有：story验收标准。一般情况下对于功能复杂的模块，为了让大家跟直观的了解功能点，一般开发人员会准备demo演示，这样也更有利于测试人员测试用例的输出。
2、测试人员根据需求澄清时了解的需求点编写测试方案，然后输出用例，完成后发给开发人员、TSE对用例进行评审，编写人员根据检视意见修改用例，直到大家都认可了，再导入用例管理工具TMSS。
3、迭代story转测试之前，测试人员需要向开发人员分一部分基本功能的用例验证，用例通过后才可以转测试。转测试附带的文档包括：代码检视确认报告、测试部提供用例的执行结果报告、开发自测用例样例参考等。
4、测试人员执行测试，执行用例---提交bug---回归问题---story评价---关闭story
5、迭代结束，回归会议，开发测试人员一起进行此次迭代版本的优缺点分析等。
6、问题单逆向分析，分析每个问题单产生的原因，是用例设计遗漏、老版本遗留的问题还是修改引入的问题？如果是用例设计遗漏还需要补充用例的，如果是开发的修改引入比较多，那开发的麻烦就大了，是需要通报批评的。
7、测试质量报告，从发现问题多少、严重性以及聚焦的功能点等考虑给出A/B/C等级评价，并合理的给出建议，比如加强开自验、加强用例输出的标准等。
最后补充下这里为什么没有测试计划这一项，因为我们的计划大部分都是根据开发人员的开发计划来制定测试计划，而且这个计划都在迭代计划里面包含的。
好了，基本上大概也就是这些流程了，不知道算不算是标准的敏捷。上次在群里一个群友说他们公司也搞敏捷，他非常的不习惯，说在软件没有出来前就让写用例真是浪费时间，因为就像是在黑夜里走路一样，根本就不知道怎么写。这一点估计大部分人都有这样的感觉吧，包括我刚敏捷的时候也是，非常的痛苦，但是真正当我跟了两个版本后，适应了后发现其实也不难，而且挺能锻炼人的，写用例的时候需要不断的去和开发确认，从中还能了解到不少需求点呢。至于浪费时间，我倒一点都没觉得，因为当需求澄清完后，开发人员在编写代码的时候，我们测试人员基本都是等着转测试，而这个时候写写用例，岂不是更合理的利用了时间了呢？敏捷开发的周期一般都很短，一个月或者最多两个月时间，节奏非常快，所以大部分人都觉得有点累，然而虽然累点，但我总感觉我是真正的在做测试，不仅仅是鼠标点点罢了，虽然他也是手工测试，因为过程不同感受不同，---个人观点。
原文地址：https://www.cnblogs.com/classics/p/9747172.html