51Testing软件测试论坛

标题: 敏捷测试如何开展？（2010-1-11）（获奖名单已公布） [打印本页]

作者: 默默巫 时间: 2010-1-11 11:48
标题: 敏捷测试如何开展？（2010-1-11）（获奖名单已公布）
随着敏捷开发逐渐成为各大公司频繁采用的软件开发方式，敏捷测试也日渐成为测试界关注的一个热点。
敏捷测试如何开展？欢迎大家各抒己见。

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

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

作者: 菜也快乐着 时间: 2010-1-11 14:15
题外话：MS大家都比较谦虚，那就让我这个菜鸟先抛砖吧。。公司放在CMM5的流程不做，也开始赶时髦，采用敏捷开发了。服从领导听指挥，测试也要敏捷撒。。。摸索了两周，有点点心得，说来大家讨论先。
一、敏捷嘛，当然没有如CMM5那么规范的文档化需求可供参考，但需求还是要明确的，这就要要求开发、测试、客户三方及时沟通明确需求点。
二、与测试同仁梳理测试点，任务分解、设计测试用例，组内讨论后发给相应的开发人员；
三、与开发中持续沟通，编码结束后开发人员应进行用例的功能测试。（中间用例有问题，可沟通修改用例，同时测试还应根据开发实现的Story添加、维护测试用例）。
四、执行测试用例，跟踪缺陷。。。
PS：关于质量。。公司连story验收标准都“敏捷”了，

，但对应我们测试人员，时刻不敢忘记责任心和质量意识。所以对于没有通过功能测试的Story坚决不予以签收测试，稳定的质量才是迭代实现的关键嘛。

作者: woza 时间: 2010-1-11 19:25
敏捷测试实在不是几句话能够说得清。

敏捷测试就方法来说，和非敏捷没有什么区别。敏捷在测试方面的变革在于，从流程和思想上面强调了质量第一的核心理念。要求先做好，再做快。

开发和测试成为一个整体。软件以最终的质量来说话。自动化测试在敏捷开发中属于必须品，而非“奢侈品”。个人的能力被充分发挥。

敏捷是一种思维方式的变革。从本质上认识到了，软件的质量需要通过客户价值来衡量；既然人是软件开发的关键，那么与其用死的规定，不如用活的方法激发人的积极性。

欢迎去我的博客拍砖。

作者: woza 时间: 2010-1-11 21:09
敏捷测试无法脱离敏捷开发而独立存在。如果一定要局限在测试领域来谈敏捷的话，我建议以下几点：

1.成员之间平等且互相尊重。
2.团队合作，胜过个人。
3.让第一线真正做事情的人去做决定。
4.鼓励尝试，避免空谈。
5.从客户价值出发，优先做对客户最有价值的任务。
6.反对一切浪费，比如无用的会议，计划，报告等等。
7.经常反思。
8.一定要实施自动化测试。

作者: luozhijun 时间: 2010-1-12 11:25
目前公司所用的也是敏捷开发，我们做测试也要转变策略变成敏捷测试。开发和测试坐在一起，有发现问题直接重现，直接修改，使用SVN进行管理。
感觉敏捷测试有时候让人感觉很轻松，因为不要按流程那么复杂，不然一个BUG修改周期太长了，而且影响其他模块功能。开发周期大大节省。
不过有时候感觉很慌乱，验收，SDV测试等等发现，没有按流程来做，文档输出不好保证，流程所涉及的一些东西没在测试过程中补全，或丢失。心慌手乱。

作者: woza 时间: 2010-1-12 19:24

原帖由 luozhijun 于 2010-1-12 11:25 发表
目前公司所用的也是敏捷开发，我们做测试也要转变策略变成敏捷测试。开发和测试坐在一起，有发现问题直接重现，直接修改，使用SVN进行管理。
感觉敏捷测试有时候让人感觉很轻松，因为不要按流程那么复杂，不然一个B ...

感觉混乱可能是因为DoD没有约定清楚。如果流程有问题，那需要在回顾会议中提出，并及时改进。尽可能从简单的流程开始，只有在需要的时候，再加入新流程。还有，流程是死的，人是活得。流程是为人服务的，而不是束缚。

我们现在工作的时候，已经不需要固定流程了。很多东西已经变成习惯了。计划，需求变更之类的事情，喊一声，几分钟就搞定了。外人看着觉得很混乱，团队成员心里都清楚的很，不会出错的。

作者: liulinzhu 时间: 2010-1-12 20:33

原帖由 luozhijun 于 2010-1-12 11:25 发表
目前公司所用的也是敏捷开发，我们做测试也要转变策略变成敏捷测试。开发和测试坐在一起，有发现问题直接重现，直接修改，使用SVN进行管理。
感觉敏捷测试有时候让人感觉很轻松，因为不要按流程那么复杂，不然一个B ...

敏捷注重三点：
1.目标明确；——灵活而不乱；
2.基于事实决策；——强调可行性，没有固定的规范；
3.加强团队协调。——强调人与人之间的合作，充分认识“人”的概念。

作者: mitutu 时间: 2010-1-12 23:40
标题: 如何应对敏捷测试？
目前也正在探索敏捷测试要如何进行，敏捷测试的意义何在？感觉可以用一句话来表达：那就是把我们的测试资源用在刀刃上，将测试价值体现最大化。敏捷测试的顺利展开需要的条件：
1.项目团队的敏捷意识。从我们的需求开始，到开发，再到测试，整个项目组的人员都要有敏捷的意识，这样就能为敏捷测试创作一个良好的氛围。
2.项目流程的敏捷化。在传统的瀑布式项目模型中我们能进行敏捷的东西是有限的，需要探索新的项目模式，比如迭代式等。
在敏捷的路上，要求需求，开发，测试三方都不断延伸自己的专业优势，同时不断完善自己的知识体系，个人感觉测试这边的挑战更大一些。因为需求方本来就有很强的商业sense，开发方有技术sense，我们测试如果只有质量sense的话就很被动，需要准备的东东很多：
1.测试技术的准备。假设我们已经走在敏捷的路上，将我们的测试工作延伸到项目的前期，当我们和开发等多方讨论技术构架等实现问题时，提出一些有建设性有影响力的建议，这时就充分体现我们原本测试角色之外的岗位价值；
2.商业嗅觉的培养。站在公司或PD，用户等需求方的视角来了解分析我们的产品，加上测试特有的风险意识，可以提前发现一些用户体验的问题，拉近我们和用户的距离，让我们的测试更贴近用户需求。
3.良好的沟通协调能力。流程敏捷了，我们会有更多的机会进行多方合作和交流，如果不具备很强的沟通协调和应变事物的能力，那么你就会成为整个项目高效运作的瓶颈，这样的压力和影响都是很大的。
总之，测试敏捷了，要求我们都要敏捷的把综合素质提高，这样才能保证项目的高效运作。敏捷是机会也是挑战！

作者: wenjinga 时间: 2010-1-13 15:03
建立不同级别的测试验收标准（也就是test suite），包括单元测试、集成测试、系统测试等各个层面的验收标准；
推动整个组织的质量文化，保证整个组织的成员在质量责任与目标方面达成一致；
通过技术或是管理的手段，保证产品、代码具有良好的可测试性；
通过自动化测试手段缩短每个产品发布周期中测试所需的时间；
与客户沟通确认客户可接受的软件质量标准，并建立针对此标准的验收测试；
深入了解应用系统和业务需求，通过探索性测试方法设计有效的测试用例，发现产品中的缺陷；
建立对整个团队可见的质量度量体系，保证整个团队能够随时看到产品的质量度量值。

作者: kittyhu 时间: 2010-1-13 16:14
标题: 请经验者描述什么是敏捷性测试
最好能举个实例，谢谢，我还没接触过，最近才听别人提了一下。请经验者描述什么是敏捷性测试,有什么优势和劣势？

作者: xiaobao0614 时间: 2010-1-13 16:33
标题: 何为敏捷测试

原帖由 kittyhu 于 2010-1-13 16:14 发表
最好能举个实例，谢谢，我还没接触过，最近才听别人提了一下。请经验者描述什么是敏捷性测试,有什么优势和劣势？

对啊，能不能说清楚点，何为敏捷测试？

作者: gascend 时间: 2010-1-13 16:42

原帖由 xiaobao0614 于 2010-1-13 16:33 发表

对啊，能不能说清楚点，何为敏捷测试？

敏捷测试应该是针对敏捷开发而言的，目前没有广泛的定义，参照敏捷开发定义有一些应给遵循的原则。个人觉得，没有很强的团队（包括能力、沟通各个方面）不好达到很好的效果

作者: archonwang 时间: 2010-1-13 16:46
看看这个专题，可能会有所裨益
http://subject.csdn.net/agile-testing.htm

作者: lvjz 时间: 2010-1-13 16:50
标题: 以扎实的测试理论为基础
我的观点没有经过实践
1.开发要做一个点，我们就写一个点的测试需求
2.测试需求和开发同步走，不写测试用例
3.边测试边写用例，用例简单写，看明白就行，不影响测试进度。开发结束测试也结束了

作者: yu8023yan 时间: 2010-1-13 16:51
先抢个位。。

作者: Mark665 时间: 2010-1-13 16:55
个人认为，敏捷测试其实就是对应敏捷开发而生出的一个新名词，与传统测试的方式和方法上基本没有太大的区别，主要区别在于对测试过程中各个环节工作的处理速度的加快，这样可以缩短测试发现的问题到修改完毕的中间时间，降低沟通环节的时间损耗，从而提高整个项目团队的工作效率；但是需要注意的是，测试的最终目的是要保证质量，一定要把握住速度和质量之间的平衡点，如果单纯为了追求速度和进度而忽略质量的话，就有点得不偿失了。

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

作者: bx127 时间: 2010-1-13 21:48
我们项目也敏捷一个月了。总结起来有以下几点在：
1、开发测试坐在一起，一个开发对应一个测试。
2、每天早上第一件事就是开早会。大家从座位站起来，围成一个圈，每人轮流说自己昨天都做了什么，遇到什么困难，希望得到什么援助等。
3、测试驱动开发。如果测试受阻，开发的最重要最紧急的工作就是解决阻塞问题。

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

那么敏捷方法论到底是个什么玩意？经过与不同的人讨论敏捷，我发现大致有以下这些理解，或者叫偏见：
1)    敏捷就是不需要流程，不需要文档，开发人员看着做就行了 ……
2)    敏捷就是XP，敏捷就是测试先行，测试驱动开发 ……
3)    敏捷就是抛弃瀑布模型，抛弃CMMI，抛弃文档和设计，随需应变 ……
4)    敏捷就是无组织，无纪律，所以我们不需要 ……
5)    只听说过敏捷开发，没听说过敏捷测试，还有敏捷管理？
6)    只要一帮聪明的人聚在一起，项目就敏捷了，我们需要聪明的人 …….
7)    敏捷就是拥抱变化，加强沟通 ……
8)    敏捷就是灵活使用工具，只要是轻量级的东西，都可以叫敏捷 ……

正是由于这样的一种现状，才让我深深地感觉得敏捷这个东西太虚，只限于一个概念，大部分人可能还是摸不着头脑，只是有一些片面的了解而已。所以，AgijeJoy有必要使用中国式的语言来传播这样一种方法，使我们本来就不先进的软件行业不要再被一些累赘所拖累，敏捷起来。

那么敏捷到底是什么？如果用一句话来概括的话就是：你感觉你每天真正是在做事了，而不是在为文档和流程疲于奔命。基本上不论XP还是Scrum还是其它框架，都离不开如下一些要点：
1)    简化流程，切切实实地简化，把能去掉的全去掉
2)    简化文档，所有的文档只应该包括客户需要的
3)    简化产品设计，要想使开发和测试过程变得敏捷，产品自己在架构和设计上首先得自己足够敏捷
4)    使用各类成熟的轻量级的框架和工具来开发和测试产品，注意是轻量级的
5)    让项目组全体成员坐在一起，相互讨论，声音可以很大
6)    充分授权，充分奖励，让团队充满活力而不是死气沉沉
7)    沟通，沟通，沟通……

归根结底，“敏捷”本身只是一个概念，只是一种方法论，就像我党“要始终高举社会主义建设伟大旗帜，坚持三个代表，坚持解放思想，………..”，这也是一种方法论，而究竟怎么能做到？怎么样才算做到了？答案有很多种，但是最终还是一个原则，确保我们的项目按时按量成功完成。

原帖出处： http://www.agilejoy.com/?p=10

作者: 舞の月 时间: 2010-1-14 09:59
标题: 回复 20# 的帖子
感觉沟通很重要，不应该排在最后的……

作者: wpyily 时间: 2010-1-14 10:00

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

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

作者: angle-ying 时间: 2010-1-14 10:17
比较孤陋寡闻刚刚听说敏捷型测试我感觉自动化还是最重要的这一点满足了对测试就有很大的帮助了需求明确也是最重要的了

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

作者: mengluoyong 时间: 2010-1-14 15:22
学习下~

作者: archonwang 时间: 2010-1-14 16:59
自己感觉，敏捷团队的人员素质是基础。如果基础不好，敏捷是很难开展下去的。

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

作者: archonwang 时间: 2010-1-14 17:01
标题: 回复 22# 的帖子
这个不是很赞同。说得不好听一点，在合理的范围内，完成工作需要加班说明还不具备敏捷的能力。

作者: archonwang 时间: 2010-1-14 17:02
想问个问题，敏捷方式对于测试而言，最大的好处在哪里？对于开发而言，最大的好处在哪里？什么样的情况下才可以具备敏捷实施的条件？

作者: archonwang 时间: 2010-1-14 17:06

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

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

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

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

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

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

作者: SQLme 时间: 2010-1-15 10:43
小弟在这里谢谢各位大侠了！学习了

作者: woza 时间: 2010-1-15 15:38
敏捷的目的并不是快。快只能说是实施了敏捷之后的结果。对于敏捷企业来说，永远质量第一。为了快而放弃质量，就不是敏捷了。

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

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

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

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

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

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

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

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

作者: chengning 时间: 2010-1-18 16:21

学习中

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

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

作者: guangzhoucm 时间: 2010-1-19 10:23
我们通过引入公司自主开发的自动化测试框架ATElite支持敏捷测试

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

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

作者: qiuqiu_ma 时间: 2010-1-22 16:47
各位，有没哪位认为自己公司的敏捷开发与测试是成功的？希望简单的给个执行方案供大家参考。谢啦！！

作者: hutter2006 时间: 2010-2-9 13:51
今天才发现我们早在2006年就施行敏捷测试了。

作者: velata 时间: 2010-8-25 18:38
看完获奖的3个帖子
感觉还是没明白敏捷测试如何开展。。。

作者: cocaxiaojing 时间: 2010-12-1 11:38
回复 45# velata
同感!

作者: lvweijue2006 时间: 2011-2-15 15:04

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

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

同感。

作者: zwb131442 时间: 2011-2-25 15:11
一般般

作者: 真实的追求者 时间: 2011-3-8 16:28
高手如云啊

作者: y_test 时间: 2011-5-6 13:09
主要结合实际的情况来定论了

作者: 061001 时间: 2011-9-29 09:04
看完了整个帖子还是没有明白什么是敏捷测试，我的理解力这么差？！

作者: 孟胡范b 时间: 2011-10-24 20:20
不错的呢。。我看好你噢！吞噬星空 http://www.kanshu.la/

作者: wangjun7 时间: 2016-8-29 14:30

作者: 中山陵夫子庙 时间: 2016-10-16 14:05
顶上去!顶上去!

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)