0. Mistress_A 64 26.12.19 11:54 Сейчас в теме

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

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

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. oleynik.dv 143 26.12.19 12:34 Сейчас в теме
Закрываем гештальты трёхлетней давности: https://infostart.ru/public/534673/
Как говорится: север помнит! (с)
1ceo_2015; +1 Ответить
2. Vladimir Litvinenko 2231 26.12.19 15:29 Сейчас в теме
Отличная статья! Спасибо.

BDD - это не о программистах, это бизнес-анализ

Не тащите одеяло на себя! )) BDD - это о разработке в целом. Каждый участник может сказать "BDD - это о тестировщиках, у нас есть основа для детальных сценарных тестов", "ВDD - это о программировании, вместо заунывного технического задания сразу есть критерии приемки", "ВDD - это о бизнес-анализе, в историях мы выражаем потребности пользователей".

Заказчик при этом скажет "BDD - это не для меня, в нем не выражены связи моих бизнес процессов и какой-то птичий язык применяется, я не буду это читать" )) Шутка )) Почти. Просто BDD мало, нужно еще документацией дополнять, если заказчик сам не из технарей.

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

Шаги проведения документов я сначала записывала "кнопконажималкой", но потом узнала, что в библиотеке есть волшебный шаг " И Я открываю навигационную ссылку 'e1cib/data/Документ.ЗаказКлиента?ref=bacaba6e71f047c911e9610fc4adcbf5' " - и моя жизнь наладилась.


Хм. Открытие навигационной ссылки e1cib/list/Документ.ЗаказКлиента я понимаю. А откуда берутся GUID-ы конкретных документов? У Вас используется какая-то заранее заготовленная база, где GUID-ы известны?

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

Действительно интересно, потому что идентификация тестовых объектов, созданных на этапе подготовки базы часто является нетривиальной задачей в Vanessa-Automation/Vanessa-ADD.
1ceo_2015; +1 Ответить
6. Mistress_A 64 26.12.19 16:01 Сейчас в теме
(2) Владимир, спасибо за вопрос )
В разделе "Написание сценариев с шагами первого уровня" в 3-ем абзаце написано, как у нас организована база для тестирования. Соответственно макеты готовятся в копии эталонной базы. И да, GUID берётся из этого макета.
Переход по навигационной ссылке мне нужен только для допроведения документов загруженных из макетов. Остальные действия я стараюсь привязывать к данным в примерах.

Если не очень понятно ответила - напишите кейс, как может проявиться хрупкость этой конструкции. Я попробую применить его к тому, как я это делаю.
8. Vladimir Litvinenko 2231 26.12.19 16:15 Сейчас в теме
(6) Понятно, спасибо. Я просто когда-то пробовал такой подход с эталонной базой. Показалось, что это повышает хрупкость сценариев и их зависимость от данных. Всё равно, что в код платформы 1С вставлять НайтиПоНаименованию() и на этом строить прикладную логику конфигурации.

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

Но может быть это я руку не набил на таком подходе к наполнению тестовой базы.

Альтернативой пока вижу только шаги вида "Я выполняю код встроенного языка" и "Я запоминаю значение выражения 'ВыражениеВстроенногоЯзыка' в переменную 'ИмяПеременной'" на этапе инициализации сценария (в разделе контекста). Это конечно требует небольших навыков программирования.
o.nikolaev; +1 Ответить
10. oleynik.dv 143 26.12.19 16:51 Сейчас в теме
(8) это же зависимость от входящих данных, которые мы же и загружаем. так что не очень страшно. если таким же образом привязываться к данным, которые создаются по ходу выполнения сценария - ну это да, самоубийство )
Макеты каждый раз новые не делаем. Если надо поменять - то загружаем макет в пустую эталонную, меняем как надо и снова выгружаем, таким образом GUID не меняется.
mxl хотим заменить на json для нормального версионирования и работы как с текстом, но пока руки не доходят.
19. 1ceo_2015 26.12.19 21:51 Сейчас в теме
(2)
Заказчик при этом скажет "BDD - это не для меня, в нем не выражены связи моих бизнес процессов и какой-то птичий язык применяется, я не буду это читать" )) Шутка )) Почти. Просто BDD мало, нужно еще документацией дополнять, если заказчик сам не из технарей.


Это не шутка , а горькая правда) Именно поэтому статья про BDDSM (BDD+StoryMapping). Работу с потоками ценностей заказчику удобнее воспринимать и для него это не так мелко и непонятно как большие простыни тестов и инструкций. При этом можно обеспечить трассировку требований от укрупненного процесса до конкретного сценария и не свалиться в рисование сложных и трудно поддерживаемых бизнес-процессов с кучей ветвлений. Такое они (заказчики) тоже с трудом воспринимают.
Vladimir Litvinenko; +1 Ответить
3. Dach 294 26.12.19 15:37 Сейчас в теме
Теги normal и critical, а также тег с номером "истории" - это чисто для себя? Или va/v-add умеет как-то с ними работать?
4. Mistress_A 64 26.12.19 15:44 Сейчас в теме
(3) вот здесь же скриншот с настройками в VBParams, чтобы так заработало в allure. Это для VA. В v-add не уверена. Надо у @pumbaE спросить.
5. Dach 294 26.12.19 15:54 Сейчас в теме
(4) понял, спасибо

Такой вопрос еще. У вас в компании приняты какие-то условные стандарты написания шагов низкого уровня? То есть тех шагов, которые "сидят" внутри группировочных. С целью, чтобы библиотека готовых шагов копилась и множилась. Я насколько знаю, обе ванессы сопоставлют шаг с обработчиком по наименованию, то есть по "подобно" или like. Если приняты, поделитесь, плз
7. oleynik.dv 143 26.12.19 16:10 Сейчас в теме
(5) давайте про стандарты я отвечу. Смотрите на втором уровне мы максимально стараемся использовать шаги из стандартной UI библиотеки VA. Если их по какой-то причине не хватает, то мы делаем issue на github (если есть какой-то обходной манёвр), если надо срочно - то пишем сами в локальную для репозитория проекта фичу "Библиотека.feature".
Это не идеальное решение. Конечно, надо сделать отдельный репозиторий для наших внутренних шагов и подключать это в виде сабмодулей. Но пока так не делаем (
9. Dach 294 26.12.19 16:28 Сейчас в теме
(7) к примеру, есть детальный шаг "И я добавляю в заказ покупателя <номер> от <дата> товар с кодом <код товара>"

я точно знаю, что такой шаг буду еще 100500 раз использовать в других тестах.

Вы копите как-то именно такие шаги? И есть ли у вас какие-то семантические правила написания таких шагов? Чтобы звучало именно "я добавляю в заказ", а не например "я подбираю" или "я создаю новую строку" и тд

Вот о чем мой вопрос, а не о процессе расширения UI библиотеки. Мы просто только начинаем применять BDD и очень хочется постигнуть "бест практикс", так сказать
Vladimir Litvinenko; +1 Ответить
11. oleynik.dv 143 26.12.19 17:00 Сейчас в теме
(9) вопрос понял. это тогда про первый уровень шагов. такого стандарта нет. всё на уровне здравого смысла и высокого уровня абстракции от конкретной реализации. переиспользование шагов первого уровня сейчас происходит максимум в одном feature-файле.
но у нас и нет такой задачи в прямом виде. для меня задача - чтобы бизнес-аналитик мог писать и автоматизировать сценарии не прибегая к услугам программиста. если он при этом надублирует похожие шаги первого уровня - это не так страшно. отрефакторить такое можно и потом. Если шаги человекочитаемы и могут обсуждаться совместно с бизнес-заказчиком - значит всё Ок.
12. Dach 294 26.12.19 17:05 Сейчас в теме
(11)
переиспользование шагов первого уровня сейчас происходит максимум в одном feature-файле


Хочется добиться максимального переиспользования именно в рамках всех тестов, особенно вновь создаваемых в будущем
13. Vladimir Litvinenko 2231 26.12.19 17:19 Сейчас в теме
(12) Имеет ли это смысл на этапе сбора требований от заказчика и согласования сценария с ним?

Ведь на этом этапе нужен максимально человеческий язык. А затем, уже на этапе формализации можно привести сценарий к унифицированному виду. Это всё равно придется делать. Например если у нас есть шаг создания вида номенклатуры, выраженный в виде экспортного сценария :

#language: ru

@ExportScenarios

Функционал: Создание вида номенклатуры

Как Разработчик сценарных тестов
Я хочу иметь универсальный сценарий создания видов номенклатуры
Чтобы уменьшить дублирование кода в прочих сценариях

# Возможные значения параметра Тип - "Товар", "Услуга", "Работа", "Набор", "Тара"
# Возможные значения параметра Ставка - "20%", "10%", "0%", "Без НДС"
# Возможные значения параметра ИстинаИлиЛожь - "Истина", "Ложь"

Сценарий: Я создаю вид номенклатуры с наименованием "Наименование вида" типом "Тип вида" единицей "Ед" и ставкой НДС "Ставка", учет по характеристикам "ИстинаИлиЛожь"

	И В командном интерфейсе я выбираю 'НСИ и администрирование' 'Классификаторы номенклатуры'
	Тогда открылось окно 'Классификаторы номенклатуры'
	И я нажимаю на кнопку 'Виды номенклатуры'
	Тогда открылось окно 'Виды номенклатуры'
	И я нажимаю на кнопку с именем 'Создать'
	Тогда открылось окно 'Вид номенклатуры (создание)'
	И у поля "Тип номенклатуры" я нажимаю гиперссылку 'указать'
	Тогда открылось окно 'Выберите тип номенклатуры'
	И я меняю значение переключателя 'ТипНоменклатурыТовар' на "Тип вида"	
	И я нажимаю на кнопку 'ОК'
	Тогда открылось окно 'Вид номенклатуры (создание) *'
	И в поле 'Наименование' я ввожу текст "Наименование вида"
	Если 'ИстинаИлиЛожь' тогда
		И я устанавливаю флаг 'Характеристики:'		
		И из выпадающего списка "Характеристики" я выбираю точное значение 'Общие для этого вида номенклатуры'
	И я перехожу к закладке "Значения по умолчанию"	
	И из выпадающего списка "Ставка НДС" я выбираю точное значение "Ставка"
	И в поле с именем "ЕдиницаИзмерения" я ввожу текст "Ед"
	И я нажимаю на кнопку 'Записать и закрыть'
	И я жду закрытия окна 'Вид номенклатуры (создание) *' в течение 20 секунд
Показать

то на этапе формализации в любом случае нужно будет шаг создания вида номенклатуры привести к виду:

Я создаю вид номенклатуры с наименованием "Наши товары" типом "Товар" единицей "шт" и ставкой НДС "10%", учет по характеристикам "Истина"


А на этапе сбора требований и первоначального обсуждения можно как угодно сформулировать этот шаг. Главное чтобы участникам обсуждения это было понятно. Среди участников при этом могут быть люди далекие от разработки. Им же не обязательно знать, какие шаги есть в наших библиотеках ))
dyuha; 1ceo_2015; oleynik.dv; +3 Ответить
17. Dach 294 26.12.19 19:18 Сейчас в теме
(13), (14)

У нас сейчас примерно такая ситуация: есть единственный готовый основной продукт, работающий не особо хорошо. Разработка ведется из рук вон плохо. Смежный функционал часто ломается. Сборочную линию внедрили, теперь надо написать кучу регрессионных тестов, чтобы весь важный функционал покрыть и улучшить качество релизов. Вот начинаю думать, как бы формализовать требования к написанию фич, чтобы и другие разработчики команды могли максимально быстро и эффективно научиться и библиотека шагов не превратилась в кашу
18. Vladimir Litvinenko 2231 26.12.19 19:54 Сейчас в теме
(17) Сложно давать советы в этом случае. Я пока вообще не встречал ситуации, когда коллеги-разработчики были бы готовы сами писать сценарии и разбираться с методиками и правилами их создания. Обсуждать сценарии - в принципе да. А для написания сценариев разработчиками нужна "руководящая указивка" и явное выделение времени под эти цели. И то вопрос с мотивацией остается. "Не для того наша роза цвела" как говорится ))

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

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

Может быть лучше не "написать кучу регрессионных тестов", а написать их немного, покрыв самые критичные блоки? Но при этом поддерживать эти тесты всегда в актуальном состоянии. Это можно сделать и самостоятельно. Силы разработчиков направить на рефакторинг.

Параллельно начать применять практику код-ревью. Она конечно бьет по самолюбию некоторых программистов, но эффект даёт быстрый. Иногда и самому хочется похалявить и побыстрее написать, а тебе коллега ссылку на стандарт в ответ )) Хороший эффект.

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

А когда система начнет улучшаться, у Вас уже будет практика написания тестов и библиотек. Будет и понимание, как лучше стандартизировать создание сценариев в вашей команде. Понимание, кто вообще готов в этом участвовать и в каком объеме. От этого ведь тоже многое зависит.
20. Dach 294 26.12.19 23:18 Сейчас в теме
(18) давайте заменим слово "сценарные" на слово "функциональные".

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


(18)
нужна "руководящая указивка"


да это понятно, что нужна "железная рука Феликса Эдмундовича". Только хотелось бы в этой руке держать худо-бедную инструкцию... Ну а то, что сценарий может наклепать не только лишь программист, а мало кто вообще аналитик - это нам автор статьи доходчиво расписала, с картинками, блэкджеком и балеринами )))
14. oleynik.dv 143 26.12.19 17:27 Сейчас в теме
(12) ну если у вас со сбором, согласованием, утверждением и изменением требований всё налажено, если вы разобрались со стратегией подготовки первоначальных данных и сборочной линией, если приёмка работ заказчиком у вас происходит в ходе просмотра Allure - тогда конечно можно озадачиться максимальным переиспользованием шагов ;-).
У вас как я понимаю один проект/продукт? Не вот эти вот бесконечные новые внедрения? Если так - то да, можно заняться перфекционизмом и "наконец-то сделать всё по-нормальному".
В условиях нашей потогонки это сложнее. Тут задача перетащить технологические достижения предыдущего проекта на новый, потому что риск просесть типа "шаг вперёд два назад" он очень реальный. Но зато и ретроспектив больше. ненужное отсеивается.
15. Pr-Mex 124 26.12.19 18:29 Сейчас в теме
Привет Господину )))
1ceo_2015; +1 Ответить
16. oleynik.dv 143 26.12.19 18:59 Сейчас в теме
(15) и вам не хворать ;-)
1ceo_2015; +1 Ответить
21. acanta 73 27.12.19 01:10 Сейчас в теме
Это новый конфигуратор 1с9? Впечатляет.
22. 1ceo_2015 27.12.19 01:16 Сейчас в теме
23. sapervodichka 3032 28.12.19 15:51 Сейчас в теме
На аватарке девушка с хлыстом + статья про BDDSM = Не получается сосредоточиться на чтении!
Прикрепленные файлы:
wowik; klaus38; TreeDogNight; gaglo; 1ceo_2015; acanta; +6 Ответить
24. gaglo 01.01.20 09:25 Сейчас в теме
(23) Сегодня 01.01.2020. Читаю.
(23)
Не получается сосредоточиться на чтении!

ДА, не получается. Но не девушка с хлыстом тому виной!! (Она даже помогает...)
Мешают ихние непонятные термины:
"Gherkin" - демон какой-то, его так часто призывают в тексте (а вдруг он явится?)
"Я создаю US-feature в StoryMapper" - я догадывался, что это выдумали в US, да как хитрО...
"Usage Flow" - это не то же, что "User Failure"??
"статус "Отгружено" - нотутже! "статус Delivered" - no comments
Но нет! Ставлю плюс, "В избранное", перечитаю, когда голова моя протре станет способной адекватно воспринимать альтернативные реальности, это ДОЛЖНО мне пригодиться...
ЗЫ Автору - браво!
25. oleynik.dv 143 13.01.20 11:47 Сейчас в теме
Коллеги, если у вас после прочтения статьи появились вопросы, требующие расширенного обсуждения - приходите к нам в телеграм-канал @BDDSM. Покажем, расскажем, дадим демо-доступ.
1ceo_2015; +1 Ответить
26. PLAstic 247 14.02.20 14:01 Сейчас в теме
Статья вроде бы изобилует такими "правильными" терминами, и тут вдруг "функционал"...
27. ILM 238 16.02.20 13:16 Сейчас в теме
Ужас, что только люди не придумают, чтобы ТЗ не писать. Автоматом формируем требования, правила, свойства, формы, код, а потом куда? В BDDSM? Тьфу-тьфу-тьфу...

Мы работаем для клиента и его результата, или для автоматизации собственной деятельности. Результатом второго, мы видим в ЕРП, когда "левая нога" может почесаться 30ю способами.
28. Terve!R 21.02.20 09:38 Сейчас в теме
Кажется, я ничего не понял, но влюбился :)
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист 1С
Москва
зарплата от 100 000 руб. до 150 000 руб.
Полный день

Автор новостных обзоров на тему 1С и бухучета
Санкт-Петербург
По совместительству

Специалист внедрения и сопровождения 1С
Москва
зарплата от 80 000 руб.
Полный день

Product Owner (Менеджер по продукту 1С)
Москва
зарплата от 100 000 руб. до 170 000 руб.
Полный день

Тим лид по разработке 1С (Team Lead 1С)
Москва
зарплата от 100 000 руб. до 200 000 руб.
Полный день