【转】朱少民老师的《敏捷方法中测试人员的价值?》---边读边思

最经读了一篇朱少民老师的有关敏捷测试的博客文章,我在其中加入我自己的批注。

敏捷方法在软件开发中受到青睐,特别是在互联网应用服务系统的开发中,越来越多的公司采用敏捷方法,包括XP、Scrum、Lean、Crystal、FDD等。具体的敏捷方法在操作时有一些区别,但基本思想是一致的,如客户至上、拥抱变化、缩短迭代周期、自我组织(Gene:敏捷开发的四句宣言另外一种说法.)等。在敏捷方法中,流程相对灵活,强调沟通,通过充分的沟通来及时解决问题,由于沟通充分,文档不是很重要,而且有可能不采用Word等独立的文件格式,而是采用Wiki、空间等web内容方式(Gene:(1)同一个Location的时候,可能Face to face交流很重要;(2)Glob Team,Mails and IM可以很快的与DEV沟通.)。在敏捷方法中,需求变化比较快、产品开发周期很短(一、两周),给软件测试带来很大的挑战!例如,功能测试的自动化实现就比较困难,没有足够时间开发自动化测试脚本,要花大量时间讨论产品特性,及时进行产品的验收测试。自动化测试,更多的是在单元测试这个层次上实现。而单元测试自动化、持续集成等一些关键实践,开发人员能发挥更大的作用,而测试人员难以很好地发挥作用。在敏捷方法中,发人员的主导作用更明显,讨论需求、实现需求,再修改需求、再实现、再重构,不断完善产品,测试人员容易边缘化。甚至在Crystal方法中,可以不需要测试人员,开发人员能承担所有技术性的工作。

在敏捷方法中,测试人员的价值又如何体现?(Gene:以下的3点,对一个没有敏捷测试经验的人来说很有参考价值.)

首先在需求讨论上,测试人员可以站在客户角度上来阐述自己的观点,和产品人员、开发人员等进行充分的交流和讨论,使自己在用户体验、业务逻辑等等方面的经验充分体现出来。
在开发过程中,测试人员不仅扮演"用户代表"角色,而且可以及时提供更全面的质量反馈,包括代码质量、接口一致性等。测试人员不写代码,可以参与代码复审(code review),将质量问题及时提交给项目组,保证在产品构造的整个过程中质量受到足够的关注,提高质量改进的持续性和可视性。
其次,测试人员还是可以参与单元测试。即使单元测试由开发人员做,测试人员可以推进开发人员进行单元测,检查单元测试状态,如确保单元测试达到80%以上覆盖率,以及帮助开发人员开发出具有良好可测试性的代码。
即使在敏捷方法中,集成测试、端到端(end-to-end)测试、性能测试等是不可少的。因为在敏捷方法中,往往将一个大的系统开发分解成多个小的子系统(模块/组件),集成测试和端到端(end-to-end)测试显得更重要。测试人员在功能测试上工作量会降低,但在这些测试上发挥更大的作用。
随着迭代的不断深入,回归测试的工作量很大,这也是测试人员的用武之地。 测试人员可以针对稳定的产品特性开发自动化测试脚本,这也是一种持续的努力,使回归测试自动化。
测试人员对缺陷进行分析,总结出一些规律,帮助开发人员建立良好的习惯,改进代码的质量。
而且:在敏捷方法中,我们也要采用敏捷测试,不要再写几十页的测试计划书,而是在每个迭代周期,写出一页纸的测试计划,将测试要点列出来
在敏捷测试中,可能不需要测试用例,而是针对use case 或user story直接进行验证,并进行探索性测试。而节约出来的时间,用于开发原有功能的自动化测试脚本,为回归测试服务。自动化测试脚本将代替测试用例,成为软件组织的财富。
所以:敏捷功能测试 = 新特性的手工测试 (use case验证和探索性测试) + 原有功能的自动化测试 (回归测试)。

理想情况下,测试人员具有很好的编程能力,可以和开发人员进行角色互换。在当前版本开发(/迭代周期)中担任测试人员角色,在下一个版本开发(/迭代周期)中担任开发人员角色,而开发人员则担任测试人员角色,让开发人员深刻地理解用户的需求角度来考虑系统功能的设计,这样会更好地保证产品的质量,沟通的障碍也会消除,开发的效率会有很大的提高。这也是对测试人员的一个挑战。

敏捷测试也是一个持续测试的过程,而这持续测试的基础是具备一个灵活的、开放的自动化测试框架。测试人员在自动化测试框架构建上、测试工具开发或第3方测试工具前期研究、试用等方面可以发挥主导作用。


项目采用敏捷方法,要获得成功,项目组中每个人都有很强的质量意识,具有质量的主人翁精神,特别是开发人员,每时每刻提醒自己--"质量是构建出来的",与客户或产品设计人员进行充分沟通,遵守高度一致的质量标准。测试人员将是促进质量文化不断提升的中坚力量。

[案例补充]

来HW一段时间了,所在项目是其一个全新重点项目,由于采用敏捷模式开发,包括PM在内大家都是在摸索中进行的。撇开CMM改用敏捷,文档不再全面了,连缺陷库都改用轻量级的了,领导们说敏捷中测试做的好不好不是看找到多少BUG,而是看转测试时有没有BUG,要在开发交流中解决全部问题。三轮迭代下来,交流占据了大多数时间,感觉工作做好很多,但却不知道如何体现,这个真是问题,希望大家给点建议。


当前问题:敏捷开发中,测试人员的工作成绩如何体现?

参考:

效率提升系列谈:敏捷开发初体验
先进、成熟的软件工程思想有哪些?
软件开发过程(CMMI/RUP/XP/MSF)是与非?
敏捷统一过程 (Agile Unified Process,AUP)
精炼统一过程(Essential Unified Process,EssUP)
敏捷的发展方向
软件工程的发展方向,敏捷开发


本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/KerryZhu/archive/2010/03/10/5366574.aspx

posted @ 2010-03-30 23:34  GeneJiang  阅读(673)  评论(0编辑  收藏  举报