EMS1.0.0项目的敏捷实践

  1. 云栖社区>
  2. 博客>
  3. 正文

EMS1.0.0项目的敏捷实践

技术小美 2017-11-17 17:03:00 浏览554
展开阅读全文

导读:EcomEMS1.0.0项目尝试了敏捷开发模式,极大地提升了项目的效率与质量。下面,让我们一起看看项目组的做法吧!

【实践1】迭代开发、迭代测试、迭代设计:
EMS1.0.0采用迭代开发方式,共划分4个迭代版本。QARD的配合模式如下图。



每个版本的单元测试都在提测前完成,以确保交给QA黑盒功能测试的代码都经过单测检验。单测未完成,则不允许迭代周期结束。为此,多次出现调整迭代计划情况。

RD
开发下一版本时,QA专注于上一版本黑盒测试。时间允许情况下,QA会提前配合RD做下一版本单测。QA测试中发现问题,及时与RD沟通,确认bugRD会及时修正,并交由QA即刻验证。

此外,详设撰写也采用分阶段迭代方式,使得 RDQA 都能先从整体把握项目全貌,避免一开始就纠结于各种细节。测试设计与产品设计并行,提升效率同时保证了文档质量。

【实践2FeatureList
SQA建议下,EMS的两模块分别做了Feature List,开发过程也据此划分。每个开发版本完成的功能都是Feature List的一部分,且每个版本都是可交付,可run的,功能相近的feature划分在同一版本中。正是因为有了基于Feature List制定的开发计划,QA的工作才更加清晰明了,每一阶段的测试点才更加明确。对应RDFeature ListQA制定了自己的测试计划,也是按表格的形式展现(如下图所示):




【实践3】单元测试:
EMS两个模块在单测上采取了不同的投入力度,表现出截然不同的效果。




Broker
模块的单测成本较高,考虑到单测需要启动桩,且桩数据构造成本较大,所以单测投入相对较少,代码分支覆盖率低(仅为15%),但黑盒测试阶段发现bug多(38个),耗时长(200人时)。

Storage
模块则与之相反,单测投入相对较多,代码分支覆盖率高(60%),发现bug数量较多(QA的单测就发现了10个)。在黑盒测试阶段发现bug少(10个),耗时很短(80人时)。

通过实践对比,可以看出单元测试与黑盒测试之间的密切关系。

另外,在设计、开发过程中应考虑代码的可测性 ,可测性低的代码将带来较高的单测成本(有的甚至没法单测),并最终造成QA在黑盒测试投入较多的时间。

【实践4QARD坐在一起:
EMS项目中,QARD坐在同一片区域,QA背后是RDRD脑后是QA。有问题,大家都是扭过头来就讨论,EMS项目中遇到问题都是当面沟通,马上解决,效率极高。当然,为防打扰别人的思路,一般会先在hi上说一声。

【实践5】跨职能团队:
EMS
迭代开发中的协作非常紧密与高效。敏捷团队中的角色并非一刀切,关键是合理协调人力,有序分工,充分配合。当某一版本周期紧时,QA主动协助RD单 测;项目后期,RD开始直接使用QA开发的自动化测试工具与测试数据进行测试。另外,模块级的性能测试都由RD同学完成,灾难恢复类的测试则由OP完成, 而QA只是提供测试环境和机器。

在这样一个氛围融洽的项目团队里,EMS1.0.0成功上线,并获得了两项商务搜索部的创新奖,那让我们来看下这个高效的敏捷团队吧!

 

 

本文首发于:百度测试技术空间http://hi.baidu.com/baiduqa/blog/item/3009e1f94538aa7d034f5693.html
关注百度技术沙龙
















本文转自百度技术51CTO博客,原文链接:http://blog.51cto.com/baidutech/743417,如需转载请自行联系原作者

网友评论

登录后评论
0/500
评论
技术小美
+ 关注