敏捷开发实践总结(二):关于测试
2012-12-20 14:08
281 查看
用了两个冲刺周期,我们组算是把敏捷开发的测试流程给捋顺了。这里对我们的测试,以及敏捷开发中的测试做一个小结。
一、开发组一定不能讳疾忌医。
作为开发人员,一定要秉着这个出发点去看待测试。业务测试测试组测试,自测,与开发组的目标是一致的,都是为了保证和提高项目质量,没有谁要给谁找茬。
二、自测是第一步。
开发组自测必须是白盒测试。必须保证覆盖率。必须是自动化测试。尽量做到交叉测试。
三、测试组测试
测试组的测试应该是最全面、细致的。至少应是黑河测试。尽量做到白盒测试。应该具备各种性能测试的能力。测试组与业务人员、开发组要有有效、及时的沟通。
四、业务测试
业务测试的目的是需求验收。基本只能做到黑盒测试。要做好沟通,并通过测试沟通体现业务需求、设想。
五、整个测试要有统一的记录、反馈渠道。
如果开发组、测试组、业务组人手一份测试记录,很可能出现测试反馈记录遗漏、版本错乱等问题。
六、测试驱动。
测试驱动是个很不错的东西。在迈步子之前先投石问路,就会知道到哪一步应该注意什么。
敏捷开发中的测试,带着敏捷的特点。
一、小版本。
敏捷开发的核心就是小版本需求,针对需求进行测试的功能必然也是小版本的。
二、频率高。
所谓“小步快跑”,小版本带来的另一个特点必然就是测试、反馈频率高。
三、沟通多。
本身敏捷开发的各种沟通就多。测试阶段又会与业务人员直接关联,各种关于需求理解、改动和成本的沟通必然也会增加。
四、测试、反馈带有业务优先级。
根据业务流程的重要性、紧急性,给测试反馈的bug排列优先级。一方面,这种优先级是业务价值的体现,也是敏捷开发的目标;另一方面,这种优先级要求方便开发组安排有限的时间和人力;此外,对优先级的排序还可以从一个侧面反映出业务需求的一些核心思路。
五、开发组自组织、自驱动性强。
关于敏捷开发的自组织和自驱动,我到现在也没有吃透。从已有经验来看,一个大需求分割成小版本,并分派到各开发人员之后,各个小版本的开发、测试等工作基本就有开发人员自己掌握和推动,即使是项目负责人也很难掌握得太细。这是一种自驱动。
六、版本隔离、合并等管理工作要求高。
小版本意味着版本多,版本多意味着版本冲突的风险大。因此,敏捷开发对版本管理的要求也更高。
七、自动化
自动化也是版本多、速度快所要求的。不仅包括测试自动化,还应包括构建自动化、发布自动化等。
我们项目组现有的测试流程
现在的测试流程,借鉴了tx的敏捷流程,采用“测试班车”和“测试包车”的形式组织测试。自测和测试驱动方面开展得不太顺利,还在继续推动之中。
“测试班车”是定期的测试版本。我们的一个冲刺规划为3周。通常,前两周的测试都采取“测试班车”的形式,每隔两天(周二下午和周五上午)发布一个测试版本,交由测试组进行测试。
“测试包车”是不定期的测试版本,什么时候有升级就什么时候包一趟车。我们组通常从第二周开始就会有测试包车。第三周开始将版本发布到stage测试环境上,交由业务组进行测试。第三周的测试反馈和更新基本都是采用包车的形式。
目前测试组的测试反馈统一由mantis系统进行管理。业务组的测试反馈目前没有统一的工具,仅由业务人员整理成统一的文档。
本文出自 “编程的摩羯男” 博客,请务必保留此出处/article/4248967.html
一、开发组一定不能讳疾忌医。
作为开发人员,一定要秉着这个出发点去看待测试。业务测试测试组测试,自测,与开发组的目标是一致的,都是为了保证和提高项目质量,没有谁要给谁找茬。
二、自测是第一步。
开发组自测必须是白盒测试。必须保证覆盖率。必须是自动化测试。尽量做到交叉测试。
三、测试组测试
测试组的测试应该是最全面、细致的。至少应是黑河测试。尽量做到白盒测试。应该具备各种性能测试的能力。测试组与业务人员、开发组要有有效、及时的沟通。
四、业务测试
业务测试的目的是需求验收。基本只能做到黑盒测试。要做好沟通,并通过测试沟通体现业务需求、设想。
五、整个测试要有统一的记录、反馈渠道。
如果开发组、测试组、业务组人手一份测试记录,很可能出现测试反馈记录遗漏、版本错乱等问题。
六、测试驱动。
测试驱动是个很不错的东西。在迈步子之前先投石问路,就会知道到哪一步应该注意什么。
敏捷开发中的测试,带着敏捷的特点。
一、小版本。
敏捷开发的核心就是小版本需求,针对需求进行测试的功能必然也是小版本的。
二、频率高。
所谓“小步快跑”,小版本带来的另一个特点必然就是测试、反馈频率高。
三、沟通多。
本身敏捷开发的各种沟通就多。测试阶段又会与业务人员直接关联,各种关于需求理解、改动和成本的沟通必然也会增加。
四、测试、反馈带有业务优先级。
根据业务流程的重要性、紧急性,给测试反馈的bug排列优先级。一方面,这种优先级是业务价值的体现,也是敏捷开发的目标;另一方面,这种优先级要求方便开发组安排有限的时间和人力;此外,对优先级的排序还可以从一个侧面反映出业务需求的一些核心思路。
五、开发组自组织、自驱动性强。
关于敏捷开发的自组织和自驱动,我到现在也没有吃透。从已有经验来看,一个大需求分割成小版本,并分派到各开发人员之后,各个小版本的开发、测试等工作基本就有开发人员自己掌握和推动,即使是项目负责人也很难掌握得太细。这是一种自驱动。
六、版本隔离、合并等管理工作要求高。
小版本意味着版本多,版本多意味着版本冲突的风险大。因此,敏捷开发对版本管理的要求也更高。
七、自动化
自动化也是版本多、速度快所要求的。不仅包括测试自动化,还应包括构建自动化、发布自动化等。
我们项目组现有的测试流程
现在的测试流程,借鉴了tx的敏捷流程,采用“测试班车”和“测试包车”的形式组织测试。自测和测试驱动方面开展得不太顺利,还在继续推动之中。
“测试班车”是定期的测试版本。我们的一个冲刺规划为3周。通常,前两周的测试都采取“测试班车”的形式,每隔两天(周二下午和周五上午)发布一个测试版本,交由测试组进行测试。
“测试包车”是不定期的测试版本,什么时候有升级就什么时候包一趟车。我们组通常从第二周开始就会有测试包车。第三周开始将版本发布到stage测试环境上,交由业务组进行测试。第三周的测试反馈和更新基本都是采用包车的形式。
目前测试组的测试反馈统一由mantis系统进行管理。业务组的测试反馈目前没有统一的工具,仅由业务人员整理成统一的文档。
本文出自 “编程的摩羯男” 博客,请务必保留此出处/article/4248967.html
相关文章推荐
- 敏捷开发实践总结(二):关于测试
- 关于《敏捷软件开发:原则、模式与实践(C#版)》
- 关于敏捷开发的总结
- 关于敏捷开发的一点总结
- 由测试中的版本同步联想到敏捷开发中的两个实践
- 敏捷开发实践总结
- 关于敏捷开发的一点总结与感悟
- 敏捷软件开发实践之总结 ( 序)
- 关于敏捷开发的一点总结与感悟
- 关于正则表达式在线测试工具的开发总结
- 同事关于敏捷开发的总结
- 敏捷软件开发:原则、模式与实践——第4章 测试
- 关于敏捷开发的总结
- 敏捷开发实践总结(一):敏捷开发的核心思想
- 敏捷开发实践总结(三):需求分析
- 敏捷开发实践总结(三):需求分析
- 《敏捷软件开发:原则、原则与实践》第四章 测试 (读书笔记)
- 敏捷理念-软件开发实践总结
- Scrum敏捷软件开发之技术实践——测试驱动开发TDD
- 敏捷开发实践总结(四):职责分工