【问题标题】:How to avoid duplicity of user stories for different users?如何避免不同用户的用户故事重复?
【发布时间】:2019-08-07 09:08:50
【问题描述】:

我是 BDD 的新手,所以我在一些基本概念上苦苦挣扎。

目前我正在为简单的功能创建用户故事:登录到设备。
基于 BDD 方法,我必须分别为每个(类型)用户编写用户故事,所以我最终得到了这个:

作为经理,我想登录以便使用终端。
作为服务器,我想登录以便使用终端。
作为订单接受者,我想登录以便使用终端。
作为调酒师,我想登录以便使用终端。
作为一个厨房,我想登录以便使用终端。

...

对于每个角色和每个故事,关于如何登录以及用户在登录后应该在哪里结束(基于他的状态、一天中的时间等),我都有略微不同的场景。我认为场景还可以。

我有点困惑,如果故事应该这样写?

谢谢

【问题讨论】:

    标签: bdd user-stories


    【解决方案1】:

    故事模板:

    As a ...
    I want ...
    So that ...
    

    最初是在大多数瀑布项目的背景下创建的。在那些日子里,利益相关者只有一次机会在最终发布之前请求他们认为可能需要的所有东西,之后更改变得昂贵。

    现在发布多个迭代版本当然更容易了,因此我们尝试专注于会产生影响的小事情。该模板仅用于回答三个问题,帮助区分发布所需的内容和不需要的内容:

    Who is it who wants this?
    What do they want?
    Why do they want it?
    

    所以,如果你能回答这三个问题,那就是一个好故事。而且你知道,多人想要同样的东西是可以的!至于模板,它只是帮助你习惯问这些问题的“训练轮”。

    当我们开始做 BDD 时,场景只是某事物行为方式的一个示例。因此,如果场景的行为相同,我们不需要为每个人提供一个场景。我们可以随便挑一个作为例子。

    Given Sue is registered as a server
    When she logs in
    Then she should be taken to the terminal.
    

    当然,如果不同的角色有不同的终端,你可能需要几个;但是如果所有不同的角色都被带到不同的终端,那么可能会让开发人员将它们放在类级别的单元测试中。你只需要一个例子。

    最后,不要从登录开始。想象一下他们已经登录(如果必须的话,可以硬编码)并弄清楚他们登录的目的是什么。这是一个更有趣的场景。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2018-05-03
      • 2010-12-15
      • 1970-01-01
      • 2017-09-09
      • 1970-01-01
      相关资源
      最近更新 更多