Как написать файл функций и когда преобразовать их в определение шага, чтобы приспособиться к изменяющимся требованиям бизнеса?

Я работаю над проектом веб-разработки и тестирования BDD с другими членами команды.

Сверху мы пишем файлы функций в gherkin и запускаем cucumber для генерации пошаговых функций. Внизу мы пишем модели страниц Selenium и скрипты библиотек действий. Остальное - просто заполните пошаговые функции скриптом Selenium и, наконец, запустите варианты огурца.

Звучит достаточно просто.

Проблема начинается, когда мы пишем файлы функций.

Проблема 1. Требования нашего клиента меняются каждую неделю по мере реализации проекта в отношении удаления старых и добавления новых.

Проблема 2. Кроме того, для некоторых функций подробные инструкции также постоянно меняются.

Проблема становится действительно серьезной, если мы каждый день пытаемся генерировать обновленные пошаговые функции на основе обновленного файла функций. Чтобы синхронизировать пошаговые функции и файлы функций, необходимо провести некоторую уборку.

Чтобы решить проблему 2, я вспомнил, что одно из основных правил при написании файла функций gherkin - как можно больше использовать язык бизнес-домена. Поэтому я попытался убедить BA написать файл функций немного более расплывчатым и не включать в него слишком много шагов, специфичных для пользовательского интерфейса, чтобы нам не приходилось часто изменять файлы функций / пошаговые функции. Но она колеблется, потому что в документе с требованиями клиента есть подробности, и она просто пытается следовать.

Чтобы справиться с проблемой 1, у меня нет решения.

Итак, мой вопрос:

  1. Есть ли хороший способ написать файл функций, чтобы на него меньше влияло изменение требований клиента? Можем ли мы написать его расплывчато, чтобы опустить некоторые детали, которые могут измениться (по крайней мере, таким образом мы сможем стабилизировать прототип пошаговой функции), и если да, то как далеко мы можем зайти?

  2. Когда подходящее время для создания определений шагов и заполнения содержимого? С самого начала или подождать, пока характеристики немного стабилизируются? Как часто мы должны это делать, если функция продолжает меняться? А есть ли удобный способ убрать устаревшие пошаговые функции?

Любые мысли приветствуются.

Спасибо,


cucumber bdd gherkin
person user1559625    schedule 10.12.2015    source источник
comment
Вы можете привести пример требования, которое изменило сценарий и шаги? Отсюда у людей могут быть идеи. Я думаю, что в целом хорошо писать новые шаги (а не менять их). Если на этапе основное внимание уделяется тому, как, а не что, то вам требуются изменения чаще. Шаг должен быть «Когда я отправляю заказ», а не «Когда я нажимаю кнопку отправки». Первое дает больше возможностей для изменений. А если вы используете рубиновую версию огурца, вы можете использовать ярд-огурец для автоматического документирования ваших шагов. Это действительно здорово - видеть, используются ли шаги и сколько раз.   -  person Dave McNulla    schedule 10.12.2015
comment
Поскольку вы пытаетесь создать эту живую документацию и включить детали, важные для клиента, ответ прост. Имейте один сценарий, в котором подробно описываются и тестируются часто меняющиеся детали, но мало функционального тестирования, а затем есть другой сценарий, который проверяет функциональность. Другими словами, БА может написать один подробный сценарий, который является поверхностным и будет изменяться (возможно, тестирует метки полей формы на странице редактирования пользователя, но не отправляет форму), а затем другой, который фактически проверяет функциональность редактирования пользователя. Теперь вы отделили изменение от неизменного.   -  person Jeff Price    schedule 10.12.2015

Ответы (1)


arrow_upward
1
arrow_downward

Если у вашего клиента есть особые требования к пользовательскому интерфейсу, для которых вы заключили контракт на предоставление автоматизированных тестов, вам следует писать их с помощью реальных инструментов автоматизации тестирования. Cucumber не является инструментом автоматизации тестирования . Если вы попытаетесь использовать его как таковое, вы просто причините себе много боли напрасно..

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

В любом случае вы в конечном итоге потерпите неудачу, если не будет реального сотрудничества с вашим клиентом. Если они регулярно навязывают новые бизнес-правила или новые бизнес-требования через транец, через который вы ограничены или не видите, то вы находитесь в безвыходной ситуации.

person Greg Gauthier    schedule 21.12.2015