敏捷测试如何开展？（2010-1-11）（获奖名单已公布）

wpyily

原帖由 dennyqiang 于 2010-1-13 22:27 发表
真正接触敏捷开发也有两年了，由于不太喜欢那种按部就班的工作方法，觉得瀑布模型太臃肿，CMMI太繁琐。所以一直在寻找一种更加灵活的方法，当我们在项目中真正使用到了Scrum这种敏捷开发框架，突然发现事情原来是可以 ...

敏捷就是加班，无止境的加班。
客户的需求不知道什么时候就发生改变，需求一变，开发的代码就变，新的问题接踵而至。开发在有效时间内完成了工作任务，那么苦了的还是测试，因为交货时间卡在那里。
敏捷=杯具（发个牢骚）

angle-ying

比较孤陋寡闻 刚刚听说敏捷型测试 我感觉自动化还是最重要的 这一点满足了 对测试就有很大的帮助了 需求明确也是最重要的了

zhuwenfeng

学习了！
成本（时间、人员、工具）、效率（速度）、效度（效果）
——所有的测试方法、流程、规范、工具都是为了上面的三点服务的。
20#所说的团队，
成员个个经验丰富、身怀绝技、有用不完的奇思妙想，执行力超强、成员之间高度默契.。。。。。
这时就一定要用敏捷吧？
----------------------------------------
这里也让我们看到一点，敏捷团队里，成员素质是最关键的。

mengluoyong

学习下~

archonwang

自己感觉，敏捷团队的人员素质是基础。如果基础不好，敏捷是很难开展下去的。

原帖由 zhuwenfeng 于 2010-1-14 14:12 发表
学习了！
成本（时间、人员、工具）、效率（速度）、效度（效果）
——所有的测试方法、流程、规范、工具都是为了上面的三点服务的。
20#所说的团队，
成员个个经验丰富、身怀绝技、有用不完的奇思妙想，执行力超 ...

archonwang

这个不是很赞同。说得不好听一点，在合理的范围内，完成工作需要加班说明还不具备敏捷的能力。

archonwang

想问个问题，敏捷方式对于测试而言，最大的好处在哪里？对于开发而言，最大的好处在哪里？什么样的情况下才可以具备敏捷实施的条件？

archonwang

原帖由 kitty1 于 2010-1-13 17:39 发表
感觉不适合大型软件开发，这样的开发比较快占领市场，适合中小企业，最主要看做多大的软件，市场重于一切的做法，可能会恶性化质量。

有点意思。我觉得考虑敏捷无非两种情况
1. 团队已经非常成熟稳定，不再需要明文的规范和约束
2. 快速占领市场，扩大地盘，并且客户对于质量的要求要低于组织对于市场的渴求。

tails82

那么多人想搞敏捷，赶时髦？你真的敏捷了吗？
        就和测试不能和开发独立谈论一样，敏捷测试也不能和敏捷开发独立而谈。现在追求敏捷，那说明我们以前那么多专家学者总结出来的工程方法是不敏捷的？
        我们先搞清楚敏捷提倡的是什么。究其最原始的创意和目的，那就是敏捷宣言。
个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作   重于 合同谈判
响应变化   重于 遵循计划
       敏捷方法论认为左边的重于右边的。但这并不说明我们可以抛弃右边的，而只选用左边的。
      我举个例子，我不只一次听人说道，敏捷开发可以不需要文档。不觉得荒谬吗？难道一个软件做完后，没有一个文档，是件正常的事情？是因为我们用了敏捷开发？其实，并不是不需要，而是表现形式不同。比如，在Scrum模式中，需求可以用Story代替。在XP模式中，详细设计可以用单元测试用例代替。这些都是文档，而且都是敏捷的核心内容。
      而为什么使用Story，不使用需求文档。为什么使用单元测试用例，不用详细设计文档？那自有他们的好处。Story描述了一个可发布的组件，可以尽早发布、应变变更能力强等。单元测试用例可以清楚地描述函数或类的功能，并能重复利用，作为重构的后防保障，等等。
      这说明了什么？我们的本质并没有变。仍然需要做需求分析，设计，编码，测试。只是我们的工作方式变了，变成了一种在某种环境下，最适应，最划算的方法，而不是死板地按照规定的约束来做。当然敏捷也有约束，但相比RUP等传统模式要少很多。当然RUP也有其适应的地方。
       什么时候用RUP，什么时候用Scrum，什么时候用CMM？没有标准答案，请根据自己的环境，找出最好的，也就是最敏捷的方法。在某些情况下，RUP比Scrum更敏捷，甚至不用RUP而用Scrum，根本无法做。而有些情况，又是相反的。所以说，别指望学会一种敏捷开发的模式，我们就敏捷了。真正的敏捷是在实践中调整出来的，不是直接拿来的。
      回到主题，敏捷测试如何开展？那么先了解你目前的流程吧。找出瓶颈，设法改进。改进时，可以参考Scrum、Kanban、XP、Lean、CMM甚至RUP等等等等你能想到的。找出最合适的，那就是最敏捷的。

Banditu

敏捷开发。。目的我咀嚼一下：
就是要快速交付，快，再快，更快！
当然这个快是要在一定的质量基础上的。
因此，要实现这个目标，我认为团队质量非常重要。走敏捷流程的团队必须很成熟，每个成员能力足够，团队凝聚力够好才能做到真正的敏捷--

就像武侠小说里的一样，轻功最NB的人往往都是武林一等高手……

尘封的记忆

小弟没做过敏捷开发，但是从不少前辈嘴里听过一些相关信息。
测试驱动开发，个人感觉需要测试人员对于业务和需求的理解很强，这就意味着需求的工作需要做的很到位，整体团队的协调性要很强，同是个人能力必须很强。

SQLme

小弟在这里谢谢各位大侠了！学习了

woza

敏捷的目的并不是快。快只能说是实施了敏捷之后的结果。对于敏捷企业来说，永远质量第一。为了快而放弃质量，就不是敏捷了。

敏捷的最终目的在于最小的代价递交给客户最有价值的东西。敏捷的高效率，快速反馈，拥抱变化都服务于这个最终目的。而传统开发模式下，要么无法给予客户最有价值的东西，要么就是无法做到低代价（这个比较常见）。

Glimmer

赞成34#说的，咱也参与了两个敏捷的项目。刚刚接触的东西肯定会存在一定的误区
在下对敏捷测试理解如下
1. 敏捷，顾名思义速度要快，但是这个速度，并不是盲目的要求开发测试的时间变短，而是改变以前开发测试合作方式中不合理的地方，删掉那些不必要的文档等待所浪费的时间。从而达到敏捷.

2. 其实不管是敏捷开发还是敏捷测试很重要的一点取决于工作人员的个人能力。基本功扎实，反应要快，理解要迅速。拿测试人员来说吧，甚至不要求测试用例。大家千万不要误会了。测试用例对测试人员的重要性是不容小觑的，这里的不要求，只是可以不用浪费的大把时间在什么TD,JIRA上语言详尽的，用词准确的描述，不用在需求变动后还去浪费大把的时间查找修改维护。但是测试人员自己，一定整理自己的测试用例要点，这一步是敏捷测试出高质量产品的重要保证。所以我们要想有效的开展敏捷开发，一定要保证自己的能力，养成良好的测试习惯。

3. 敏捷中还有一点很重要，那就是沟通，楼上看到有人说沟通是最重要的.说的很对，沟通不仅仅在敏捷中最重要。在任何工作里，都很重要。而在敏捷中，沟通是保证敏捷的一个重要手段。开发和测试人员理解的需求不统一，很多测试人员习惯于在测试的过程中，才去跟开发沟通，才去跟需求设计人员沟通，这如果放在敏捷中就会大大浪费彼此的时间，敏捷，每天8小时开发人员都有自己任务，你在人家这个sprint工作时间里去沟通上个sprint的问题。开发人员需要去回忆，去思考，甚至浪费时间找代码。我们要做的是实时的沟通。今天开发人员完成了他这个story的任务，你第二天就可以去check他的功能，注意，这个时间不是你报BUG的时间，你要做的只是去了解那些你真正在测试过程中会碰到的疑问。去沟通开发理解需求和你不同的地方。总而言之，我们要保证及时的沟通，以及正确的沟通方式。

敏捷只是一个概念，没有硬性的要求，怎样才可以最好的开展，当然还要取决于具体的项目。
欢迎拍砖！

xyzwh

35楼的还参加了2次敏捷的项目，实践后的理解应该会深刻些，很同意35楼的说法。
目前还没有参加过敏捷测试的项目，还不是很清楚敏捷开发，更别说敏捷测试了。
据说敏捷开发是2个开发人员公用一台电脑，头脑风暴？（一直还质疑这种说法对不对）

我自己空想下：敏捷测试是应“敏捷开发”而衍生的词，开发都敏捷了，我们测试的当然也要敏捷一把，这样整个项目才能敏捷。
想敏捷，当然得提高效率，提高效率的方法很多：
1.抛弃或精简一些不必要的文档，例如，个人感觉有些用例些的步骤写的不需繁冗。在用例前期可以不用写很细节，有些测试人员一开始写的很详细到时后期改动维护很麻烦。测试点尽可能的用一句话概括。但一定要明确正确，这样也方便修改和维护。
2.沟通的问题，我觉得测试人员应尽量多参加一些开发人员的内部沟通会议，这样可以尽早发现测试人员和开发人员之间的对功能理解的一些思维差别。同事测试人员能理解一些程序设计架构之类的知识。
3.测试团队内部或测试人员个人都需多多总结，例如哪些模块是重灾区，那些发现bug的方法比较好，怎样提高用例执行率。这对测试人员的能力提升也很有帮助。

总之，能力的提升，沟通和工作的效率提高才是敏捷的捷径

chengning

学习中

wuxinling

我不认为敏捷开发是抛弃了CMMI，CMMI不单单是针对的软件开发，敏捷是在一定的基础上的敏捷，如果为了敏捷而敏捷，那就麻烦了。按照一般的理解，敏捷开发站在了CMMI的对立面，从另一个角度理解，CMMI不就是一个参照标准吗？说是抛弃，不如说是超越它。
按照CMMI来做产品，时间成本和物质成本很高，但是如果真的严格按照标准做了，产品的质量肯定能得以保证，会做出好的产品。敏捷后，会降低很多时间和物质的投入，肯定会有质量方面的牺牲。如果这种质量的降低在用户可以接受的范围内，是完全可以进行的，什么的价格产生什么样的货！如果敏捷也要达到同样的质量，而公司投入还很少的话，那么成本的相差部分那里来那。我想肯定是人的利用率高了，要么你加班，要么你福利差，（班还不给钱！）说白了，是通过剥削员工的生命换来质量的保证。
我不是不赞成敏捷，而是公司太聪明，故意歪曲敏捷的含义，取对公司最有利的方面，牺牲员工的福利。
相信一句话，世上没有免费的午餐！放之四海皆准。

kuangjianke

敏捷也并不是用嘴说的，抛弃诸多复杂流程和文档是有前提条件的，楼上的很多朋友也说了，测试人员的素质是有一定要求的，比如要有很深厚的开发基础和能力。另外，每日构建，持续集成，成熟的自动化测试平台或框架也是实施敏捷的必要手段，所以技术不成熟的团队实施起来还是比较困难的，敏捷要的并不是速度，更关注代码的持续集成的质量。

guangzhoucm

我们通过引入公司自主开发的自动化测试框架ATElite支持敏捷测试

zsselina

CMMI与其说是一种标准，不如说是一种牌子，CMMI评级时狂补文档，审查一过该如何做事还如何做，国内大部分企业都是这么评CMMI的吧？敏捷的重点不是降低物质和时间的投入，而是生产率的提高。质量的保证并不和物质时间的投入一定成正比。真正的敏捷完全摒弃加班