敏捷测试如何开展？（2010-1-11）（获奖名单已公布）
随着敏捷开发逐渐成为各大公司频繁采用的软件开发方式，敏捷测试也日渐成为测试界关注的一个热点。敏捷测试如何开展？欢迎大家各抒己见。
如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
http://bbs.51testing.com/attachments/month_0811/20081125_650d7dccd46be6244f27oXDjE0HoDhyX.gif
相关文章：
敏捷开发&敏捷测试
敏捷的软件测试 必须纠正十大误解
关于敏捷，我们究竟了解多少？
更多内容请点击＞＞＞
获奖名单奖项获奖名单奖励答案链接一等奖mitutu51软件测试书籍9#二等奖dennyqiang300论坛积分20#三等奖tails82100论坛积分30# 题外话：MS大家都比较谦虚，那就让我这个菜鸟先抛砖吧。。公司放在CMM5的流程不做，也开始赶时髦，采用敏捷开发了。服从领导听指挥，测试也要敏捷撒。。。摸索了两周，有点点心得，说来大家讨论先。
一、敏捷嘛，当然没有如CMM5那么规范的文档化需求可供参考，但需求还是要明确的，这就要要求开发、测试、客户三方及时沟通明确需求点。
二、与测试同仁梳理测试点，任务分解、设计测试用例，组内讨论后发给相应的开发人员；
三、与开发中持续沟通，编码结束后开发人员应进行用例的功能测试。（中间用例有问题，可沟通修改用例，同时测试还应根据开发实现的Story添加、维护测试用例）。
四、执行测试用例，跟踪缺陷。。。
PS：关于质量。。公司连story验收标准都“敏捷”了，:L ，但对应我们测试人员，时刻不敢忘记责任心和质量意识。所以对于没有通过功能测试的Story坚决不予以签收测试，稳定的质量才是迭代实现的关键嘛。 敏捷测试实在不是几句话能够说得清。
敏捷测试就方法来说，和非敏捷没有什么区别。敏捷在测试方面的变革在于，从流程和思想上面强调了质量第一的核心理念。要求先做好，再做快。
开发和测试成为一个整体。软件以最终的质量来说话。自动化测试在敏捷开发中属于必须品，而非“奢侈品”。个人的能力被充分发挥。
敏捷是一种思维方式的变革。从本质上认识到了，软件的质量需要通过客户价值来衡量；既然人是软件开发的关键，那么与其用死的规定，不如用活的方法激发人的积极性。
欢迎去我的博客拍砖。 敏捷测试无法脱离敏捷开发而独立存在。如果一定要局限在测试领域来谈敏捷的话，我建议以下几点：
1.成员之间平等且互相尊重。
2.团队合作，胜过个人。
3.让第一线真正做事情的人去做决定。
4.鼓励尝试，避免空谈。
5.从客户价值出发，优先做对客户最有价值的任务。
6.反对一切浪费，比如无用的会议，计划，报告等等。
7.经常反思。
8.一定要实施自动化测试。 目前公司所用的也是敏捷开发，我们做测试也要转变策略变成敏捷测试。开发和测试坐在一起，有发现问题直接重现，直接修改，使用SVN进行管理。
感觉敏捷测试有时候让人感觉很轻松，因为不要按流程那么复杂，不然一个BUG修改周期太长了，而且影响其他模块功能。开发周期大大节省。
不过有时候感觉很慌乱，验收，SDV测试等等发现，没有按流程来做，文档输出不好保证，流程所涉及的一些东西没在测试过程中补全，或丢失。心慌手乱。 原帖由 luozhijun 于 2010-1-12 11:25 发表 http://bbs.51testing.com/images/common/back.gif
目前公司所用的也是敏捷开发，我们做测试也要转变策略变成敏捷测试。开发和测试坐在一起，有发现问题直接重现，直接修改，使用SVN进行管理。
感觉敏捷测试有时候让人感觉很轻松，因为不要按流程那么复杂，不然一个B ...
感觉混乱可能是因为DoD没有约定清楚。如果流程有问题，那需要在回顾会议中提出，并及时改进。尽可能从简单的流程开始，只有在需要的时候，再加入新流程。还有，流程是死的，人是活得。流程是为人服务的，而不是束缚。
我们现在工作的时候，已经不需要固定流程了。很多东西已经变成习惯了。计划，需求变更之类的事情，喊一声，几分钟就搞定了。外人看着觉得很混乱，团队成员心里都清楚的很，不会出错的。 原帖由 luozhijun 于 2010-1-12 11:25 发表 http://bbs.51testing.com/images/common/back.gif
目前公司所用的也是敏捷开发，我们做测试也要转变策略变成敏捷测试。开发和测试坐在一起，有发现问题直接重现，直接修改，使用SVN进行管理。
感觉敏捷测试有时候让人感觉很轻松，因为不要按流程那么复杂，不然一个B ...
敏捷注重三点：
1.目标明确；——灵活而不乱；
2.基于事实决策；——强调可行性，没有固定的规范；
3.加强团队协调。——强调人与人之间的合作，充分认识“人”的概念。
如何应对敏捷测试？
目前也正在探索敏捷测试要如何进行，敏捷测试的意义何在？感觉可以用一句话来表达：那就是把我们的测试资源用在刀刃上，将测试价值体现最大化。敏捷测试的顺利展开需要的条件：1.项目团队的敏捷意识。从我们的需求开始，到开发，再到测试，整个项目组的人员都要有敏捷的意识，这样就能为敏捷测试创作一个良好的氛围。
2.项目流程的敏捷化。在传统的瀑布式项目模型中我们能进行敏捷的东西是有限的，需要探索新的项目模式，比如迭代式等。
在敏捷的路上，要求需求，开发，测试三方都不断延伸自己的专业优势，同时不断完善自己的知识体系，个人感觉测试这边的挑战更大一些。因为需求方本来就有很强的商业sense，开发方有技术sense，我们测试如果只有质量sense的话就很被动，需要准备的东东很多：
1.测试技术的准备。假设我们已经走在敏捷的路上，将我们的测试工作延伸到项目的前期，当我们和开发等多方讨论技术构架等实现问题时，提出一些有建设性有影响力的建议，这时就充分体现我们原本测试角色之外的岗位价值；
2.商业嗅觉的培养。站在公司或PD，用户等需求方的视角来了解分析我们的产品，加上测试特有的风险意识，可以提前发现一些用户体验的问题，拉近我们和用户的距离，让我们的测试更贴近用户需求。
3.良好的沟通协调能力。流程敏捷了，我们会有更多的机会进行多方合作和交流，如果不具备很强的沟通协调和应变事物的能力，那么你就会成为整个项目高效运作的瓶颈，这样的压力和影响都是很大的。
总之，测试敏捷了，要求我们都要敏捷的把综合素质提高，这样才能保证项目的高效运作。敏捷是机会也是挑战！ 建立不同级别的测试验收标准（也就是test suite），包括单元测试、集成测试、系统测试等各个层面的验收标准；
推动整个组织的质量文化，保证整个组织的成员在质量责任与目标方面达成一致；
通过技术或是管理的手段，保证产品、代码具有良好的可测试性；
通过自动化测试手段缩短每个产品发布周期中测试所需的时间；
与客户沟通确认客户可接受的软件质量标准，并建立针对此标准的验收测试；
深入了解应用系统和业务需求，通过探索性测试方法设计有效的测试用例，发现产品中的缺陷；
建立对整个团队可见的质量度量体系，保证整个团队能够随时看到产品的质量度量值。
请经验者描述什么是敏捷性测试
最好能举个实例，谢谢，我还没接触过，最近才听别人提了一下。请经验者描述什么是敏捷性测试,有什么优势和劣势？何为敏捷测试
原帖由 kittyhu 于 2010-1-13 16:14 发表 http://bbs.51testing.com/images/common/back.gif最好能举个实例，谢谢，我还没接触过，最近才听别人提了一下。请经验者描述什么是敏捷性测试,有什么优势和劣势？
对啊，能不能说清楚点，何为敏捷测试？ 原帖由 xiaobao0614 于 2010-1-13 16:33 发表 http://bbs.51testing.com/images/common/back.gif
对啊，能不能说清楚点，何为敏捷测试？
敏捷测试应该是针对敏捷开发而言的，目前没有广泛的定义，参照敏捷开发定义有一些应给遵循的原则。个人觉得，没有很强的团队（包括能力、沟通各个方面）不好达到很好的效果 看看这个专题，可能会有所裨益
http://subject.csdn.net/agile-testing.htm
以扎实的测试理论为基础
我的观点没有经过实践1.开发要做一个点，我们就写一个点的测试需求
2.测试需求和开发同步走，不写测试用例
3.边测试边写用例，用例简单写，看明白就行，不影响测试进度。开发结束测试也结束了 先抢个位。。 个人认为，敏捷测试其实就是对应敏捷开发而生出的一个新名词，与传统测试的方式和方法上基本没有太大的区别，主要区别在于对测试过程中各个环节工作的处理速度的加快，这样可以缩短测试发现的问题到修改完毕的中间时间，降低沟通环节的时间损耗，从而提高整个项目团队的工作效率；但是需要注意的是，测试的最终目的是要保证质量，一定要把握住速度和质量之间的平衡点，如果单纯为了追求速度和进度而忽略质量的话，就有点得不偿失了。 感觉不适合大型软件开发，这样的开发比较快占领市场，适合中小企业，最主要看做多大的软件，市场重于一切的做法，可能会恶性化质量。 我们项目也敏捷一个月了。总结起来有以下几点在：
1、开发测试坐在一起，一个开发对应一个测试。
2、每天早上第一件事就是开早会。大家从座位站起来，围成一个圈，每人轮流说自己昨天都做了什么，遇到什么困难，希望得到什么援助等。
3、测试驱动开发。如果测试受阻，开发的最重要最紧急的工作就是解决阻塞问题。 真正接触敏捷开发也有两年了，由于不太喜欢那种按部就班的工作方法，觉得瀑布模型太臃肿，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
