0. Vladimir Litvinenko 1755 21.01.19 00:52 Сейчас в теме

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

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

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

Комментарии
Избранное Подписка Сортировка: Древо
1. Vladimir Litvinenko 1755 21.01.19 00:54 Сейчас в теме
За время, прошедшее с первой публикации, появилось ещё одно новое видео по рассматриваемой теме на канале "ФТО-Проект". Рекомендую посмотреть :

https://www.youtube.com/watch?v=2Ulzs81ExB4
Tavalik; artbear; +2 Ответить
10. Pr-Mex 123 21.01.19 14:50 Сейчас в теме
(1)
Порадовала концовка видео )
Я думаю, Серебряной пуле лучше начать с запуска CI контура для самого ADD, а уже потом переходить к покрытию тестами ЗУП.
17. Vladimir Litvinenko 1755 21.01.19 15:33 Сейчас в теме
(10) Хотелось бы избежать горячих обсуждений "у кого лучше" ) Всё таки тема посвящена вопросам установки и интерфейсу. А ссылкой на доклад просто захотелось поделиться как на новое видео по рассматриваемой теме.

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

На канале ФТО есть еще несколько отличных видео с этой встречи. В том числе выступление Петра Грибанова по новым механизмам платформы 1С.
Tavalik; artbear; +2 Ответить
2. Meteorage 17 21.01.19 06:13 Сейчас в теме
Шикарная статья. Выражаю особую благодарность за подробное описание. У меня сейчас как раз проект в котором я хочу внедрить данные технологии.
artbear; Vladimir Litvinenko; ovcharenko.di; +3 Ответить
3. artbear 1149 21.01.19 12:34 Сейчас в теме
(0) Огромное спасибо за две обалденные и очень полные статьи :)
Tavalik; Vladimir Litvinenko; +2 Ответить
4. Pr-Mex 123 21.01.19 12:56 Сейчас в теме
(0)
Спасибо за статью.
Единственное что не очень - это гифки. В них нет паузы и перемотки. Не всегда удобно смотреть.
kuzyara; tormozit; +2 Ответить
9. oleynik.dv 121 21.01.19 14:35 Сейчас в теме
(4) Позвольте с вами не согласиться, уважаемый коллега! ;-)
Размер имеет значение. Хорошая гифка на 3-5 сек в тексте намного нагляднее статичной картинки. Тут важно чувство меры.

Вопрос к Владимиру: каким инструментом гифки делаете? (интересуюсь с целью перенять опыт)
for_sale; kuzyara; freddy121; 1ceo_2015; +4 Ответить
11. Vladimir Litvinenko 1755 21.01.19 14:57 Сейчас в теме
(9) Gif-анимацию записываю через LICEcap. Он умеет делать паузу (только во время записи), но я этим не пользуюсь, так как иначе время необходимое для удачной записи сильно увеличится.

Также неудобно, что он не отображает факт клика мышью. Знаю, что есть инструменты, позволяющие это делать - отображать клик отдельной анимацией. Но руки не дошли до их изучения. LICEcap просто уже давно использую и привык.
for_sale; oleynik.dv; 1ceo_2015; +3 Ответить
12. Vladimir Litvinenko 1755 21.01.19 15:01 Сейчас в теме
(4) Согласен, для такого материала гораздо лучше подходит видео с озвучкой. Без озвучки совсем не то, и накладные расходы на запуск виде больше чем польза от них. Но для записи качественных видеоуроков необходимы особые условия - тишина долгое время, микрофон, заливка.... пока не имею такой возможности и думаю что повторять потом этот материал в формате видео уже будет мало смысла.
13. Pr-Mex 123 21.01.19 15:02 Сейчас в теме
(12)
Именно. Поэтому я планирую в ближайшем времени переход на автовидео инструкции.
15. Vladimir Litvinenko 1755 21.01.19 15:10 Сейчас в теме
(13) Они же перестали работать в последних версиях платформы. С 8.3.12 точно, а кажется даже с 8.3.9. Разве нет?
Мы пытались их применять в компании. Выделение активного элемента больше не работало. Удалось частично починить - коллега вносил изменения в механизм. Но кнопки командной панели так и не получилось заставить выделяться. Смотрели как в ADD, так и в Automation.
16. Pr-Mex 123 21.01.19 15:23 Сейчас в теме
(15)
Сама запись автовидео как работала так и работает.
Начиная с 8.3.12 нельзя определить координаты элемента на экране через win api, поэтому нельзя подсветить активный элемент на экране и подвести к элементу курсор мышки. Но эти проблемы я решаю в новых автовидео.
Vladimir Litvinenko; +1 Ответить
18. Vladimir Litvinenko 1755 21.01.19 15:40 Сейчас в теме
(16) Спасибо! Будет хорошо, если получится.
22. Pr-Mex 123 21.01.19 16:40 Сейчас в теме
(15)
Удалось частично починить - коллега вносил изменения в механизм

Можно поподробнее про эти изменения?
23. Vladimir Litvinenko 1755 21.01.19 16:45 Сейчас в теме
(22) Извиняюсь, я дезинформировал )) Сейчас узнал - "починка" заключалась в применении старой версии платформы 8.3.6 для записи видеоинструкций для нашей конфигурации )) Была попытка попробовать изменить код на Паскале, но получилось запустить конфигурацию на старой версии платформы.
24. Pr-Mex 123 21.01.19 17:12 Сейчас в теме
5. artbear 1149 21.01.19 14:09 Сейчас в теме
Для отладки экспортного метода необходимо до первого исполнения шага открыть реализующую его внешнюю обработку в режиме 1С:Предприятия, обязательно в том сеансе тест-менеджера, в котором открыта Vanessa-ADD. Затем открыть эту обработку в конфигураторе, найти нужный метод в форме обработки и поставить в нем точку останова. Затем можно выполнять сценарий - точка останова сработает.


(0) подобное подключение отладки устарело и нужно редко.

я еще в версии 5.1.0 Vanessa.ADD (т.е. довольно давненько) сделал более удобный механизм отладки - абсолютно штатная 1С-отладка шагов/тестов, если файл с клиента доступен на сервере.

При следующих условиях
- шаги отлаживаются в файловой базе - самый простой и полезный кейс
- клиент и сервер 1С - это одна машина
- файлы обработок находятся в сетевой папке, доступной и на клиенте, и на сервере 1С

Теперь не нужно мучаться с отладкой шагов, как раньше :)
Vladimir Litvinenko; +1 Ответить
14. Vladimir Litvinenko 1755 21.01.19 15:06 Сейчас в теме
(5) Хм, а может быть я именно эту возможность за нововведения в платформе 8.3.14 принял? ))
Заметил, что обработки, реализующие шаги по прежнему нужно открывать для их успешной отладки, но только если подключение отладчика произошло уже потом, после запуска тест-менеджера. Если же тест-менеджер запускается из конфигуратора, то в этом не было необходимости.
6. artbear 1149 21.01.19 14:14 Сейчас в теме
В этом разделе рассмотрим функционал вкладки "Запуск сценариев" за исключением группы команд "Внешние инструменты". В этой группе ценность на мой взгляд имеет только команда отображения отчета Allure в браузере

(0) Еще команда "Генератор макетов данных" очень полезна

А в новой версии еще одна полезная команда появляется - "Управление дымовыми тестами"
1ceo_2015; +1 Ответить
7. Shmell 256 21.01.19 14:24 Сейчас в теме
Спасибо! все объединили в одном месте. Добавил в избранное.
8. oleynik.dv 121 21.01.19 14:25 Сейчас в теме
Отличный мануал! У самого бы руки никогда не дошли.
А тут прям в таком виде можно давать новым сотрудникам. Круто.
freddy121; +1 Ответить
19. artbear 1149 21.01.19 16:10 Сейчас в теме
Проблема в том, что это происходит иногда , то есть работа далеко не такая стабильная как хотелось бы :


(0) Могу помочь разобраться, что не так с подстановкой шагов фич через gherkin.autocomplete в VSC

Здесь или на форуме https://xdd.silverbulleters.org/c/razrabotka/vanessa-add
21. Vladimir Litvinenko 1755 21.01.19 16:27 Сейчас в теме
(19) Продублирую описание установки и описанный здесь эффект на форум, как только появится время.
Возможно проблема в том, что на машинах, где редактирую сценарии, установлена Windows 7. Как на домашнем, так и на рабочем компьютере. Где-то читал, что с Windows 7 проблемы возникают с этим плагином. На CI-сервере где Windows Server 2016 плагин не ставил. Посмотрю поведение на нём чуть позже, может быть такой эффект наблюдаться не будет.
20. artbear 1149 21.01.19 16:12 Сейчас в теме
Кстати, всем напомню, что поддержка по продукту Vanessa.ADD оказывается

1 на нашем форуме https://xdd.silverbulleters.org/c/razrabotka/vanessa-add
- (предпочтительно, т.к. история сохраняется и в разных ветках есть разные контексты)

2 и в чате-телеграме Серебряной Пули https://t.me/silvernation

3 или в чатах статей про Vanessa.ADD на ИС, таких, как эта статья.
25. tsukanov 57 21.01.19 19:02 Сейчас в теме
(20) Написав вопросы на форуме 12 дней назад так и не дождался ни одного комментария )
Поддержка платная или я что-то не то / не так спросил?
new_user; +1 Ответить
26. tsukanov 57 21.01.19 20:16 Сейчас в теме
Владимир, спасибо за статью. Но есть ряд вопросов.
Я уже давно хочу задать эти вопросы и все никак не решаюсь (чтоб никого не обидеть).
Но думаю таки стоит спросить:
Видел несколько статей, видел вебинары кусками (выделить время на полный анализ сложно). И каждый раз это большой объем информации с крайне низким КПД (по личным ощущениям).
Например, то что описано в данной статье (просмотрел по диагонали), по большей части проблемы не представляет. Почти все выясняется методом научного и не совсем тыка. Причем довольно быстро (по крайней мере мы в основной механике разобрались за день без погружения во все эти публикации). Мне кажется программисту внутренняя кухня должна быть очевидна.
Но когда ты разобрался в механике, возникает куча вопросов совершенно другого плана.
Как тестировать то? Я вижу как в вебинарах и видео говорится что нужно писать высокоуровневые шаги, а затем программист их реализует.
Но когда я вижу статьи и скриншоты с типа реальными примерами, то возникает когнитивный диссонанс, т.к. там кликеры, а совсем не то, что вроде как должно быть. Так а где примеры не кликеров? Я что-то пропустил? есть ссылки?
Дело в том, что видится два варианта использования и оба с проблемами:
1. Высокоуровневые шаги (тру) - проблема в переиспользовании.
Как это делать?
Я знаю как это делать в Тестере, например. Там переиспользование получается само собой с порога, т.к. там полноценный язык программирования. Сделал общий сценарий создания документа (реализации, например), который принимает структуру данных документа и погнал. Кликер для реализации будет сделан один раз в одном месте. Но как этого добиться с Ванессой? Если попытаться сделать то же самое, что в Тестере, то получится дикий изврат, т.к. в Ванессе нет структур данных. Да и концепция читаемости будет вырублена на корню.
Как быть то?
2. Низкоуровневые шаги (кликер) - проблема в декомпозиции.
Получаются длинные портянки, читаемость которых по ощущениям еще ниже чем у кода 1С. Мне (программисту) их читать субъективно сложнее. Типа возник у тебя вопрос: "Какая сумма вводится туда-то в том-то документе?" и начинаешь судорожно искать глазами нужную строчку в этом мусоре.
В общем длинные портянки очевидно нужно разбивать на какие-то части. Но как? Экспорт сценариев?
Человек не связанный с программированием таким скилом (декомпозиция) тупо не обладает.
И даже для программиста возникают вопросы. Например, есть 10 сценариев, которые используют общие данные, которые хотелось бы создавать кликами как юзер. Как сделать так, чтобы запустив 10 сценариев, данные были созданы только один раз?
Делать и передавать между сценариями уникальный ключ данных как в Тестере? Но это опять же повышает требования к человеку пишущему сценарии.

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

Куча вопросов, которые тянут на отдельную статью, и минимум времени, которое жалко тратить даже на такой плохой коммент.

ps Пардон за сумбур и ужасный текст. Надеюсь мысль донес
Enot; JohnyDeath; 1ceo_2015; grumagargler; Vladimir Litvinenko; goshasilver; +6 Ответить
28. goshasilver 21.01.19 23:10 Сейчас в теме
(26) вот прям написали, что болело, мало опыта боялись спрашивать. Тоже с тестером работаем, там чтоли все больше для дела реализовано и мануал в одном месте а не нужно собирать по крупицам
tsukanov; +1 Ответить
29. Vladimir Litvinenko 1755 22.01.19 00:49 Сейчас в теме
(26)
Видел несколько статей, видел вебинары кусками (выделить время на полный анализ сложно). И каждый раз это большой объем информации с крайне низким КПД (по личным ощущениям).

Да, такая проблема есть, писал про неё еще во введении к первой части https://infostart.ru/public/969637. Именно это и сподвигло к выпуску публикаций. Но здесь Вы должны понимать, что эти продукты создаются на энтузиазме разработчиков. И среди 1С-ников очень мало людей, готовых помочь в разработке. Мало даже людей, которые вообще способны участвовать в совместной разработке на github по незнакомым правилам игры. Мы же дети типовых конфигураций и хранилища в формате .1CD. Чтобы задействовать git на проектах приходится уговаривать коллег "ребята это не страшно, оно не кусается". И всё равно то и дело встречаешь страх английских слов "Blame" и "Review" и нежелание совместно работать над кодом. Разработчики из других языков ржут... громко ))

На мой взгляд фирме 1С стала невыгодна такая ситуация с замкнутостью легко заменяемых разработчиков 1С на хранилище и конфигураторе по одной причине - захотелось на западный рынок. Поэтому сейчас всё на git будут переводить и на EDT. Надо изучать. Но не поздновато ли? ))


И вот в этих условиях рождаются и развиваются такие мощные проекты на github. Требовать от разработчиков при этом еще и бесплатных курсов и всеобъемлющей документации несправедливо. А вот мы со своей стороны можем помочь информационно и сделать эту самую документацию. Или хотя бы что-то похожее на неё.

Сейчас помимо этих публикаций хорошими источником информации по практическому применению является встроенная в bddRunner.epf справочная информация. Альтернатива - собирать по кусочкам из вебинаров, форумов и чатов - за неделю можно многому научиться. Помню кто-то из разработчиков написал, что сейчас вообще наблюдается тенденция к ЧДД - "чат driven documentation" ))

Ранее ещё был курс https://infostart.ru/special/bdd. Но он был изрядно устаревшим еще тогда когда его проходил - в 2017 году и сейчас требует переработки. Если откровенно, то у меня самого после него не получилось начать работать с инструментом. Слишком много дыр в голове осталось, много времени было уделено bdd-editor, который теперь в статусе depricated. Visual Studio Code тогда еще не применялся. Больше помог второй курс https://infostart.ru/public/597500, где речь про Vanessa-Beravior не ведётся, но в нём рассказано про построение CI-контура и даже с основами применения Докера познакомиться можно. Впоследствии собрал CI-контур по другому, но курс задал вектор, чтобы дальше развиваться, понимая где и какую искать информацию. Рекомендую.


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

Хм, мне бы Ваш оптимизм в своё время. Может быть отличаюсь тугодумством, но у меня получилось разобраться не сразу, даже поняв где искать информацию.

Если же Вам всё здесь написанное кажется очевидным, то подождите следующей публикации. Там будут практические примеры. Было бы неправильно перейти к практическим примерам не написав про установку инструментов и не сделав обзор интерфейса. Это бы поставило интересующихся темой в то же самое положение "вот волшебная шляпа, вот волшебная палочка, я ей взмахиваю и достаю из шляпы кролика". Уверен, что вам знакомо это чувство )) В общем информация по установке на мой взгляд необходима.



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

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

Подозреваю, что такой же синдром есть у абаперов на SAP и прочих сильно зависящих от одного вендора и одного набора инструментов разработчиков. "Я же 1С-ник/Сапёр, зачем мне всё это! Уберите от меня эти страшные штуки! Я итак деньги заработаю!". И ведь зарабатывают )) Часто пользователи очень не скоро могут понять, что им в систему болячку подсунули и она систему разрушает до тех пор, пока другие "врачи в жёлтых халатах" уже не могут справиться ))

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

Задумка была такая. Первая часть - концепция, знакомство с инструментом, чтобы читатели не путали BDD с покрытие тестами для автоматизации регресса. Там же простой пример сценарного теста. Затем установка инструментов и обзор интерфейса. Дальше примеры на типовой конфигурации думаю показать. С такими же неудобными gif-ками, как здесь )) Но думаю желающие смогут разобраться.

1. Высокоуровневые шаги (тру) - проблема в переиспользовании.
Как это делать?


Высокоуровневые шаги для Vanessa - это аналог обычных шагов в сценариях, написанных для других платформ типа Java. Просто у них шаги реализуются непосредственно кодом. А у нас есть Ванесса, которая позволяет "высокоуровневые" = "настоящие" шаги реализовать через автоматически записанные библиотечные шаги. И так как это тоже получается текст на языке Gherkin, то мы имеем возможность разместить их в том же самом сценарии.

Если же Вы пишете свои собственные реализации шагов (через свои внешние обработки), то может оказаться так, что Ваш шаг вообще не нуждается в разбиении на более мелкие шаги, а является самодостаточным и переиспользуемым. Например можно создать шаг
"Я перепровожу последовательность документов за текущий месяц".
Затем реализовать этот шаг в экспортном методе обработки, точно также как делал бы коллега-программист на Java. После чего этот шаг можно переиспользовать сколько душе угодно.

Другим вариантом переиспользвоания являются экспортные сценарии.

Ни про собственные шаги ни про экспортные сценарии в следующей публикации информации не будет. Я просто не успею про это написать, да и с рядом вопросов ещё самому разобраться надо.

Низкоуровневые шаги (кликер) - проблема в декомпозиции.
Получаются длинные портянки, читаемость которых по ощущениям еще ниже чем у кода 1С. Мне (программисту) их читать субъективно сложнее. Типа возник у тебя вопрос: "Какая сумма вводится туда-то в том-то документе?" и начинаешь судорожно искать глазами нужную строчку в этом мусоре. В общем длинные портянки очевидно нужно разбивать на какие-то части. Но как? Экспорт сценариев?

И снова с Вами согласен. Поэтому даже если разработка идет не по BDD, то начинать лучше с описания логики - нормальных человекочитаемых шагов. А затем уже включать автоматическую "кнопконажималку".

Ну ок. Допустим даже кому-то это делать лень. Но после того как сценарий автоматически записан его обязательно нужно разбить на логические группы шагов. Это же как разбивать код на процедуры и функции. В 1С модно делать методы на 3000 строк. Но это же ненормально )) Сценарии тоже нужно правильно оформлять. Иначе в сценариях бардак будет. Но глядя на имеющиеся примеры мне кажется, что человеческая лень всё же часто побеждает ))

Постараюсь привести примеры на этот счёт в следующий раз.


Например, есть 10 сценариев, которые используют общие данные, которые хотелось бы создавать кликами как юзер. Как сделать так, чтобы запустив 10 сценариев, данные были созданы только один раз? Делать и передавать между сценариями уникальный ключ данных как в Тестере? Но это опять же повышает требования к человеку пишущему сценарии.


Сценарии в идеале должны быть независимы друг от друга. Но кажется я понимаю о чём речь. Речь о подготовки тестовых данных в целом.

Я это делаю через специальный этап сборочной линии - "Подготовка тестовых данных". Разворачиваю тестовую базу из копии рабочей (да да из копии рабочей, потому что программисты накодили там поиск по наименованию, кое где вшиты GUID и прочий хардкод, алгоритмы зависят от кучи пользовательских данных, просто так маленькую демо базу не сделать). Затем запускаю обработку инициализации - она готовит пользователей, сбрасывает пароли. Затем стартовые сценарии - подготовка тестовых данных.

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


Вот эти вещи где-то освещены?

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


Что вообще может сделать писатель фич без программиста?

Многое. Это ещё зависит от того, кто является писателем. Если писатель - QA-инженер, то может составить тест-кейс. Автоматически записать по нему шаги "кнопконажималкой". Затем декомпозировать их на группы в соответствии с тест-кейсом. Если это аналитик - то его задача бизнес логику прописать.

Но как писал в прошлой публикации, без программиста обойтись нельзя. Либо аналитик/консультант накосячит с проектированием интерфейса, либо QA не сможет сложный шаг запрограммировать. И это отлично! Команда должна работать вместе. Ведь программисту тоже сложно без других специалистов одному работать.

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

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

Работать в тесной связке. Scrum, который мне ближе всего, вообще не разделяет роли QA и программиста. Мы все - разработчики продукта. В 1С такая идилия конечно не всегда возможна. Но в общем это то, к чему я стремлюсь. И чтобы не было профессиональной дискриминации QA, которая в нашей отрасли сильно выражена. QA не кнопкодавы, а члены команды разработки. Есть люди до которых это не доходит.


Кто организует структуру сценариев? Писатель на уровне фич или программист под капотом?
Через год это не превратится в груду мусора (или, как модно говорить, тех. долг)?

Наверное нужно работать также, как с программным кодом при групповой разработке. Можно и в груду мусора превратить. А можно стараться и поддерживать в порядке. Хорошие вещи требуют усилий. Плохие происходят сами по себе ))

Надеюсь мысль донес

Более того, почти со всеми мыслями согласен ))
tsukanov; freddy121; grumagargler; +3 Ответить
33. tsukanov 57 22.01.19 19:16 Сейчас в теме
(29) Спасибо за развернутый комментарий!
Так, в диалоге, многое становится в яснее.

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

Но здесь Вы должны понимать, что эти продукты создаются на энтузиазме разработчиков. И среди 1С-ников очень мало людей, готовых помочь в разработке. Мало даже людей, которые вообще способны участвовать в совместной разработке на github по незнакомым правилам игры.


Да, я это понимаю. Правда не все так просто, как вы описали. Одно дело когда фигачит группа энтузиастов и совсем другое дело когда речь идет о продукте конкретной конторы ) Мы ведь не дети, да? Все прекрасно понимают, что, к примеру, Microsoft пилит бесплатный открытый VSC совсем не по доброте душевной )
Дальше не буду углубляться. Думаю вопрос совместной разработки можно закрыть не открывая. И больше вообще об этом не заикаться. Каждый сам выбирает с каким логотипом на груди ходить (тут отсылка к будущему по Гибсону)

Мы же дети типовых конфигураций и хранилища в формате .1CD. Чтобы задействовать git на проектах приходится уговаривать коллег "ребята это не страшно, оно не кусается". И всё равно то и дело встречаешь страх английских слов "Blame" и "Review" и нежелание совместно работать над кодом. Разработчики из других языков ржут... громко ))


Знаете, тут не соглашусь. Над разработчиками на других языках тоже можно поржать. У нас в 1С в хранилище уж сколько лет можно допиливать (иногда сильно) вендорский продукт, и при этом силами джуниора делать слияние.
Разработчики из других языков такого в гите не имеют (ну или я чего-то не знаю). Blame не так уж и нужен на практике. Ну разве что тимлиду чтобы унижать джунов. В хорошей команде всем должно быть по барабану кто писал код, имхо. А для понимания истории обычного хранилища достаточно. Review - это нужная штука, да. Вот только с чего вы взяли что у разрабов на других языках с этим все норм? Я видел реально годное ревью только у команды Go. И при этом они используют инструмент, который сами же и написали ЕМНИП. Температура в целом по больнице мне не известна, но всегда казалось что это общая боль (вменяемый инструмент трудно найти)

У меня для любой идеи/технологии/задумки в голове всплывает стандартный вопрос: "Какую проблему это решает?"
И какую проблему решает git? Мне она не очевидна.
Вы только не подумайте что я консерватор. Сам внедрял в своей конторе SVN с разбором обработок и затем Git тогда, когда всей этой модной движухи еще не было (12/13 год). Но делалось это для решения конкретной проблемы в моей конторе - хаос с внешними обработками (типичная проблема для фикси). Т.е. я достаточно давно "в теме", но ваши взгляды не разделяю )

ps Продолжение следует... )
pps Да, тут не по теме исходных моих вопросов. Просто возник интерес и другие темы затронуть
34. Vladimir Litvinenko 1755 22.01.19 19:51 Сейчас в теме
(33)
Могу порекомендовать хорошие инструменты Crucible+Fisheye , сейчас на Github есть файлы настроек для подсветки синтаксиса языка 1С для Crucible.

Когда-то использовал в связке с Bitbucket и настраивал только выгрузку хранилища в Bitbuket для связи с задачами в Jira и ревью в Crucible. Но в начале осени настраивал все эти продукты самостоятельно и выяснил, что для посткоммитного ревью (когда в git автоматически отправляются уже помещенные в хранилище изменения) достаточно связки Crucible+Fisheye.

Стоят дорого, но можно использовать триалки.

Здесь есть мой вопрос в сообщество со ссылками на то, что ранее использовал и хотел получить от более простой связки (один из скриншотов не открывается):
https://community.atlassian.com/t5/Jira-questions/Choosing-between-Fisheye-and-Bitbucket-to-integrate-with/qaq-p/887851

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

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

Собственно про преимущества git наверное не буду много писать. Это всё очень просто ищется и в поисковиках и на Инфостарте. Как правило картинок больше, чем советов по настройке. Но я для настройки отдельную публикацию делал : https://infostart.ru/public/903269
35. tsukanov 57 22.01.19 20:29 Сейчас в теме
(34)
Могу порекомендовать хорошие инструменты Crucible+Fisheye , сейчас на Github есть файлы настроек для подсветки синтаксиса языка 1С для Crucible.


Спасибо за наводки )

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


Пользовался Blame начиная с SVN (это не фишка гита). Ничего оно мне на практике так и не дало )
Ну т.е. нафантазировать пользу я могу, но по факту на практике не помню чтоб нужно было.

Когда перелезем на EDT, эта фишка конечно будет приятным бонусом )

Собственно про преимущества git наверное не буду много писать. Это всё очень просто ищется и в поисковиках и на Инфостарте. Как правило картинок больше, чем советов по настройке. Но я для настройки отдельную публикацию делал : https://infostart.ru/public/903269


Спасибо, про публикации и всеобщее увлечение гитом мне известно )
Затронул эту тему только потому что интересен этот социальный феномен.
37. tsukanov 57 23.01.19 20:14 Сейчас в теме
(29)
Да, именно так. Это проблема. Все эти накликивания на мой взгляд работают на одну цель - убедить прикладников, боящихся любых технических практик, в том, что это не страшно. У нас в отрасли сильная неофобия. При этом боятся разработчики 1С даже не нового, а старого. Того, что другие разработчики уже десятилетия стабильно применяют.


Эти накликивания имеют и обратный эффект - разубеждают тех, кто понимает о чем речь. Если статьи одна за другой демонстрируют кликеры... то складывается впечатление, что собсна BDD то никакого и нет. И доверие с каждой демонстрацией начинает падать по экспоненте. Потому что кликеры существуют со времен мамонтов. На ИТС ЕМНИП даже обработка была. А завернуть это в шаги на человечьем языке может любой падаван (на ключевые слова геркина всем вроде пофиг). Но это со времен тех же мамонтов никто не считал хорошей идеей. И сам собой возникает резонный вопрос: В чем собсна соль?
Не воспринимайте это как троллинг или холивор. Я просто честно описал свои ощущения (возможно я один такой).

Если конечная цель - кликер для прикладника, то в общем то все норм. Это можно понять и принять (мерещится что так все и делают в общем то)

У нас в отрасли сильная неофобия. При этом боятся разработчики 1С даже не нового, а старого. Того, что другие разработчики уже десятилетия стабильно применяют.


Вы считаете что неофобия - это плохо? Думается неофобия - это один из самых важных скилов в современном обществе. Потому что "экспертов" и "новаторов" вокруг стало слишком много. И все обещают чудеса. И все это в 99% случаев пузыри.

А про других разработчиков... Вы же знаете историю про "величайшую победу запада в холодной войне"?
Это когда наши решили копировать IBM-360.
У нас (у русских) есть национальная забава - копировать, подражать и воровать.
Так и живем на западных идеях и технологиях.
Это повод гордиться? Да вроде нет.
Мы тупые? Похоже что да. Но это опять же не повод гордиться.
Так почему же разработчики 1С должны наступать на те же грабли, на которые этот народ наступал уже сотни раз?

ps Я не считаю что вы не правы. Я просто пытаюсь показать что все несколько сложнее. Нельзя впадать в крайность - это основной посыл
60. tsukanov 57 26.01.19 20:51 Сейчас в теме
(29)
И снова с Вами согласен. Поэтому даже если разработка идет не по BDD, то начинать лучше с описания логики - нормальных человекочитаемых шагов. А затем уже включать автоматическую "кнопконажималку".

Ну ок. Допустим даже кому-то это делать лень. Но после того как сценарий автоматически записан его обязательно нужно разбить на логические группы шагов. Это же как разбивать код на процедуры и функции. В 1С модно делать методы на 3000 строк. Но это же ненормально )) Сценарии тоже нужно правильно оформлять. Иначе в сценариях бардак будет. Но глядя на имеющиеся примеры мне кажется, что человеческая лень всё же часто побеждает ))

Постараюсь привести примеры на этот счёт в следующий раз.


Да, примеры больше всего хотелось бы увидеть )

Это же как разбивать код на процедуры и функции


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

Я знаю как сделать экспортный сценарий, но слабо понимаю как это использовать в большом масштабе.
Если видимость сценария определяется текущим каталогом, то я получается все тесты в какую-то пирамиду собрать должен (типа головоломка такая). Это как-то не очень стыкуется со здравым смыслом.
Модулей нет, импорта нет, процедур нет, никакой квалификации шагов нет, ничего знакомого нет. Есть одно глобальное пространство в которое свалено все со странными областями видимости. Я просто тупо не понимаю как в этой каше можно вести разработку. В итоге мы сейчас собираем одну большую портянку, а потом ее будем нарезать (если поймем как вообще это делать)

Понимаете? На один шаг вперед видно, на два вроде тоже, а вот дальше туман. Если бы геркин/ванесса была сделана как классический ЯП, то и вопросов бы не было.

Осветите, пожалуйста, подробнее эти моменты в следующей статье. Есть подозрение что я просто что-то прошлепал и не знаю чего-то важного.
61. Vladimir Litvinenko 1755 26.01.19 22:14 Сейчас в теме
(60)
Осветите, пожалуйста, подробнее эти моменты в следующей статье.

Ох, следующая статья уже готова. Получилась такая, какая получилась )) Завтра вечером отправлю на модерацию. Там будет только практика на УТ 11. Три примера, начинаются с высокоуровневых шагов, затем "накликивание" на их основе, и затем переход к полноценному сценарию через объединение исходного сценария и исполняемых шагов.

Жаль, что Денис Олейник не имеет времени на публикацию по этой теме. Действительно было бы интересно узнать об опыте длительного применения этих инструментов на обновляемых типовых конфигурациях. Прочитал его соображения по теме ниже в комментариях, очень полезная информация.
1ceo_2015; tsukanov; +2 Ответить
62. tsukanov 57 27.01.19 14:48 Сейчас в теме
(29)
Сценарии в идеале должны быть независимы друг от друга. Но кажется я понимаю о чём речь. Речь о подготовки тестовых данных в целом.

Я это делаю через специальный этап сборочной линии - "Подготовка тестовых данных". Разворачиваю тестовую базу из копии рабочей (да да из копии рабочей, потому что программисты накодили там поиск по наименованию, кое где вшиты GUID и прочий хардкод, алгоритмы зависят от кучи пользовательских данных, просто так маленькую демо базу не сделать). Затем запускаю обработку инициализации - она готовит пользователей, сбрасывает пароли. Затем стартовые сценарии - подготовка тестовых данных.

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


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

Мне кажется сообществу при обсуждении нужно четко разграничивать два контекста:
1. Внедрения типовых с доработками
2. Собственная/тиражная разработка

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

Как говорил Маркс: "бытие определяет сознание" )

ps Пардон за капитанство. Я не очень сообразительный ) Подозреваю все это терлось уже вдоль и поперек в сообществе.
1ceo_2015; Pr-Mex; acanta; Vladimir Litvinenko; +4 Ответить
38. 1ceo_2015 24.01.19 14:45 Сейчас в теме
(26)
Вот эти вещи где-то освещены?
Что вообще может сделать писатель фич без программиста?
Как правильно взаимодействовать писателю и программисту. Это ведь трабл, т.к. у этих людей совершенно разные контексты.
Кто организует структуру сценариев? Писатель на уровне фич или программист под капотом?
Через год это не превратится в груду мусора (или, как модно говорить, тех. долг)?



Смотрите: в обоих плеерах починили возможность отображения произвольного текста после названия сценария согласно документации: https://docs.cucumber.io/gherkin/reference/#descriptions
https://github.com/silverbulleters/add/issues/323
https://github.com/Pr-Mex/vanessa-automation/issues/56

Зачем это нужно и почему это важно для фичеписателей и клиентов?
В этом произвольном тексте бизнес-аналитик (он же фичеписатель) конкретизирует критерий приемки на понятном для клиента языке.
Таким образом имеем первую итерацию сценария после общения с клиентом:



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




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

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

Можно построить story-map и разложить фичи по папкам согласно пользовательским активностям.
Можно пометить тегами и ими структурировать отчет аллюра.


Но самое главное, чтобы клиент это видел и понимал. Если не понимает и не видит - тогда пофигу все эти уровни детализации и произвольные тексты и кликерство.
Но это уже другая история. Руководителя проекта ;)"
JohnyDeath; oleynik.dv; Pr-Mex; Vladimir Litvinenko; +4 Ответить
39. tsukanov 57 24.01.19 22:02 Сейчас в теме
(38) Мне кажется вы не поняли о чем я писал.

Мы не с клиентом работаем, а между собой (покрываем систему тестами).
Фичи пишет тестировщик, а программер ему помогает. Вопрос был в этом.

Взаимодействие с клиентом через геркин меня вообще не интересует.

Например, сейчас пишется сценарий проверки прав, в котором уже овер 2000 шагов.
И это мы только только начинаем и пробуем.

ps В любом случае спасибо что поделились опытом

Ведь геркин это код


Спорное утверждение
41. oleynik.dv 121 25.01.19 12:11 Сейчас в теме
(39) К сожалению вы не поняли зачем Геркин :-(

Фичи пишет тестировщик, а программер ему помогает. Вопрос был в этом.


Это просто с ног на голову. Тестировщик пишет тест-кейсы. А фичи пишет бизнес-аналитик по результату сбора требований. Если у вас задача обкладывать готовый функционал тестами - то используйте (как вы и делаете) соответствующие инструменты (Тестер или Тестирование 3 или всё то же Сценарное тестирование).

Геркин он из BDD. Решается знаменитая проблема нахождения единого языка общения между бизнесом (как минимум бизнес-аналитиком, а в идеале стекйкхолдером), разработчиком и тестировщиком (three amigos):


Если у вас нет таких задач, то вам как говорится "Геркин не нужен!".
1ceo_2015; +1 Ответить
42. tsukanov 57 25.01.19 14:22 Сейчас в теме
(41) Возможно не понял. А возможно не поняли вы.
Тестировщик (или аналитик) тоже не технический специалист, он тоже проверяет поведение системы с точки зрения пользователя и ему тоже нужно взаимодействовать с техническим специалистом.
Озвученная вами проблема существует между технарем и прикладником независимо от того, сотрудниками какой конторы они являются. Для исполнителя-технаря клиентом является тот, кто ставит задачу.
Ну и вообще в исходных моих вопросах вопрошалось не о философских категориях сортов тестирования, а о проблемах на поле боя, с которыми приходится сталкиваться. Этот ваш BDD никто еще не продемонстрировал ни разу. Приводимые детские примеры обсуждать желания нет (это я еще не упоминаю что даже эти приводимые примеры содержат ошибки)


Ну и в целом, товарищи, я не говорил что мне нужен геркин и BDD. Для меня комбинации из трех букв все на одно лицо.
Меня интересует тестирование как таковое. Т.е. потыкать палкой и убедиться что шевелится.
BDD можно спокойно и в упомянутом вами Тестере делать. Это вопрос вкуса. Текущая беседа - не холивар о навязываемых методиках.

ps В 1С тоже не понимают зачем геркин, когда прикручивают его к СППР?
44. oleynik.dv 121 25.01.19 16:51 Сейчас в теме
(42) "Человек с молотком во всём видит гвоздь" (с)
Меня в институте учили, что для каждой специфической операции есть специальный инструмент.
Наверное, на матлабе можно сделать учётную систему. Но зачем?
Gherkin был придуман для BDD (Дэн Норт, Аслак Хилесой и иже с ними).
Пришёл Алексей Лустин и создал волну движухи "За BDD в 1С!". И на фоне этой движухи произошла подмена понятий: из языка формализации требований Gherkin стали превращать в язык автотестирования, коим он изначально не являлся и не является. Именно поэтому так тяжело идёт. Всем интересно, но как до дела - так и масса вопросов, нюансов и подводных камней. А ответов нет. А всё потому что не по назначению используется.

Поэтому если стоит вопрос обкладывания готового функционала тестами - надо решать её соответствующими инструментами (выше о них написал). И разработчикам легче в голову ложится, и поддерживать тесты проще, и методики и документация есть.
А если есть задача: отстроить проектное внедрение по Scrum - тогда User Story, Feature и Gherkin inside. С демонстрацией заказчику прироста полезной функциональности зелёными сценариями в Allure. О чём выше и написал 1ceo_2015 (за что и получил непонятые вами плюсы).

Что касается СППР и Gherkin. Сама тенденция не может не радовать. Но, насколько я знаю, если держать в голове тот факт, что разработка продукта в СППР оторвана от сценариев на Gherkin, то всё становится не так радужно. То есть в СППР 2 есть функциональная модель, по которой ведётся дальнейшая разработка, а сбоку есть некие бизнес-процессы, в узлах которых сидит турбо-геркин. То есть по сути левая рука не ведает о том, что творит правая. К сожалению, пресловутая подмена понятий перекочевала и в СППР. Методик, как применять СППР на проектах внедрения я тоже не услышал (на семинаре ERP).

По поводу Gherkin в СППР у нас с Pr-Mex идут жаркие дискуссии. Вот он кстати внизу вписался. Может дать обратную связь или поправить меня про СППР (если это не коммерческая тайна конечно же).
1ceo_2015; +1 Ответить
45. tsukanov 57 25.01.19 17:26 Сейчас в теме
(44) Аминь, пусть так. Не готов вести диалог о тестировании на таком уровне (жалко времени).
Мне эти холиворы не интересны.

Скажите, а сколько вы написали тестов в формате геркин? Сколько функционала покрыли таким способом?
Поделитесь опытом

ps И да, меня в институте учили совершенно другому.
47. oleynik.dv 121 25.01.19 18:34 Сейчас в теме
(45) Не ради холивара. Я говорю о целесообразности в выборе инструмента. Потренироваться с Gherkin на готовом функционале - почему нет. Но ставить это на поток, на мой взгляд, неправильно идеологически.

Тесты и покрытие - это не про Gherkin . Мы не тестируем готовый функционал. А разрабатываем новый по сценариям поведения пользователей. Сейчас заканчиваем второй проект внедрения, в котором ставим цель разработки по BDD. Идеального результата нет, и ответов на все вопросы, как это делать правильно тоже нет. Поскольку применять BDD в проектах внедрения/кастомизации тиражного продукта - это тоже нетривиальное использование инструмента, заточенного под продуктовую разработку.

В цифрах: на текущем проекте сейчас - это до двадцати фич, в каждой из которых 10-20 структур сценариев, в каждой 20-30 примеров. За количеством не гонимся. Нам важно именно выстроить процесс по методике и доказать (в первую очередь себе), что так можно работать и это эффективно.
Fox-trot; tsukanov; +2 Ответить
49. tsukanov 57 25.01.19 19:01 Сейчас в теме
(47)
В цифрах: на текущем проекте сейчас - это до двадцати фич, в каждой из которых 10-20 структур сценариев, в каждой 20-30 примеров. За количеством не гонимся. Нам важно именно выстроить процесс по методике и доказать (в первую очередь себе), что так можно работать и это эффективно.


Слабо понял. структуры - это что? примеры - это что?

Если не затруднит, опишите как организованы сценарии. Так мы хоть вернемся в конструктивное русло и к моим исходным вопросам, т.к. вы похоже обладатель того опыта, который меня интересует.
Было бы просто замечательно, если бы вы это описали в статье, и все наконец увидели бы BDD, а не кликеры.
50. oleynik.dv 121 25.01.19 19:35 Сейчас в теме
(49) я не успеваю писать статьи :-(
Максимум на комментарии хватает.
Да и поскольку законченного результата (которого все требуют в качестве пруфов) пока нет, то и писать неловко.

Посмотрите в профиле мою единственную (увы) статью. Там есть примеры структур сценариев.
Ну и есть вот этот очень полезный текст What's in a story (если с английским больно - вверху статьи есть ссылка на мой вольный перевод). Мы руководствуемся принципами из этой статьи.
Вот это по синтаксису Gherkin хорошо расписано.
54. tsukanov 57 25.01.19 23:01 Сейчас в теме
(50)
Да и поскольку законченного результата (которого все требуют в качестве пруфов) пока нет, то и писать неловко.


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

То что это работает в простейших случаях никто не сомневается (вашу статью посмотрел).
Непонятно как это делать в промышленных масштабах.

Статей и примеров детских я видел уже кучу. Проблема в том, что в реальности сценарии на порядок сложнее. Разложить все на микросценарии (как в примерах) тоже не видится возможным. Писать высокоуровневые фичи кажется по ресурсам нереальным (потому как тут вовлекается на фултайм как минимум 2 человека). И т.д. и т.п. Теория звучит заманчиво, но реальность с ней чет не очень стыкуется.

Я так понимаю что кроме как в СППР, никто так и не продемонстрирует кунгфу.
55. oleynik.dv 121 26.01.19 02:34 Сейчас в теме
(54) объясняю, почему топлю за трушность BDD.

BDD работает для продуктовой разработки. То есть новая функциональность появляется в продукте, после того как требования проходят через экструдер (например) Storymapping, составления критериев приёмки в User Story и последующего написания сценариев. Это важно: новая функциональность не появляется в продукте внезапно! И потому итеративность работает, сценарии просто так не падают - если они упали, то потому что мы накосячили. И такое нужно исправлять. Всё красиво.

Наш бизнес (как и у многих игроков на рынке 1С) - это внедрение и кастомизация типовых решений фирмы 1С. Соответственно, каждый игрок на этом рынке, обкладывающий готовый функционал сценариями на Gherkin, живёт на пороховой бочке из свежих релизов типовых решений (с переименованием общих модулей, объектов метаданных, не говоря уже о реквизитах и формах). Понимаете? Я это понял, на собственном опыте. Когда проект начинался на версии 2.2, и сценарии писались под эту версию, и функционал 2.2 кастомизировался (реквизиты, формы, свои обработки-отчёты). Долго писались. Около года. А потом пришла 2.4. И обновляться нужно было без вариантов. Больше половины сценариев просто умерли. Когда я прикинул конскость затрат на рефакторинг всего этого - просто опустились руки. То есть мало того, что после обновления глючит измененный функционал на обновленной конфигурации (что как бы предсказуемо), так ещё и сломана реализация сценариев, которые были призваны контролировать эту регрессию. В результате остались только дымовые.

Какие вижу варианты выхода из ситуации:
1. Не обновляться никогда. У нас есть клиенты до сих пор живущие на УТ 11.1, и им этого хватает. Древние УПП без ведения регл. учёта. Из глобальных изменений - 20% НДС. Здесь обкладывание готового функционала сценариями как процесс фиче-реинжиниринга имеет место быть. Ну то есть обложили сценариями готовый функционал - и дальше уже можно BDD-ить по полной.
2. Нужно на этапе внедрения вводить свою интерфейсную прослойку. И на её основе писать сценарии. Собственный рабочий стол под каждую роль (не в терминах 1С) в системе, разнообразные АРМ, фоном использующие типовой функционал. При таком подходе не нужно будет чинить сценарии после обновления, поскольку бизнес-логика не поменяется. Нужно будет адаптировать прослойку под новый функционал типового решения. Но это нормальная работа программистов. То есть покрасневшие сценарии будут нам показывать проблемы адаптации прослойки к новому типовому функционалу, а не проблемы реализации сценариев, потому что документ "Поступление" в 2.4 стал называться "Приобретением".
3. Фирма 1С начинает разрабатывать типовые продукты по BDD и на выходе вместе с очередным релизом выдаёт пачку сценариев на Gherkin, которые на некой эталонной базе зеленеют в Allure. Это не даёт ясности в том, как жить после обновления кастомизированной конфигурации, зато даёт отличную базу для регрессии. И здесь вся надежда на СППР и Pr-Mex.

По первому варианту клиенты платить не готовы. А если готовы - то реинжиниринг требует таких затрат "мыслетоплива", что теряется весь смысл затеи. Кроме того, это не масштабируется. Каждый раз нужно проделывать работу заново. Людей, которым это можно делегировать, не существует, поскольку никто этого делать не умеет. Соответственно мы идём по второму варианту, а он требует трушного BDD-подхода. С короткими человеко-читаемыми сценариями, описывающими бизнес-логику, получением обратной связи от клиентов - "понятно ли написано, это ли вам надо?".
freddy121; Vladimir Litvinenko; tsukanov; 1ceo_2015; +4 Ответить
58. tsukanov 57 26.01.19 13:40 Сейчас в теме
(55) Спасибо за развернутый ответ!
Прям ощутил вашу боль. Сам работал раньше на внедрениях и допилах типовых.
Но сейчас у меня ситуация не похожа на вашу. Тиражная разработка. Соответственно новый функционал обычно затрагивает сразу многие объекты в конфе. И даже если вообразить, что мы делаем это под конкретного юзера, то проблема все равно остается. Объем даже простейших тестов получается не маленьким. Хоть ты сквозной бизнес-процесс прогоняй в минимальном варианте, хоть россыпь мини BDDшек. Есть куча вопросов организационного и чисто технического плана. И мы пытаемся организоваться ведь не в вакууме. Есть ограничения на ресурсы, есть особенности командного состава, есть устоявшиеся практики. Хочется чтобы пакет тестов понимали все участники, чтобы можно было понимать что у нас покрыто тестами а что нет, и много других чтобы...
И вопрос использовать BDD или нет вообще не стоит. Мы решаем свою конкретную проблему в своей системе координат. Ванесса заинтересовала банально тем, что гипотетически сценарии может понять любой участник без доп. подготовки (хотя это пока вызывает сомнения). Т.е. мы смотрим только на определенные свойства инструмента, а все аббревиатуры оставляем за дверью. Нам не важно как будет называться методика (и есть ли вообще название), на рельсы которой мы встанем в итоге. Нам важно получить адекватный нашей реальности подход.
63. grumagargler 606 28.01.19 20:17 Сейчас в теме
(55)
Соответственно, каждый игрок на этом рынке, обкладывающий готовый функционал сценариями на Gherkin, живёт на пороховой бочке из свежих релизов типовых решений (с переименованием общих модулей, объектов метаданных, не говоря уже о реквизитах и формах)

И встает вопрос - что же это за инструмент тестирования такой, который фактически вынуждает вас вместо эволюции продукта, хоронить его под вашими тестами? То есть получается, что для кода, который вы не писали, у вас не хватает сил изменить тесты, а что если вам этот код еще и писать придётся, это же еще больше сил хватать не будет! На мой взгляд проблемы, которые решает bdd важны, но уж сильно переоценены. У каждого своя статистика, но моя говорит о том, что проблемы в продуктах существенно чаще связаны с чистыми ошибками, недосмотрами, и недостаточным качеством тестирования, и совсем не часто с тем, что кто-то кого-то не понял.
По поводу покрытия готового функционала. Как раз описываемый bdd-инструментаций, по факту, и выводит тестирование уже готового функционала. Вести разработку (программирование) с такими инструментами очень сложно, начиная от перезапусков приложения и заканчивая подготовкой тестовых данных, а в тестере - этот процесс бесшо