您如何管理 bdd 功能和场景？
我们正在使用 Specflow 采用 BDD。我们面临的问题是，不能指望产品所有者和经理进入 Visual studio / svn 并编辑功能或场景。
我们可以让下午在谷歌文档中完成这一切，然后我们可以将它们复制并粘贴到功能文件中，但这很容易出错，并且很快就会失去同步。
管理此问题的最佳实践是什么？
We are adopting BDD using specflow. The issue we have is that product owners and managers can not be expected to go into Visual studio / svn and edit features or scenarios.
We can get the pm's to do it all in google docs, and then we can copy and paste them into feature files, but this will be error prone and will get out of sync very quickly.
What is the best practice for managing this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
一般来说，产品所有者或业务分析师不应该自己编写功能，因为这可能会导致结构不良、无法测试的场景。
一种常见的方法被称为“三个朋友”——业务利益相关者、开发人员和测试人员一起工作来编写场景。
可以使用 Google Docs 进行初始草稿，但之后功能应存储在版本控制中，并且 PO/BA 应与具有源代码控制访问权限的开发人员合作进行更改。
您应该通过从 Intranet 或 wiki 链接到版本控制的功能文件，或者使用 津津有味。
Product owners or business analysts should, in general, not be writing features on their own, as this can lead to poorly structured, untestable scenarios.
A common approach is known as 'the three amigos' - a business stakeholder, developer and tester working together to write scenarios.
It's fine to use Google Docs for the initial draft, but after that the features should be stored in version control, and the PO/BA should collaborate with a developer who has source control access on making changes.
You should make the version-controlled feature files easily accessible for review and reference to business stakeholders by linking to them from your intranet or wiki, or using a tool such as Relish.
我们在我工作的公司所做的是，大多数业务分析师（也就是编写故事的人）知道如何使用 SVN，编写故事，甚至运行测试（在我们的例子中，它不是 Specflow，而是 Cucumber） ）。他是那个与产品所有者/经理交谈并将新功能/需求写成故事的人。换句话说，将任务委托给具有一定编写故事或场景经验的人员（BA 或 QA），并且能够运行它们并在发生问题时进行故障排除。沟通是这一切的基础。如果你没有这个人，那么...尝试得到他:)
What we have done in the company I work for is, most of the Business Analysts (which are the ones that write the stories) know how to use SVN, write the stories and even run the tests (in our case it's not Specflow but Cucumber). He is the one that talks with product owners/managers to write the new features/requirements as stories. In other words, delegate the task to someone (either a BA or a QA) who has some experience writing stories or scenarios and be able to run them and troubleshoot if something bad happens. Communication is the base of this. If you don't have this person, well... try to get it :)
Matt Wynne 关于使用 Cucumber 是一本很好的读物。让每个人都使用通用语言，并为整个团队提供单一的事实真相。
查看 Pickles 来很好地输出您的功能 https://github.com/x97mdr/pickles/wiki
Matt Wynne on Using Cucumber is a good read. Getting everyone talking ubiquitous language and having a single point of truth for the whole team.
Check out Pickles for outputting your features nicely https://github.com/x97mdr/pickles/wiki