Перейти к содержимому

Фотография

Помогите разобраться со сценариями на Gherkin

gherkin сценарии

  • Авторизуйтесь для ответа в теме
Сообщений в теме: 6

#1 Interestester

Interestester

    Новый участник

  • Members
  • Pip
  • 4 сообщений

Отправлено 03 февраля 2016 - 11:38

Начинаем автоматизировать проект. Много дебатов с коллегами, поэтому решила вынести на всеобщее обсуждение.

Feature: As a user I want to sent request with data of my car So backoffice user can call me**
     *Scenario: Send sell request successfully*
    Given user goes to Sell car page
    When user fills 'phone' with '123456'
    And user clicks Submit
    Then Thanks page should be opened
    *Scenario: Send sell request with errors*
    Given user goes to Sell car page
    And user clicks Submit
    And error message for 'phone' is visible
    When user fills 'phone' with '77777777'
    And user clicks Submit
    Then Thanks page should be opened
    And error message for 'phone' should be not visible
    *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'

Честно говоря приветствуется любая критика. Особенно волнуют следующие вопросы:

1. Первое или третье лицо использовать в сценариях?

2. Можно ли смешивать бекенд с фронтендом?

 

Буду благодарна за любые ресурсы, которые помогут мне писать сценарии мечты, а также за ответы.


  • 0

#2 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 03 февраля 2016 - 13:44

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

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

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

 

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


  • 0

#3 Interestester

Interestester

    Новый участник

  • Members
  • Pip
  • 4 сообщений

Отправлено 03 февраля 2016 - 14:05

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

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

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

 

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

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

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

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

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


Сообщение отредактировал Interestester: 03 февраля 2016 - 14:08

  • 0

#4 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 03 февраля 2016 - 15:29

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

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

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

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

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

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


  • 0

#5 Interestester

Interestester

    Новый участник

  • Members
  • Pip
  • 4 сообщений

Отправлено 05 февраля 2016 - 10:46

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

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

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

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

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

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

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

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


  • 0

#6 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 05 февраля 2016 - 12:33

1) У вас есть роль Клиент и роль Менеджер - оперируйте ими

5) Ничего странного. Получаете 2 сценария для первого предусловием является наличие заявки в базе, для второго наличие заявки в базе является условием успешного выполнения.

6) при этом стоит помнить что юскейсы со стороны менеджера не ограничиваются просмотром заявок и что сценарий который проверит прохождение заявки от клиента до менеджера НЕОБХОДИМ, иначе прохождение всех тестов не гарантирует что роли клиент и менеджер работают с одной базой, или что клиент не сохраняет заявку в базу так, что у менеджера все падает и ничего не работает. В этом смысле помещение записи в базу через клиентский API или даже UI и проверка наличия заявки в базе через API/UI менеджера - хорошая практика.


  • 0

#7 Interestester

Interestester

    Новый участник

  • Members
  • Pip
  • 4 сообщений

Отправлено 05 февраля 2016 - 14:53

 

В этом смысле помещение записи в базу через клиентский 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 

правильно?


  • 0



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных