敏捷测试的“要”与“不要”

发表于:2017-9-12 10:52  作者:朱少民   来源:软件质量报道

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 敏捷测试 测试方法

  最近在看 Craig Larman和Bas Vodde写的 Practices for Scaling Lean & Agile Development 这本书,感觉作者挺重视“测试”的。多数敏捷开发类图书很少单独去谈测试,敏捷宣言和敏捷开发原则中也几乎没有谈到测试,而本书的作者在讲产品管理、计划、需求与PBI、设计与架构...之前就专门用一章的篇幅先谈“测试”,而且有50页的内容,超过其它十四章各个主题。作者叙述这章的方式也特别,用:
  “尝试”做什么
  “避免”做什么
  来表达作者的观点、所提倡的测试方式、方法和具体的实践,这些也来自于他们多年(敏捷咨询项目的)实践经验。
  这里把他们50页的内容浓缩为一张表,左边是尽量避免的项,右边是尽量尝试去做的项,供大家思考,看看是否对大家有启发?你们也可以对照自己公司的做法,在下面留言,谈谈你们自己的想法。
  (讽刺的是:一方面他反对certified tester,但自己却被Certified LeSS)
  这张表包括三部分:总体上测试的思考、面向用户的测试(褐色内容)、开发者测试(蓝色内容)。
  注1: 绝不容忍Open的缺陷是指:找到一个缺陷就会尽快修复,其好处就是防止:
  在跟踪许多bug上花费精力
  花费精力在优先级排序上
  延迟学到当修复缺陷时产生的知识
  花费额外的时间修复Bug,因为开发人员不再记得代码
  注2: 项目测试的臭味
  多故障的测试
  开发人员不编写测试
  测试高维护
  产品多故障
  注3:关于测试的假定
  测试必须是独立进行的,因此要与开发相分离
  必须有单独的测试部门
  必须有测试经理
  测试必须由“测试人员”完成
  测试不可以在代码完成前开始
  测试必须在最末尾进行
  测试必须是“计划周详的”
  必须有“测试策略”和一个“主测试计划”
  测试遵循以下顺序:I)测试用例设计,2)测试用例执行,3)测试用例汇报(一个测试瀑布流程)
  百分百测试覆盖率太昂贵。
  百分百自动测试太昂贵。
  测试需要精密的测试管理工具。
  注4:典型的研讨会日程:
  PO介绍研讨会目的
  Team和PO选择要工作的条目
  PO对选取的需求做概述发言
  发散:分局成几个子团体,就某个item讨论,写case
  聚合大家的成果
  重复“发散-聚合”几次
  结论
  提取

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2017, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道