什么时候应该编写BDD测试场景[[关闭]

一般来说,在Scrum中,您希望用户故事也有满足的条件。意思是,如果这些条件都满足了,我作为一个产品所有者,会很满意这个故事是完整的。

最好由产品负责人编写,如果是以给定的/When/Then格式编写,效果更好。这样团队就可以根据满足的条件创建BDD测试。测试通过后,故事就完成了。

在产品负责人认为有必要确认故事已经实现时,应该有尽可能多的满足条件,这些条件应该在sprint计划会议上及时准备好。它们不需要编码,但是应该写出来,这样团队就可以知道需要什么来完成这个故事。

如果BDD的意思是“行为驱动的开发”,那么你可能会被“测试”这个词绊倒。

如果您正在寻找BDD(也称为验收测试驱动开发),您可能愿意在Sprint计划发生之前尽早开始编写验收测试。其他一些“更敏捷”的方法倾向于将此推迟到最后一个负责任的时刻,我已经指导了几个团队,在Sprint期间,验收标准也会随着时间的推移而不断完善。

开发团队的“测试人员”在为下一个Sprint(称为look ahead)准备Backlog的过程中与产品负责人密切合作,并且在当前Sprint期间,当他们认为符合PO时,他们丰富了验收标准。

BDD的目标是从行为的角度来驱动软件的开发,这应该给你一个非常清晰的“方法”,告诉你如何以及何时编写验收标准。我发现它们与用户案例的INVEST清单以及Ready for you Backlog的定义结合起来非常有用。

安德烈