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

默默巫

随着敏捷开发逐渐成为各大公司频繁采用的软件开发方式，敏捷测试也日渐成为测试界关注的一个热点。
敏捷测试如何开展？欢迎大家各抒己见。

如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！



相关文章：

敏捷开发&敏捷测试

敏捷的软件测试 必须纠正十大误解

关于敏捷，我们究竟了解多少？

更多内容请点击＞＞＞

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	mitutu	51软件测试书籍	9#
二等奖	dennyqiang	300论坛积分	20#
三等奖	tails82	100论坛积分	30#

中山陵夫子庙

顶上去!顶上去!

wangjun7

孟胡范b

不错的呢。。我看好你噢！吞噬星空  http://www.kanshu.la/

061001

看完了整个帖子还是没有明白什么是敏捷测试，我的理解力这么差？！

y_test

主要结合实际的情况来定论了

真实的追求者

高手如云啊

zwb131442

一般般

lvweijue2006

敏捷测试无法脱离敏捷开发而独立存在。如果一定要局限在测试领域来谈敏捷的话，我建议以下几点：

1.成员 ...
woza 发表于 2010-1-11 21:09

同感。

cocaxiaojing

回复 45# velata
同感!

velata

看完获奖的3个帖子
感觉还是没明白敏捷测试如何开展。。。

hutter2006

今天才发现我们早在2006年就施行敏捷测试了。

qiuqiu_ma

各位，有没哪位认为自己公司的敏捷开发与测试是成功的？希望简单的给个执行方案供大家参考。谢啦！！

look心

哎，想到我们公司好像一直都在做敏捷开发，敏捷测试，对测试一块也不是很重视，往往容易出问题。而且整个项目的测试或许就你一个人在做工作，你想在短时间内做出有效的测试还是比较困难。
这个可能跟我们所有接触项目的人员的沟通也有关，技术未落实现场情况，具体需求；研发简单开发不注意用户操作；测试了解需求，简单设计用例，提交报告，未测试到现场环境，测试没有现场环境等各种状况都容易引发问题。
所以要敏捷，还是先要打好基础。

zsselina

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

guangzhoucm

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

kuangjianke

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

wuxinling

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

chengning

学习中

xyzwh

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

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

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

Glimmer

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

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

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

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