敏捷开发过程中测试团队的职责和产出是什么？
2012-01-19 17:48:52   来源：   点击：

13 个答案

• 答案 1：

  1.敏捷中文档轻量化，但是并不代表不保证质量。敏捷是减少不必要的文档，减少重复文档，敏捷中不会出现传统开发中分的那么细的各个阶段文档，你可以看下scrum中的backlog，这个文档可以从需求贯彻到测试整个过程。对用户故事，计划估算，实现方法，如何测试等内容都有描述。2.是提供用户故事，但是用户故事粒度比你说的会细化很多。敏捷过程中同样不允许出现需求蔓延情况。一个用户故事是能够带来用户价值的最小需求单位。用户估算不管如何实现，但是一定是会把需求说清楚。3.迭代只是敏捷的一个特征，而不是全部。敏捷更加重要的特征是通过短周期迭代而带来的团队不断自适应和调整。敏捷方法中需求人员在迭代1当然没有必要想好后续所有迭代的产品细节，但是一定要想好整个产品的功能规划，即对产品的高端规划和设计还是要有。

• 答案 2：

  1.文档的量我觉得可以少些，过多的文档是不符合敏捷开发的理念的，但是文档的质量必须得到保证，测试用例的覆盖一定要够，像你说的那个成功案例，虽然只有一张纸，恐怕上面也有着大量的测试用例吧2.我觉得虽然敏捷开发可以边开发边设计细节，但是明确的需求肯定是必须的，任何一个设计在确定时最好先想想这个设计是否能让迭代顺利。3.我觉得敏捷开发就是迭代式的开发，确实有可能出现边实现边设计的情况，这也是很难避免的，因为需求时刻都有可能发生变化。所以，测试人员应该及时跟上开发和需求人员的脚步，及时地更新测试用例，并提醒大家需求的变更是不是超过了限度，该控制控制了。

• 答案 3：

  1. 敏捷开发过程中, 相关的系统分析文档, 设计文档. 对应的测试分析文档, 测试用例, 是否需要按质量完成.这些文档视情况而写，对于框架平台的，设计文档可能会要求严一点；业务开发，可能会只需要画几个类图而已。但是不管如何，测试用例我们是要求写的。对于测试用例质量的要求与传统敏捷开发一样2. 关于需求, 敏捷开发过程中, 是否需求方只需要提供一个用户故事,而具体的详细设计在开发过程中边设计边讨论.用户故事往往在实际开发中不够，因为价值的东西都是相对高层的东西，实现的时候还需要细化，可以使用用例、业务规则等形式细化，检验的标准就是开发人员能够理解需要做什么，知道有哪些流程。详细设计肯定是在开发过程中去做的，但是在估时时会进行简单的设计，这个准确度是随着团队经验以及能力提高而提高的。3. 敏捷开发过程, 是否可以等价于迭代式开发迭代开发并不是敏捷开发，它只是敏捷开发的一个方面。就但说迭代，有没有固定周期、有没有价值目标就是敏捷开发中的一些要素。

• 答案 4：

  1，文档要全，而且要保证质量，不过测试用例例外，看情况而来。敏捷团队有建议的人数规模，测试人员应该着眼于关键点，一个全面的测试用例也常常被证明40%以上的用例是徒劳的。测试人员应该具备出色的test sense，根据经验能够判断出哪里是潜在bug、缺陷和主要数据流关键点，针对这些地方写测试用例，方便管理也能够判断数据流阶段性的正确。还有就是TDD在开发过程中的保证，前期的需求讨论，测试人员参与程度应比开发人员更高，而系统架构确定、软件架构确定，都是由开发和测试共同决定，并在开发过程中出现需求变动，也保持软件架构的相对稳定，因为软件架构的改动对于测试人员来讲不单单是改动，很可能是重新来过。2，这个不管是不是敏捷的，前期都尽量挖掘客户的需求，不留下任何潜在的需求。开发过程中的需求变动，根据经验来说，还没有遇上过需求不变的。这个其实是很无奈的，这是由客户方不够专业引起的，这也确实没有办法，只能是期望变动不是翻天覆地的。3，开发过程差不多，或者说一样也可以，但敏捷方法对人员上的控制有一些建议，来使人员工作效率更高，交流成本更低。在这方面来讲，敏捷对于人的性格也有要求，不是每个人都适合参加敏捷开发，在搞人这方面上，敏捷只是提出了一些建议，最佳实践还是得根据公司人员和公司内部结构的实际情况来定了。

• 答案 5：

  职责没有变化，但是意识要有很大的变化。意识需要从发现Bug转变为预防Bug出现，从越多发现Bug转变为越早发现Bug

• 答案 6：

  敏捷中根本没职责的概念，没有测试、开发的分工，两种角色可以互换。但是这种要求对现在我们的团队来说，有点困难 。文档，敏捷其实不等于无文档，只是要产出必要的文档，在一个小团队里，如果人员足够自主的话，充分的沟通是可以代替文档传递项目内容的。但是这个我们也尝试失败了，主要原因还在于人员问题。人员，我曾经问一个培训老师，敏捷是不是对人员要求不显著，可以通过团队来弥补一个新人的技术能力问题？虽然回答是肯定的，但是我们尝试过，其实敏捷对人还是有一定要求的，最少的要求是主动性强。敏捷和瀑布哪个好？其实一个开发模式没有自己的好坏，要看适合与否。瀑布模式会流程感强一点，而且留下的文档对于产品的长期维护还是有帮助的。敏捷中产出的文档太少，项目后期若不补充文档，产品长期发展是不利的。如果一个团队人员自主性不强，主动性也不好，能力普遍不强，其实这样子情况瀑布模式反而会让人觉得过程可控（感觉上的）。并且这种情况下，个人感觉瀑布和敏捷差别不大。

• 答案 7：

  我认为敏捷测试是为了让测试团队回归测试的本质，即验证功能性能，预防与发现Bug，测试不是为了出文档而进行的，测试的质量不是由文档来决定的，关键是测试的人员。敏捷测试正是强调参与人员的重要性。对于比较简单的场景，减化必要文档能提高测试的效率，但对于比较复杂的场景，添加必要文档也许可以提高效率。

• 答案 8：

  我觉得,不管是不是敏捷开发。对于测试团队的职责和产出是没有影响的。职责始终应该是根据需求来检验产品质量，保证最后递交的产品符合出口准则。产出应该就是各类测试报告。

• 答案 9：

  主要职责没有变化，仍然是以发现BUG为前提的测试，但是要多一种更积极的沟通意识，很多不是BUG的问题也要尽早发现尽早反馈。

• 答案 10：

  个人觉得在敏捷团队中，测试的难度和挑战比瀑布模式大的多。不断变更的需求，技术重构，从story到迭代版本的基本验证，测试...因此测试的主要职责可以包括以下的几点：1.需求的把握。测试要对不断变化的需求都能把握住，以PO（product ower）的标准来要求自己，敏捷的要旨是小步快跑，保证每一步都是对的，这样在团队中就需要有人来保证我们做出来的东西是没有偏离需求的，这个角色只有测试胜任；2.团队节奏的控制。不知道大家有没有做过敏捷项目，迭代不断的出现延迟，问题单越来越多，大家疲于根据计划加班。这个时候我们可不可以把下个迭代要做的事情暂时先停下来，留一个迭代或者半个迭代来解决问题，重新读下代码，找出那些异味的代码（smelly code）重写一下。找找我们流程中的问题并改进。这个事情也是由测试人员来提出比较合适；3.质量控制。这当然是测试的传统的工作，找出问题，让开发人员来解决。对于一个tester来说，质量控制Quality Control比质量保证Quality Assurence更重要。在敏捷阶段，不是说发现的所有问题都需要马上让开发人员去改，因为或许这个bug对应的需求还不明确，或许下轮的重构就能自动解决问题，或许当前这个迭代使用的技术解决这个问题代价太大... 总之，这里是比较灵活的，也是比较考验测试人员的经验的，什么问题应该马上解决，什么问题可以讨论。另外，关于质量控制比较重要的一点是分清楚测试阶段，这点在国内的公司很明显，单元测试，集成测试覆盖率低，或者干脆不做，或者做了没啥作用，每当大家回去做问题回塑，会发现很多问题应该在ut或者st阶段发现。那么这里的测试人员要不要去做这些测试，如果要做怎么做，这个对于不同形态的产品或许答案完全不一样。自己参与过的大型产品中测试人员都是做集成测试的，只是这个过程对测试来说比较痛苦，需要了解代码，有一定的编码能力。另外，测试的产出这个有点不好界定，产出这个东东感觉是和流程比较强相关的，我在流程的哪个阶段必须产出什么东西。文档，测试分析，问题单，测试需求分析等等。。。 这个也是和产品的形态有关，如果是轻量级的产品完全不需要做很多事情，或者很多事情可以合并来做，产出一份文档或者结果就可以。

• 答案 11：

  敏捷过程中，测试的主要职责应该是对每次迭代的产出物做验证，确保产出物满足产品设计需求，质量合格。

• 答案 12：

  1.关于轻文档的说法之前也看了些关于敏捷模型和方法的介绍性文章，对其中“轻文档”的概念是深信不以，自己误将“轻文档”理解为“无文档”了 ，这下出乱子了，在一段时间里需求和设计都是采用口口相传的方式，完全靠个人的理解和记忆力，使所有成员都处在混沌状态（毕竟这种方式对人的要求太高了，按照当前中国企业人员现状，大家都懂的...），最后连产品经理自己都不记得当时是怎么设计的了，后来改成了设计讨论优先，技术同学可以开始开发，此时交互设计师同步撰写设计文档，在产品开发过程中再不断完善这个文档。但是文档本身也必须讲究轻量级，将主要的逻辑和需求明确清楚，对于异常问题可以随着后续的开发进程进行补充。对于测试的一张纸的问题，我觉得一张两张或者三张的这种形式并不重要，重要的是测试用例是一定要有的，另外测试人员也需要对每个迭代所要达到的目标烂熟于心，这点个人觉得很重要。2. 关于需求的这个观点，其实我个人只能赞同一半了，赞同的是需求可以通过user story card进行传达，但是设计不是要等到开发时才出，而是要将本迭代需要开发实现的需求要同步讨论和给出设计来3. 这点赞同人月神话的回答，我再补充一点，“比如, 将某个产品分成几个部分, 先完成某个部分, 再完成其他部分, 或者先做出一个基本原型. 此原型能够实现基本功能, 再次基础上继续完善其他功能“的这个说法，我个人不是很赞同，敏捷的迭代应该是尽量将产品所要传达给用户的最有价值的功能先行实现，而不是简单的说是先实现几个部分再实现几个部分

• 答案 13：

  我越来越觉得 是中国的产品经理能力不够 对细节无法把握 也做不出原型 所以我很同意上面的观点 在反复中完善细节 其实如果原型交互做的好 真的可以减少文档 但中国会用工具的人太少了