实例化需求并不是一个新的思想,而是80年代晚期就被提了出来。为什么实例化需求没有被发扬光大,作者认为业界走了弯路。如何能够做到实例化需求呢?可以从两方面做起:改变过程,改变团队文化

过程的改变可以从以下几点做起: 如果已经在进行一个过程变更,那么就通过它实现实例化需求说明的主要思想。 将实例化需求说明的思想当做改善产品品质的灵感。 为那些没有自动化功能测试的团队,实施功能测试的自动化。 对那些自动化测试与开发环节脱离的团队,引入自动化的可执行需求说明(作者好想比较推崇Fitnesse)。 对那些时间测试驱动开发的团队,使用TDD作为下一步的踏脚石。 一些tips: 可以把实例化需求作为更大变革中的一部分。打到包里好办事儿(经验看的确如此)。 把重心放在专注于质量提高上,而不是改变上,两者可以相互促进。 如果开发人员和测试人员不紧密合作,这事儿就不好成。 不要一开始就实例化需求,先从把功能测试自动化做起来开始。 在实现功能测试自动化自动化的时候要做好工具选型,工具要适合实例化需求。 团队文化的改变从以下几点做起: 避免使用“敏捷”术语。从帮助团队提高质量和开发效率的一点一滴做起,每一步都起到实效。 获取管理层支持。因为需要显著改变工作方式,不可避免会遇到阻力。 把实例化需求当做是比执行验收测试更好的方式来推销。酒香也怕巷子深。 不要让自动化测试成为最终目标。 不要太拘泥于工具。实例化需求并不以程序员为重心,程序员独立使用一个工具不会取得良好效果。 在迁移过程中,注意需要有人维护遗留脚本。 跟踪那些人在运行/没有运行自动化检查程序。