Визуализация фич Vanessa Automation в StoryMapper

Публикация № 1214031

Методология - Методология управления разработкой - Agile (XP, SCRUM, Канбан)

bdd VA StoryMapper

Описан процесс визуального упорядочивания коллекции feature-файлов в виде карты пользовательских историй. Используется инструмент гибкого управления требованиями StoryMapper.

Введение

Те, кто следит за развитием проекта Vanessa Automation, могли заметить, что в релизе 1.2.030 появились изменения в feature-файлах, связанные с задачей "Адаптация feature-файлов проекта VA для использования в StoryMapper". В своём большинстве эти изменения такого вида:

Закономерный вопрос: что это за теги и зачем они нужны?

В наших предыдущих статьях ([1], [2]) упоминался StoryMapper - инструмент для организации feature-файлов в виде карты пользовательских историй. В статье [2] он использовался для организации разработки по методике BDDSM, в [1] предлагалось использовать его для упорядочивания своего репозитория feature-файлов. В этой статье мы хотим продемонстрировать, как можно использовать StoryMapper для упорядочивания ваших фич, так чтобы их было удобно и наглядно демонстрировать вашему руководству или стейкхолдерам.

По согласованию с @Pr-Mex (aka Леонид Паутов) мы решили провести такое упорядочивание на примере очень большой коллекции feature-файлов (порядка 700) из ветки develop репозитория Vanessa Automation. Цель данного действия: визуализировать и тем самым повысить прозрачность и понимание того, как работает Vanessa Automation. На сегодняшний день feature-файлы VA распределены по тематическим папкам, но их распределение носит отражение технического подхода к их написанию (регрессионное тестирование), а не точки зрения пользователя или возможного нового контрибьютора. Составление карты историй позволит поменять перспективу рассмотрения feature-файлов и взглянуть на них под пользовательским углом.

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

 

Выбор UF

Первый этап упорядочивания - это составление скелета карты пользовательских историй. Скелет в StoryMapper состоит из двух уровней: UF (Usage Flow) и UA  (User acivity). Верхний уровень - это некие крупные блоки пользовательской активности, которые мы ожидаем от продукта. В случае VA и её feature-файлов нужно понимать, что не все фичи относятся к пользовательской активности по своей техногенной сущности, соответственно и UF будут не всегда о пользователях.

Итак, мы выделили ряд UF, которые описывают пользовательский опыт взаимодействия с VA, другие, в которых будут содержаться фичи с библиотечными шагами и с особенностями реализации Gherkin, вспомогательные технические фичи, которые в VA используются как макеты данных для учётных задач (данные для тестирования), и отдельный UF для (пока) неклассифицированных фич.

Напомню, что в самом начале процесса все фичи репозитория будут лежать в первой колонке под UF0 - поскольку они ещё ни к чему не привязаны.

 

Составление UA

Второй уровень составить было сложнее. Поскольку разработка VA шла не от карты пользовательских историй, а по пути инкрементного наращивания функционала, нельзя было просто взять и составить список пользовательских активностей. Поэтому мы восстанавливали UA обратным ходом - от US. Когда под UF0 находилась очередная фича, про которую было понятно к какой UF она относится, но под этой UF не было подходящей UA - тогда подходящая UA создавалась.

То, что не получалось никак классифицировать, то уносилось под "UF11 Прочее", чтобы потом можно было разобраться более тщательно. Понятно, что сразу получались какие-то избыточные сущности и при повторном проходе что-то сливалось, что-то удалялось. Но в итоге удалось получить картинку более-менее соответствующую реальной пользовательской активности. На картинке поместились далеко не все UA, полную версию можно посмотреть в StoryMapper (доступы в конце статьи).

 

Разнесение фич под UA

Из предыдущего раздела уже понятно, что UA формировались по ходу разнесения фич. Основная цель, которую мы преследовали на первом этапе - это сделать так, чтобы под UF0 не осталось ни одной фичи. Чтобы все они стали классифицированными, а  уж потом можно переподчинять их согласно реальному предназначению. То есть к текущей версии карты пользовательских историй я пришёл за 4 итерации упорядочивания. Во-первых, вынес все фичи из-под UF0, во-вторых, отделил реальные фичи от служебных, которые используются как макеты, в-третьих, пересмотрел подчинённость фич пользовательским активностям, и в-четвёртых, получил результаты выполнения сценариев и, соответственно, увидев те фичи, которые реально выполняются на CI-контуре, убрал вспомогательные фичи с экспортными сценариями в "UF11 Прочее".

Конечно, не обошлось без трудностей. Надо понимать, что StoryMapper работая с feature-файлами, ориентирован не на название файла, а на название фичи, то есть тот текст, который идёт после ключевого слова "Функционал/Функция". Поскольку за уникальностью этого значение в репозитории никто не следил (а за неимением соответствующего инструментария это делать достаточно проблематично) получались ситуации, когда фича вроде бы уносилась из-под UF0, но после отправки изменений в git - возвращалась обратно. В результате пришлось провести работу по унификации названий фич, что на текущем этапе вылилось в добавление цифр в конце названия. В дальнейшем нужно будет либо слить эти фичи в одну, либо дать им более осмысленное название.

 

Отображение результатов выполнения сценариев

Что ещё интересного есть в StoryMapper, кроме карты пользовательских историй. Цифры в правом нижнем углу показывают количество выполненных сценариев. Поскольку в VA всё фичи зелёные (а разве бывает по-другому?) - то и на карте мы видим только цифры на зелёном фоне. Если бы сценарии падали, или у них были бы не реализованные шаги - то эти цифры также отобразились бы на карте на красном или сиреневом фоне соответственно. Данные о результатах выполнения сценариев берутся из json-файла c результатами выполнения в формате Cucumber. Сопоставление идёт по названию фич и сценариев.

Также в StoryMapper можно увидеть и результаты выполнения сценариев в формате Allure (без необходимости ходить на CI-сервер, либо публиковать результаты каким-то иным образом), что позволяет исследовать результаты выполнения до шагов, а также анализировать скрин-шоты в случае падения того или иного сценария.

Отправка результатов сборок формата Cucumber и Allure в Storymapper осуществляется POST-запросом. На сейчас я взял у Леонида json-файлы после очередной сборки и отправил их вручную. Если к инструменту будет проявлен интерес, и им будут пользоваться на постоянной основе, то можно будет вставить запрос по отправке результатов в сборочную линию VA и результаты выполнения сценариев в StoryMapper будут актуализироваться автоматически.

Также в StoryMapper есть полезная функция по выгрузке результата упорядочивания в Excel, выстраивающая табличную иерархию UF->UA->US->Сценарий.

 

Доступы к StoryMapper

Все манипуляции с feature-файлами происходили в моём форке VA, после очередной итерации я создавал pull-request, разрешал конфликты, VACIbot запускал автотесты - и после удачного прохождения тестов изменения по фичам попадали в ветку develop основного репозитория VA. Ветка develop основного репозитория также подключена к StoryMapper, но в режиме "только чтение". Всем желающим посмотреть на фичи VA под другим углом - добро пожаловать:

URLhttps://app.checkushka.com/storymapper/VAdevelop/

login: VA_user

password: BDDSM2020

 

Ссылки:

  1. Полевые исследования концепции «Documentation as code»
  2. BDDSM-практики, или 50 оттенков желтого

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. Pr-Mex 125 21.03.20 15:25 Сейчас в теме
Интересно про реверс инжиниринг активностей пользователя.
Vladimir Litvinenko; 1ceo_2015; +2 Ответить
2. Vladimir Litvinenko 2329 21.03.20 23:47 Сейчас в теме

Вот это красота! Да и не только красота, но и удобство. Как минимум для просмотра и навигации.

В статье Полевые исследования концепции «Documentation as code» одним из направлений развития указано
какая-то интеграция с Jira

Интересно, получилось что-то в этом направлении?

Разделение действительно очень напоминает иерархию/декомпозицию в Jira на проекты, эпики и истории.
Здесь могла бы быть связь UA или UF = эпик, фича = история. Или UF = эпик, UA = история, фича = подзадача. Что больше бы подошло для ситуации, когда по одной истории происходят уточнения и доработки реализуются через отдельные задачи и подзадачи. Для каждого проекта или продукта могла бы быть отдельная страница в StoryMapper. То есть напрашивается ещё один уровень абстракции/организации - "продукты" или "проекты". Так понимаю сейчас это уже реализовано за счет разделения на отдельные подкаталоги для разных проектов вроде storymapper/VAdevelop.

По юзабилити инструмента:
Кажется было бы удобно, если бы окно View/Edit можно было закрывать по клавише Esc. Для закрытия окна реализовано аж два элемента - крестик справа вверху и кнопка Close справа внизу. Но при последовательном просмотре множества фич оба варианта одинаково неудобны - далеко тянуться мышкой и целиться. На автомате рука несколько раз нажимала клавишу Esc, которая сейчас ничего не делает.


Также интересно помещение изменений в репозиторий. Согласно той же схеме в статье на Хабре StoryMapper связан с гит-репозиторием двунаправленно.


То есть в ряде случаев предполагается редактирование фич прямо через него, также как и через Visual Studio Code. Но в таком случае как происходит коммит?

В Visual Studio Code коммит можно сделать согласованно - после согласованного изменения нескольких фич, или например фичи и экспортного сценария, от которого она зависит. А как здесь при работе через веб-интерфейс? Ведь в этом случае при закрытии окна изменения надо сохранить, прежде чем переходить к другой фиче. И судя по всему в этом случае изменение должно приводить к отдельному коммиту. Удобно и правильно ли это?

Вот если можно было отредактировать несколько фич, а потом разом сделать коммит - это было бы классно. Но в этом случае что делать в случае конфликта? Кажется что в этом случае имеет смысл связывать StoryMapper с неким "локальным" репозиторием. А в случае возникновения конфликта предлагать перейти к нему и вручную разрешить возникшие противоречия.

Или я слишком заморачиваюсь и продукт пока далёк от использования в такой роли?
1ceo_2015; +1 Ответить
3. 1ceo_2015 22.03.20 13:39 Сейчас в теме
(2)
Вот если можно было отредактировать несколько фич, а потом разом сделать коммит - это было бы классно. Но в этом случае что делать в случае конфликта? Кажется что в этом случае имеет смысл связывать StoryMapper с неким "локальным" репозиторием.


Так и сделано. Просто у вас доступ readonly.



Соответственно связь изменения репозитория требований к программному продукту с задачами на изменение программного продукта в жире есть (если в коммите указать номер задачи - он появится в этой задаче и в битбакете)



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

Возвращаясь к первому вопросу про более сложные конструкции связей систем управления требованиями и систем управления задачами. Если коротко: такие штуки сложно поддерживать.
Связки Epic - UA US-story использовались нами еще со времен использования Speclog в качестве базовой системы накопления требований. Красиво и прозрачно на первой стадии проекта, страшно и криво на последующих стадиях)). Да и смысл связки сомнителен по причине отсутствия в ней бизнес-целей. Для них приходится городить более высокий уровень абстракции.

Мы используем (и настойчиво рекомендуем остальным на проектах внедрения Jira+StoryMapper) следующую конструкцию: Epic для фиксации бизнес-целей и задачи типа баг и стори в эпике для декомпозиции на понятные для команды разработчиков объемы работы.
Это позволяет привлечь бизнес к структурированию и работе с требованиями, ускорить поставку бизнес-ценности и избежать выполнения ненужной работы.
Естественно это требует изменения способа работы с заказчиком и требованиями и не со всеми это удается сделать.
Такая связка позволяет реверс-инжинирингом собрать разрозненные таски в один бизнес-проект с понятными бизнес метриками. StoryMapper в таком случае выступает пространством для общения бизнес-заказчиков и разработчиков.
На самом деле это тема для отдельной статьи или даже цикла. В рамках комментария описать такое сложно. Будет интересно - можем сделать демо или вебинар по методике.
Прикрепленные файлы:
Vladimir Litvinenko; +1 Ответить
5. Vladimir Litvinenko 2329 22.03.20 18:44 Сейчас в теме
(3)
Спасибо за ответы. Действительно интересно.
Будет интересно - можем сделать демо или вебинар по методике.

Думаю для этого нужно собрать большее количество интересующихся темой. Жаль, что публикация вышла в выходные, из-за этого она может не привлечь достаточное внимание коллег. Демо наверное не стоит - это лучше для заказчиков/покупателей системы )) А вот вебинар именно по методике фиксации и структурированию задач, особенно в связке с Jira, я бы с удовольствием послушал и на платной основе.

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

Вот например этот момент тоже можно было бы осветить. Границы применимости.

Вообще кажется, что большую склонность к такой проработке задач имеют разработчики. Потому что изначально в таком подходе - алгоритмизация и системность. Обычно же ПМ-ы и консультанты больше склонны к мягко говоря частичной систематизации и алгоритмизации при постановке задач, выявлении и фиксации требований заказчика. Часто даже работа ведётся с неверсионируемыми Word-документами или в неком подобии 1С:Документооборота, что создаёт понятные проблемы.

То есть интересен вопрос не только границ применимости с заказчиком, но и процесса перехода к этим подходам самой команды разработки/проектной команды.
1ceo_2015; +1 Ответить
6. 1ceo_2015 22.03.20 19:12 Сейчас в теме
(5)
(5)
Часто даже работа ведётся с неверсионируемыми Word-документами или в неком подобии 1С:Документооборота, что создаёт понятные проблемы.


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

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


(5)
Вот например этот момент тоже можно было бы осветить.


Если совсем коротко description эпика:

как заказчик я хочу улучшить UF (критерии успешности которого у меня уже прописаны и измеряются) до таких-то показателей.

ну и исходя из этого формируем список изменений Критериев Приемки (они же сценарии) или добавляем новые. В конце итерации смотрим на изменение показателей. и делаем новые гипотезы о развитии компании.
7. oleynik.dv 144 22.03.20 20:40 Сейчас в теме
(2) в принципе Фёдор уже всё ответил, но я прокомментирую по поводу общего коммита.


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

1. В StoryMapper он жмёт кнопку Download (эквивалент git pull). При этом все локальные изменения в проекте StoryMapper затираются текущим состоянием ветки в "центральном" репозитории.
2. Бизнес-аналитик работает с картой историй. Создаёт/удаляет/перемещает UF/UA/US, возможно в редакторе StoryMapper вносит изменения непосредственно в фичи.
3. Нажимает кнопку Upload и вводит сообщение коммита. Выполняются команды git add, commit, push. Изменения уходят в "центральный" репозиторий.
4. В клиенте git на рабочей машине выполняет git pull и получает изменения, выполненные в StoryMapper.
5. Работает с фичами в VSC, Sublime, Notepad++, и отправляет изменения в "центральный" репозиторий.
6. При необходимости внести изменения в карту историй возвр. к п.0.
7. Когда доходит до промежуточного результата - мёрджит свою ветку с основной веткой разработки.

Вы можете зарегистрироваться по ссылке https://app.checkushka.com/register.php, и я вам подключу демо-проект, связанный с репозиторием на гитхабе. Там можно будет пощёлкать, потаскать и посмотреть на коммиты в гитхабе.
Vladimir Litvinenko; +1 Ответить
Оставьте свое сообщение

См. также

Vanessa, видеоинструкции для web-клиента

Vanessa Automation v8 1cv8.cf Бесплатно (free)

Vanessa-Automation. Использование видеоинструкций в web-клиенте.

01.06.2020    1465    0    SvVik    1    

Молчание "best practices": тестовые и эталонные данные, структура и связность, падения и новая функциональность, и другие неудобные вопросы к сценарному тестированию

Рефакторинг и качество кода Сценарное тестирование v8 Бесплатно (free)

Непонимание некоторых базовых вопросов мешает программистам начать применять инструменты тестирования в процессе разработки для 1С. Как разобраться в терминологии и интегрировать процесс тестирования в разработку 1С-решений на конференции Infostart Event 2019 Inception рассказал руководитель отдела разработки компании C.T.Consultants Решитко Дмитрий.

29.05.2020    2751    0    grumagargler    14    

Почему Scrum не работает в проектах 1С

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Более точная формулировка заголовка, пожалуй будет такой -  Почему Scrum в чистом виде плохо работает в проектах внедрения продуктов 1С.

18.05.2020    9638    0    MariaTemchina    33    

Тестирование: Отлаживаем и тестируем REST интерфейс 1С с помощью SoapUI

Сценарное тестирование v8 Бесплатно (free)

Рассмотрим быстрый и удобный способ облегчения разработки и отладки REST, SOAP веб сервисов, а также создания автоматизированных тестов.

03.02.2020    4227    0    ivanov660    2    

BDDSM-практики, или 50 оттенков желтого

Методология управления разработкой Vanessa Automation ИТ-компания 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

В статье описаны практические результаты применения методики BDDSM на отдельно взятом РЕАЛЬНОМ проекте поддержки.

26.12.2019    7765    0    Mistress_A    28    

Vanessa Automation + СППР

Vanessa Automation СППР v8 Бесплатно (free)

Vanessa Automation. Использование автоматизированного тестирования в СППР.

07.11.2019    10932    0    SvVik    14    

Vanessa, улучшаем инструкции

Vanessa Automation v8 1cv8.cf Бесплатно (free)

Vanessa Automation умеет делать хорошие инструкции, давайте посмотрим, какие инструменты для этого есть.

30.10.2019    8122    0    OPM    11    

Vanessa, хочу все и сразу

Vanessa Automation v8 Бесплатно (free)

Vanessa Automation это инструмент для тестирования прикладных решений на платформе 1С, но он/она может больше, чем только тестирование.

11.10.2019    9388    0    OPM    20    

Как стать контрибьютором Vanessa Automation?

Практика программирования Разработка Vanessa Automation v8 1cv8.cf Россия Бесплатно (free)

Краткая инструкция о том, как помочь проекту VA

15.07.2019    6006    0    fenixnow    43    

Разработка и сценарное тестирование с Vanessa-ADD. Отчетность Allure. Автоматизация запуска сценариев

Практика программирования Vanessa Automation v8 Россия Бесплатно (free)

Формируем отчетность о результатах выполнения сценариев. Автоматизируем запуск.

26.02.2019    19867    0    Vladimir Litvinenko    27    

Разработка и сценарное тестирование с Vanessa-ADD. Установка инструментов. Запись действий пользователя и выполнение сценариев

Практика программирования Vanessa Automation Бесплатно (free)

Вторая часть цикла публикаций, посвященных Vanessa-ADD и автоматизации тестирования.

21.01.2019    30118    0    Vladimir Litvinenko    96    

[Заметки] Scrum за 5 минут

Agile (XP, SCRUM, Канбан) Бесплатно (free)

Первый опыт создания статьи в сообществе. Немного о Scrum и нашем знакомстве.

20.11.2018    8078    0    leobrn    11    

BDD в 1С

Математика и алгоритмы Vanessa Automation Бесплатно (free)

Я расскажу вам про магию BDD. Сначала будет немного теории, а потом я покажу, как это применимо к 1С на практике. BDD расшифровывается как Behavior Driven Development, разработка через поведение системы. Это означает, что мы выстраиваем весь наш процесс разработки, исходя из ожидаемого поведения.

30.08.2016    27977    0    Pr-Mex    19    

Опыт практического применения методики BDD на 1С. Написание сценариев

Математика и алгоритмы Практика программирования Vanessa Automation v8 Бесплатно (free)

Эта статья открывает цикл публикаций, в которых я хочу поделиться опытом использования методики BDD при разработке на 1С. В этой статье речь пойдёт о написании сценариев.

03.07.2016    22895    0    oleynik.dv    131