评《从一个实例详解敏捷测试的最佳实践》
评《从一个实例详解敏捷测试的最佳实践》

评《从一个实例详解敏捷测试的最佳实践》

前几日同事分享了一份号称IBM的敏捷实施经验,看完心中有好多疑问,在网上搜索,发现此文应该是率先发布在IBM的DeveloperWorks上面:《从一个实例详解敏捷测试的最佳实践》,但遗憾的是此文中有很多对敏捷开发的误解。

  • 文中所引用的“敏捷软件开发有着自己独特的流程”事实上是Scrum概要图,而非敏捷的流程图。
  • 极限编程、Scrum并非是在敏捷开发前出现的软件开发方法,而是敏捷方法中的一部分,至于测试驱动开发更只是极限编程之中的工程实践而已。
  • “团队中的项目经理(Scrum master)需要在每个客户需求到来的时候制定 Sprint 的周期,定义每个 Sprint 的目标、分派任务、进行监督、最后总结得失并开始计划新的 Sprint。”
    • scrum master并不是团队的经理,也并不是以往的项目经理换个名字,而是具有不同的职责和权力
    • sprint周期的确定并不是有scrum master一个人来确定,需要由相关人员商讨决定,取决于产品所处的行业环境、客户对交付的要求、团队能否适应短周期等等许多因素
    • sprint的目标、分派任务、总结得失,这些都应由团队自己担起责任,这才能培养出scrum里面重要的一个role — self-organized team
  • “如果项目进行于开发新功能时期……..如果项目进行于测试新功能时期,”:这依然是瀑布式流程化思想的产物,敏捷宣言中有提到,working software才是唯一的度量,在同一个迭代周期内,需要完成所有的需求分析、开发、测试、客户文档等相关活动,并不会分为“开发时期”和“测试时期”
  • “测试人员需要在每天的站立会议(Daily Standup
    Meeting)上报告前一个工作日发现的新缺陷情况,项目经理根据项目进度和缺陷严重性来决定是否修复这些问题。需要及时修复的缺陷是目前
    Sprint 中的一个新任务,将由项目经理添加到 Sprint Backlog 上并通知开发人员去修复漏洞。

    • 站立会议是团队成员之间交流状态分享信息的机会,而不是向某个管理人员报告
    • 迭代周期内的工作内容一般在迭代开始前已经确定,并不再变化,因此不存在需要在站立会议上由项目经理来决定是否修复
    • 以及,在迭代周期内对于工作内容的变更都应该由产品负责人来抉择,而非项目经理(如前所言为scrum master)
  • “对于敏捷开发和测试中的审查过程,极限编程中的同行评审(peer
    review)思想得到了充分应用。代码和文档的审查追求简单而高效。团队成员两两组成一对,互相评审;有时候,一个开发和一个测试人员也可以组成一对,
    互相协作。这样能够有助于缺陷和问题在第一时间被抹杀在萌芽中。”:作者混淆了peer review与pair programming(或pair work)

  • “敏捷开发还有以下几个关键概念 (Key Issues)”:随后所列出的并非是所谓的敏捷开发的关键概念,user story、continuous integration以及re-factoring属于XP推导的工程实践,stand-up meeting则是scrum的重要部分。
  • “这时候,团队成员按照既定的顺序向项目经理汇报各自前一天完成的任务,所遇到的困难和当天要完成的任务。同时,项目经理更新 Sprint Backlog(一张制作精良的 Excel 表格),并及时解决每个人所提出的问题。”
    • scrum master(作者文中所言的项目经理)并不是团队的管理者
    • 文章开头虽然将scrum master和项目经理作为等价类或是同义词,而从随后的措辞以及任务描述来看,难以逃脱“新瓶装旧酒”的嫌疑,无非是将原有的项目经理冠名为scrum master,而后声称使用了“scrum”或是“敏捷开发方法”(所谓的),但这却丝毫无助于团队或是项目或是组织从“敏捷开发”(所谓的)中获得好处。

随后的具体实例因循如上所述的思想,用于分析在敏捷开发过程中如何进行测试活动的话可以参考,如果被用于某个测试人员具体的工作方式,则。。

“综上所述,本文详细谈论了敏捷开发中测试的各项任务。希望本文有助于正在使用敏捷模式或者打算使用敏捷模式的团队更好得理解敏捷测试。”:我挺怀疑这篇文章是否有所帮助。。

也怀疑文章末尾所提到的前三篇参考文献,作者是否有阅读过,或是只读了其中一部分。

2条评论

Brian 发表评论 取消回复

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据