去年12月, infoQ采访了《实例化需求》作者,在采访中作者给出了一些阅读本书的建议和原则,帮助大家在软件开发项目中采用实例化需求去创建活文档。实例化需求是一组方法,它以一种对开发团队有所帮助的方式(理想情况下表现为可执行的测试)描述计算机系统的功能和行为,让不懂技术的利益相关者也可以理解,即使客户的需求在不断变化,它也具有很好的可维护性,可以保持需求的相关性。
敏捷测试不再是空谈,看过本书后,成功的交付高质量软件不再难。
1、对于敏捷项目,构建正确文档的关键因素。见下图:
2、避免使用“敏捷”术语
敏捷软件开发的方法饱受术语和流行语的困扰。Scrum、立会、用户故事、功能清单(backlog)、大师(master)、结对编程,以及其他一些诸如此类的术语,很容易让人产生误解并导致混乱。对有些人而言,它们甚至会喧宾夺主,让人提心吊胆。术语造成的焦虑,是导致大家回退到从前并抵制任何过程变更——或者被动地等待失败到来的一大原因。(我想这是大部分人的困扰)
3、在迁移过程中,遗留脚本也要有人维护
使用新的工具去重写功能测试并将它们自动化需要一定的时间。在新的验证系统成长到一定规模前,现有的测试应该予以维护,并使其保持更新。解决这个问题的一个好方法是:在做近期计划时,委托一个人专门去维护并更新老的测试。
4、对敏捷开发创建文档最基本的认识
敏捷初学者会认为敏捷是没有文档的,这不是事实。敏捷建议我们要选择那些有用的文档。对那些害怕没有文档的人而言,这样的测试是一个保护他们自己的绝佳机会,同时可以让他们看到在敏捷过程中仍然是有文档的,而且那并不是两英尺高的一大堆纸,而是一种更轻量级但紧密绑定在实际代码上的文档。当你询问‘你们的系统是否有这种功能’的时候,你没有一份用来记录系统功能的Word文档,相反你有一种可以执行的东西,可以证明系统就是按照你的想法在运行。那才是真正的文档。
实例化需求说明是把需求与测试紧密结合的一种协作方法。这种方法有4个显著优点:可以生成可靠的活文档;可以清晰地定义出预期结果并使得验证更为高效;能减少返工;最重要的是,可以确保交付团队与利益相关者一起构建的软件符合预期的目的。
本书面向开发人员、测试人员、分析师以及业务人员,指导他们共同构建优秀的软件产品。本书的案例分析涉及的对象既有小型互联网创业公司,也有大型的金融服务公司,书中介绍的方法适用于不同的软件过程,包括极限编程、Scrum以及看板。书中主要内容包括: • 常见的过程模式 • 如何避免错误的实践 • 在过程中引入实例化需求说明 • 50多个案例分析
想知道成功的开发团队如何交付正确的软件?看看本书便知!
“独一无二的、基于大量的业内研究提取出来的知识。” —— Mike Stockdale,Syterra软件公司
“本书是我的挚爱,它教会我如何正确地做测试。” —— Craig Smith,Suncorp公司
“本书将改变我们讨论和思考测试的方式。” —— David Evans,ThinkAlike咨询公司
“本书是有关需求收集与维护的最好的图书。” —— Oleksandr Alesinskyy,NAVTEQ
“基于众多团队的经验,它将让你的测试自动化事半功倍。” —— Rick Mugridge,Rimu研究公司
Gojko Adzic是战略软件交付顾问,他与多个具有上进心的团队合作,帮助他们改进软件产品和过程的质量。他专注于实施敏捷和精益的质量提高,尤其擅长敏捷测试、实例化需求和行为驱动开发。Gojko经常在重要的软件开发和测试会议上发言,并运营着英国的敏捷测试用户小组。最近这11年来,他一直在财务和能源交易平台、移动定位、电子商务、在线游戏和复杂配置管理系统等行业项目中,从事程序员、架构师、技术指导和顾问等工作。
实例化需求术语解读
测试驱动开发的艺术