Interestester

 

В этом смысле помещение записи в базу через клиентский API или даже UI и проверка наличия заявки в базе через API/UI менеджера - хорошая практика.

получается что вот этот сценарий я не использую

*Scenario: See sent request in backend*
    Given user goes to Sell car page
    When user fills 'phone' with '0000000000'
    And user clicks Submit
    And backend user is logged in
    And user goes to Backend leads page
    Then user should see '0000000000' in 'phone'

а вместо у него будет что-то (до API еще не добралась, жду его) типа такого:

Scenario: See sent request in backend
 Given request was sent through API with parameters: "0000000000", ...(тут еще параметры если нужны))
 Then manager goes to List of requests
 And  manager should see '0000000000' in 'phone'

и вот такое

Scenario: Sent request by client
 Given client goes to Sell car page
 When client fills 'phone' with '0000000000'
 Then API with parameters: "0000000000", ...(тут еще параметры если нужны)) should be received 

правильно?

1) Определитесь с ролями в системе. Кто такой frontend user? сдается мне, что это банальный client, причем даже не факт что зарегистрированный.

2) В сценарии может быть столько взаимодействующих сущностей и ролей, сколько нужно для его выполнения. 

3) Feature, который по факту user story должен звучать: Как <Роль> я могу <Действие>, так что <Бизнес-ценность>

4) Сценарии, которые ко факту use case должны описывать все возможные способы как роль достигает бизнес-ценности

5) Бизнес-ценностью, похоже. является наличие у менеджера информации о желании клиента пообщаться "клиент, номер телефона для звонка и некоторый сет данных my car"

6) Ничего конкретного не порекомендую, я читал блоги, статьи и проектную документацию, писал некоторое количество end-to-end тестов на кукумбере. Той кашей которая в итоге получилась я и делюсь с вами.

1) да. но его надо же как-то отделить от бекенда. раз они вдвоем в одном сценарии

5) именно так. но в таком случае user story вообще странное получается. Как менеджер, я хочу получать заявки клиента на обратный звонок, так что я могу продать ему машину. Либо. Как пользователь, я могу отправить запрос на обратный звонок, так чтобы не приходилось звонить самому.

1) вы явно путаете backend user и user в последнем сценарии.

2) лучше 3-е лицо. Иначе у вас начнутся пересечения сценариев разных ролей. Либо каждый сценарий должен определять какую роль имеет ваше I и выполнять шаги исходя из ее контекста

3) каждый сценарий должен нести бизнес-ценность, не думаю что бизнес-ценность сценария показать пользователю "Thanks page"

 

Учитывая инструментарий - смотрите классическую литературу по работе с user-story и use-case.

спасибо большое! и пара новых вопросов тогда, если можно.

первого юзера тогда заменить на frontend user? это вообще нормально использовать двух юзеров в одном сценарии?

про бизнес-ценность. в этом случае должен быть один сценарий на фичу. по сути последний?

про user story и use-case я была уверена, что читала достаточно. но похоже что не то, раз не получается. Не могли бы вы пожалуйста подсказать что является классикой?