Как делить и классифицировать фича-файлы

#1

Добрый день, коллеги.

Прошу совета, как у более опытных.

Столкнулся с тем, что не могу понять как правильно разделять фича-файлы. проблема скорее в терминах и понятиях.

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

Пока все понятно.

А как быть с тем, когда тестируемая фича пересекается с другой фичей?

Например, фича - настраиваемый нумератор объекта (справочника или документа)
Кроме самого объекта “Нумератор” разработка этой фичи затрагивает другой объект - справочник ОбъектыМетаданных, который по сути является агрегатором настроек для конкретного бъекта метаданных. В т.ч. и настройка нумерации его с помощью разрабатываемого нумератора.

Сам справочник “объекты метаданных” тоже фича продукта и у него тоже есть свой фича файл со сценариями.

Таким образом технически разрабатывая новую фичу я добавляю в существующую фичу доп функционал.

Как правильно будет распределить сценарии по фича файлам.?

Если я все сценарии связанные с новой фичей логически запихну в один фича-файл “Нумераторы”, то как я потом прогоню регресс только по фиче “объекты метаданных” ?

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

Возможно ответ в тегах и тогда можно делать фичафайлы мельче и тегами их метить, тогда один фича файл с пересекающимися сценариями будет гоняться в регрессе в обоих случаях, когда я буду проверять нумераторы и объекты метаданных по ситуации.
Но в этом случае нарушается представление о том что такое feature.

Подскажите, как вы делаете в таких ситуациях?

#2

Если я раскидаю сценарии по новой фиче согласно логике разработки

Вот здесь торчат уши основной причины проблем.
Фича - это кусочек пользы для конечного пользователя.
Чтобы было проще на это смотреть с этой стороны, нужно для каждой фичи честно писать user story в формате

Я как <Роль>
Хочу <Действие>
Чтобы <Цель (чтобы что?)>
#3

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

#4

Есть лайвхак в такой ситуации - использование https://github.com/picklesdoc/pickles
И структура папок для фича файлов.

Порядок действий такой

  1. с заданой периодичностью формируешь DOC файл
  2. в секции content смотрится на возникшую структуру - она должна быть последовательна по логике системы с иерархией в 2 уровня
  3. Рефакторинг структуры каталогов

То есть как только возникает неудобство с пересечением фича файлов, нужно взглянуть на структуру файлов.

Такой подход придумал Мэт Вейн при разработке своего RelishAPP

#5

Фича 1:

Функционал: Настраиваемая нумерация объектов - подсистема нумератор
Как Администратор системы
Я Хочу произвольным образом настраивать нумерацию справочников и документов
Чтобы Нумеровать объекты способом отличным от стандартного

Фича 2

Функционал: Настройка объектов метаданных
Как Администратор системы
Я Хочу настраивать отображение и поведение объектов метаданных в режиме 1С Предприятие
Чтобы Менять поведение объектов системы, не используя конфигуратор.

#6

Если исходить из утверждения, что эпик - это компонент системы.
Скажем подсистема “Нумератор” в моем случае это эпик, который состоит из одной user-story.
Подсистема “объекты метаданных” - Это другой эпик и у него много userstory.

Стал быть эпики это каталоги, истории это фича файлы. И структура такая.

  1. Подсистема “Нумератор”
    1.1. Создание правил нумерации объектов
  2. Подсистема “объекты метаданных”
    2.1. Настройка нумерации объекта метаданных

То есть в моем случае user-story не одна, а две, значит и фича-файлов тоже два.

А чтобы прогонять весь регресс по ОбъектамМетаданных, каждый фича-файл я помечаю тегами по эпикам: @numerator, @metadata

Затем после разработки новой фичи в подсистеме “объекты метаданных” я могу по тегу @metadata сказать дженкинсу проверить еще и этот прежний фича файл. Верно?

??? Еще нужно проверить что нумератор нумерует по указанным правилам. Куда логичнее поместить эту проверку? Ведь чтобы заработало нужно и создать нумератор и подключить его в настройках. Создавать еще одну юзерстори и включать его в эпик “Нумератор” ? чтобы структура каталогов была понятной.
Мне кажется. что это неверно. Проверку нужно включить в одну из двух историй, а не создавать новую.

#7

??? Еще нужно проверить что нумератор нумерует по указанным правилам. Куда логичнее поместить эту проверку? Ведь чтобы заработало нужно и создать нумератор и подключить его в настройках.

Звучит так, что это про проверку нумератора, а

нужно и создать нумератор и подключить его в настройках.

Это относится к инфраструктуре, т.е. в контексте нумератора это вспомогательные действия.

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

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

#8

Да. в точку ))
В одном сценарии проверяю через UI, в другом. где это вспомогательные действия, делаю программно.
Подмывает все залепить одним сценарием, но это не правильно с точки зрения уровня тестирования.
Один сквозной сценарий - это типо приемочный и по нему можно делать видео-инструкцию для пользователей.
А функциональные тесты они более атомарные и проверяют одну функцию за раз. Отсюда неизбежно дублируются сценарии и шаги.

#9

image
image.png1250×804 234 KB

Мы так делим (стырено отсюда https://bit.ly/2MqFsON)
В рамках такой классификации удобно проверять “чтобы что” о котором писал @kuntashov выше.

Можно раскладывать по папкам и выводить в pickles, можно использовать спеклог (https://www.speclog.net/) . Можно с помощью шагов @pumbaE группировать раздел behavior в отчете allure

image
image.png1852×587 108 KB

Мы делаем свой инструмент для уопрядочивания на основе техники StoryMapping
image
image.png1776×770 124 KB

Но в любом случае BDD это про поведение пользователей, а не про технические фичи.
Так что как бы не делили , а писать истории в формате, написанным Сашей нужно :wink:

2 Симпатий
#10

То есть если я правильно понял.
BDD - это проверить один конкретный очевидный сценарий пользователя для каждой полезной фонкциональности?

Если нужно:

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

то это тоже BDD?

Правильно ли, что на каждую функциональность (квадратик зеленый, как на скринах выше) пишется отдельная история, а на каждую историю пишется один фича-файл с набором всех нужных сценариев (изолированных) ?

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

#11

Сценарий: накладная с незаполненным контрагентом НЕ должна проводиться

Да. Это самое что ни на есть BDD.

Да

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

#12

Можно запустить в плеере все фичи (или сценарии) с определеным тегом.

Это только при условии строгого порядка запуска, о чем, в общем-то, нужно тоже специально озаботиться, и просто использования тэгов и опции “строгий порядок” для этого мало.

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

“Серебряной пули нет…” (с) (и да, есть люди Серебряная пуля и все такое))).

1 Симпатия
#13

Спасибо, коллеги.

В целом кое что вырисовалось в понимании этого хозяйства.

#14

Самодостаточность дело тонкое.
У нас же есть процесс заказчика который дожен выполняться. И может быть такой момент что по одной все выполняется, а вместе не работает)
Ну это уже вопрос техники, тактики, размеров проекта, качества фич etc

2 Симпатий
#15

Самодостаточность дело тонкое.

Согласен.

#16

Кстати - пока не забыл про людей Серебряная Пуля.

Мэт Вейн проводит вебинар по cucumber.pro 8-го августа, как раз по данной тематике и своему новому продукта. Бог с ним продуктом - но как раз в тему https://zoom.us/webinar/register/6015330482561/WN_Aydr3t39TgiRTcfnnxpDYw

1 Симпатия
#17

Я уже потестил вчера. Кривовато как-то для трех лет ожидания. Релизы и комменты в гит не ложатся, а хранятся в базе. Но послушать можно.

#18


еще вебинар по теме