问题描述：

　　1、敏捷开发过程中，相关的系统分析文档，设计文档。对应的测试分析文档，测试用例，是否需要按质量完成。

　　以前听过一个据说非常成功的案例，说在敏捷开发过程中，测试是使用一张纸的测试文档的，这张纸写清楚需要测试的点，然后开始测试。

　　2、关于需求，敏捷开发过程中，是否需求方只需要提供一个用户故事，比如“我作为PD（代表用户的意思），在某些场景中期望达到什么目的，所以希望产品如何如何。”而具体的详细设计在开发过程中边设计边讨论。

　　3、敏捷开发过程，是否可以等价于迭代式开发，比如，将某个产品分成几个部分，先完成某个部分，再完成其他部分，或者先做出一个基本原型。此原型能够实现基本功能，再次基础上继续完善其他功能。

　　这样的说法，本人基本赞同，但是会演变成另外一种情况，是需求人员自己都没想好整体产品的细节，先把想好的实现掉，再实现的过程中，再慢慢想其他功能。

　　精彩回答：

　　周金根：

　　1、这些文档视情况而写，对于框架平台的，设计文档可能会要求严一点；业务开发，可能

　　会只需要画几个类图而已。但是不管如何，测试用例我们是要求写的。对于测试用例质量的要求与传统敏捷开发一样

　　2、用户故事往往在实际开发中不够，因为价值的东西都是相对高层的东西，实现的时候还需要细化，可以使用用例、业务规则等形式细化，检验的标准是开发人员能够理解需要做什么，知道有哪些流程。详细设计肯定是在开发过程中去做的，但是在估时时会进行简单的设计，这个准确度是随着团队经验以及能力提高而提高的。

　　3、迭代开发并不是敏捷开发，它只是敏捷开发的一个方面。但说迭代，有没有固定周期、有没有价值目标是敏捷开发中的一些要素。

　　旗?：

　　1、文档要全，而且要保证质量，不过测试用例例外，看情况而来。

　　敏捷团队有建议的人数规模，测试人员应该着眼于关键点，一个全面的测试用例也常常被证明40%以上的用例是徒劳的。测试人员应该具备出色的test sense，根据经验能够判断出哪里是潜在bug、缺陷和主要数据流关键点，针对这些地方写测试用例，方便管理也能够判断数据流阶段性的正确。还有是TDD在开发过程中的保证，前期的需求讨论，测试人员参与程度应比开发人员更高，而系统架构确定、软件架构确定，都是由开发和测试共同决定，并在开发过程中出现需求变动，也保持软件架构的相对稳定，因为软件架构的改动对于测试人员来讲不单单是改动，很可能是重新来过。

　　2、这个不管是不是敏捷的，前期都尽量挖掘客户的需求，不留下任何潜在的需求。开发过程中的需求变动，根据经验来说，还没有遇上过需求不变的。这个其实是很无奈的，这是由客户方不够专业引起的，这也确实没有办法，只能是期望变动不是翻天覆地的。

　　3、开发过程差不多，或者说一样也可以，但敏捷方法对人员上的控制有一些建议，来使人员工作效率更高，交流成本更低。在这方面来讲，敏捷对于人的性格也有要求，不是每个人都适合参加敏捷开发，在搞人这方面上，敏捷只是提出了一些建议，佳实践还是得根据公司人员和公司内部结构的实际情况来定了。

　　欧阳清：

　　个人觉得在敏捷团队中，测试的难度和挑战比瀑布模式大的多。不断变更的需求，技术重构，从story到迭代版本的基本验证，测试...

　　因此测试的主要职责可以包括以下的几点：

　　1、需求的把握。测试要对不断变化的需求都能把握住，以PO（product ower）的标准来要求自己，敏捷的要旨是小步快跑，保证每一步都是对的，这样在团队中需要有人来保证我们做出来的东西是没有偏离需求的，这个角色只有测试胜任；

　　2、团队节奏的控制。不知道大家有没有做过敏捷项目，迭代不断的出现延迟，问题单越来越多，大家疲于根据计划加班。这个时候我们可不可以把下个迭代要做的事情暂时先停下来，留一个迭代或者半个迭代来解决问题，重新读下代码，找出那些异味的代码（smelly code）重写一下。找找我们流程中的问题并改进。这个事情也是由测试人员来提出比较合适；

　　3、质量控制。

　　这当然是测试的传统的工作，找出问题，让开发人员来解决。对于一个tester来说，质量控制Quality Control比质量保证Quality Assurence更重要。在敏捷阶段，不是说发现的所有问题都需要马上让开发人员去改，因为或许这个bug对应的需求还不明确，或许下轮的重构能自动解决问题，或许当前这个迭代使用的技术解决这个问题代价太大... 总之，这里是比较灵活的，也是比较考验测试人员的经验的，什么问题应该马上解决，什么问题可以讨论。

　　另外，关于质量控制比较重要的一点是分清楚测试阶段，这点在国内的公司很明显，单元测试，集成测试覆盖率低，或者干脆不做，或者做了没啥作用，每当大家回去做问题回塑，会发现很多问题应该在ut或者st阶段发现。那么这里的测试人员要不要去做这些测试，如果要做怎么做，这个对于不同形态的产品或许答案完全不一样。自己参与过的大型产品中测试人员都是做集成测试的，只是这个过程对测试来说比较痛苦，需要了解代码，有一定的编码能力。

　　另外，测试的产出这个有点不好界定，产出这个东东感觉是和流程比较强相关的，我在流程的哪个阶段必须产出什么东西。文档，测试分析，问题单，测试需求分析等等......这个也是和产品的形态有关，如果是轻量级的产品完全不需要做很多事情，或者很多事情可以合并来做，产出一份文档或者结果可以。

　　Rincolor：

　　前面的回答已经很完善了，我来补充下第二、第三个问题的看法：

　　第二个问题：“是否需求方只需要提供一个用户故事”，这样的说法有点问题，用户故事的产生需要PO和用户一起商议决定，其来源始于用户（需求方），但其产生过程实际是PO对原始需求的分析和拆解过程，倾注了其对需求的理解和判断，故对于团队来说，用户故事是由PO提供的，且PO和用户的讨论交流过程中，用户不一定需要提出完备的用户故事（当然用户能够且愿意和PO一起分析需求更好）。后半句的回答：详细设计是在迭代中细化的，但迭代计划会议时，团队成员应该对用户故事实现的概要设计达成一致（主要的设计思路和难点风险点，UI草图等）。

　　第三个问题：敏捷不等于迭代开发。相对于迭代开发，敏捷从形式上看更强调一种节奏感（即长期的稳定的团队生产力的输出、稳定的交付节奏、预期可见的交付物等）。“需求人员自己都没想好整体产品的细节， 先把想好的实现掉， 再实现的过程中， 再慢慢想其他功能”，整体产品的细节作为需求人员来说不一定需要都清楚，需求人员只要对产品的整体结构以及长远的规划有个大体的把握可以开始迭代了，而且其实现实情况往往是这样的，需求是在发展变化中的，需求的不断实现过程中往往会催生出新的需求，甚至会推翻之前的一些需求。刚开始做一个大而全的规划反而不好，这也正是敏捷灵活机动的所在。