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

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

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

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

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

https://www.youtube.com/watch?v=2Ulzs81ExB4
Tavalik; artbear; +2 Ответить
10. Pr-Mex 122 21.01.19 14:50 Сейчас в теме
(1)
Порадовала концовка видео )
Я думаю, Серебряной пуле лучше начать с запуска CI контура для самого ADD, а уже потом переходить к покрытию тестами ЗУП.
17. Vladimir Litvinenko 1738 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 1143 21.01.19 12:34 Сейчас в теме
(0) Огромное спасибо за две обалденные и очень полные статьи :)
Tavalik; Vladimir Litvinenko; +2 Ответить
4. Pr-Mex 122 21.01.19 12:56 Сейчас в теме
(0)
Спасибо за статью.
Единственное что не очень - это гифки. В них нет паузы и перемотки. Не всегда удобно смотреть.
kuzyara; tormozit; +2 Ответить
9. oleynik.dv 120 21.01.19 14:35 Сейчас в теме
(4) Позвольте с вами не согласиться, уважаемый коллега! ;-)
Размер имеет значение. Хорошая гифка на 3-5 сек в тексте намного нагляднее статичной картинки. Тут важно чувство меры.

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

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

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


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

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

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

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

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

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


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

Здесь или на форуме https://xdd.silverbulleters.org/c/razrabotka/vanessa-add
21. Vladimir Litvinenko 1738 21.01.19 16:27 Сейчас в теме
(19) Продублирую описание установки и описанный здесь эффект на форум, как только появится время.
Возможно проблема в том, что на машинах, где редактирую сценарии, установлена Windows 7. Как на домашнем, так и на рабочем компьютере. Где-то читал, что с Windows 7 проблемы возникают с этим плагином. На CI-сервере где Windows Server 2016 плагин не ставил. Посмотрю поведение на нём чуть позже, может быть такой эффект наблюдаться не будет.
20. artbear 1143 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 54 21.01.19 19:02 Сейчас в теме
(20) Написав вопросы на форуме 12 дней назад так и не дождался ни одного комментария )
Поддержка платная или я что-то не то / не так спросил?
new_user; +1 Ответить
26. tsukanov 54 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 1738 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 54 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 1738 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 54 22.01.19 20:29 Сейчас в теме
(34)
Могу порекомендовать хорошие инструменты Crucible+Fisheye , сейчас на Github есть файлы настроек для подсветки синтаксиса языка 1С для Crucible.


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

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


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

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

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


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


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

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

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


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

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

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

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

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


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

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


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

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

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

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

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

Жаль, что Денис Олейник не имеет времени на публикацию по этой теме. Действительно было бы интересно узнать об опыте длительного применения этих инструментов на обновляемых типовых конфигурациях. Прочитал его соображения по теме ниже в комментариях, очень полезная информация.
1ceo_2015; tsukanov; +2 Ответить
62. tsukanov 54 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 54 24.01.19 22:02 Сейчас в теме
(38) Мне кажется вы не поняли о чем я писал.

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

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

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

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

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


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

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


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

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


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


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

ps В 1С тоже не понимают зачем геркин, когда прикручивают его к СППР?
44. oleynik.dv 120 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 54 25.01.19 17:26 Сейчас в теме
(44) Аминь, пусть так. Не готов вести диалог о тестировании на таком уровне (жалко времени).
Мне эти холиворы не интересны.

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

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

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

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


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

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

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


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

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

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

Я так понимаю что кроме как в СППР, никто так и не продемонстрирует кунгфу.
55. oleynik.dv 120 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 54 26.01.19 13:40 Сейчас в теме
(55) Спасибо за развернутый ответ!
Прям ощутил вашу боль. Сам работал раньше на внедрениях и допилах типовых.
Но сейчас у меня ситуация не похожа на вашу. Тиражная разработка. Соответственно новый функционал обычно затрагивает сразу многие объекты в конфе. И даже если вообразить, что мы делаем это под конкретного юзера, то проблема все равно остается. Объем даже простейших тестов получается не маленьким. Хоть ты сквозной бизнес-процесс прогоняй в минимальном варианте, хоть россыпь мини BDDшек. Есть куча вопросов организационного и чисто технического плана. И мы пытаемся организоваться ведь не в вакууме. Есть ограничения на ресурсы, есть особенности командного состава, есть устоявшиеся практики. Хочется чтобы пакет тестов понимали все участники, чтобы можно было понимать что у нас покрыто тестами а что нет, и много других чтобы...
И вопрос использовать BDD или нет вообще не стоит. Мы решаем свою конкретную проблему в своей системе координат. Ванесса заинтересовала банально тем, что гипотетически сценарии может понять любой участник без доп. подготовки (хотя это пока вызывает сомнения). Т.е. мы смотрим только на определенные свойства инструмента, а все аббревиатуры оставляем за дверью. Нам не важно как будет называться методика (и есть ли вообще название), на рельсы которой мы встанем в итоге. Нам важно получить адекватный нашей реальности подход.
63. grumagargler 597 28.01.19 20:17 Сейчас в теме
(55)
Соответственно, каждый игрок на этом рынке, обкладывающий готовый функционал сценариями на Gherkin, живёт на пороховой бочке из свежих релизов типовых решений (с переименованием общих модулей, объектов метаданных, не говоря уже о реквизитах и формах)

И встает вопрос - что же это за инструмент тестирования такой, который фактически вынуждает вас вместо эволюции продукта, хоронить его под вашими тестами? То есть получается, что для кода, который вы не писали, у вас не хватает сил изменить тесты, а что если вам этот код еще и писать придётся, это же еще больше сил хватать не будет! На мой взгляд проблемы, которые решает bdd важны, но уж сильно переоценены. У каждого своя статистика, но моя говорит о том, что проблемы в продуктах существенно чаще связаны с чистыми ошибками, недосмотрами, и недостаточным качеством тестирования, и совсем не часто с тем, что кто-то кого-то не понял.
По поводу покрытия готового функционала. Как раз описываемый bdd-инструментаций, по факту, и выводит тестирование уже готового функционала. Вести разработку (программирование) с такими инструментами очень сложно, начиная от перезапусков приложения и заканчивая подготовкой тестовых данных, а в тестере - этот процесс бесшовный. То, что должен делать функционал - легко описывается в комментарии, а дальше - чистый код, без особенностей поведения.
Я прочитал последнюю статью Владимира. Парни, вы всерьёз утверждаете, что овладеть технологией в состоянии простой тестировщик, что всем всё понятно, и такие шаги как “И я запоминаю значение поля с именем "Дата" как "ДатаДокумента"” не являются артефактом того, что подход протекает под реальностью?
64. tsukanov 54 28.01.19 21:58 Сейчас в теме
(63)
То есть получается, что для кода, который вы не писали, у вас не хватает сил изменить тесты, а что если вам этот код еще и писать придётся, это же еще больше сил хватать не будет!


Ну тут мужиков можно понять. Все таки если у тебя, скажем, ERP, и ты клиенту делаешь какую-то доработку точечно, то понятно поддержка тестов функционала самой ERP - это фантастика. Это затраты, которые никак не всунешь в бюджет внедрения. Просто потому что вендор не ты.
И может быть для таких точечных тестов BDD у них хорошо ложится. Но это думается будет работать только в специфических случаях, когда нет задачи написать целую подсистему учета с нуля. Т.к. эта подсистема очевидно будет сшиваться с типовым функционалом, и тесты нужны будут большие и сквозные...
65. grumagargler 597 28.01.19 22:13 Сейчас в теме
(64)
Ну тут мужиков можно понять. Все таки если у тебя, скажем, ERP, и ты клиенту делаешь какую-то доработку точечно, то понятно поддержка тестов функционала самой ERP - это фантастика

Но ведь это “дано”. Это именно то, что в 90% случаев и приходится делать, и соответственно - тестировать. Не требуется покрывать своими тестами типовой функционал, достаточно иметь тесты-методы, которые будут создавать нужные данные по необходимости, и инструментарий должен легко давать возможность менять эти тесты без страха перед изменениями, ведь для этого тесты и существуют - не бояться менять/развивать функционал. И не все доработки заканчиваются добавлением новых объектов. А что если нужно тестировать измененный типовой документ, писать тест или нет? Если писать - значит получается очередное обновление (что норма) - это большая проблема восстановить работоспособность тестов.
66. tsukanov 54 28.01.19 22:33 Сейчас в теме
(65)
Не требуется покрывать своими тестами типовой функционал


Ну я в общем то о том же )

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

ps Ну или я уже вообще не соображаю, пардон
67. grumagargler 597 28.01.19 22:47 Сейчас в теме
(66)
ps Ну или я уже вообще не соображаю, пардон

Как по мне, всё отлично вы соображаете и задаете острые вопросы, которые многие стесняются задавать.
Конечно, прийти на работу и сесть за написание тестов покрытия функционала типовой, неправильно, думаю об этом и речи ни у кого нет. Но, не писать тесты для покрытия своего функционала, которые затрагивают типовые объекты - нельзя, иначе о каком тестировании речь. Если добавляется движение в документ ПоступлениеТоваров, то проверить эту доработку без создания теста для типового ПоступлениеТоваров - нельзя. И то, что этот документ, будет меняться от релиза к релизу - это совсем не новость, не сложность, и ни что иное - как нормальная ситуация, и если инструментарий + методика к этому не готовы, или готовы настолько, чтобы не делать эти обновления, тогда нельзя говорить о продуктивном тестировании.
68. Vladimir Litvinenko 1738 28.01.19 22:49 Сейчас в теме
(66) Представьте себе торговую компанию. Работа 24/7, точки по всей России. Типовая конфигурация с доработками. Критичные операции - закупка , перемещение, заказ клиента и реализация товара.

Допустим мы доработали документ "Реализация товаров и услуг". Одновременно с ним доработка коснулась складского учета. Планируются дальнейшие доработки типовых модулей складского учета и методов модулей, которые задействованы в различных типовых механизмах.

Следует ли при этом написать хотя бы несколько функциональных тестов на процесс заказа товара клиентом, перемещения товаров и процесс поступления товаров?


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

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

Вот если фирма 1С сама начнёт выпускать такие тесты для типовых механизмов - вот это будет классно и решит эту проблему без дополнительных затрат.
1ceo_2015; +1 Ответить
69. oleynik.dv 120 29.01.19 00:49 Сейчас в теме
(63) Дмитрий, совершенно верно: у каждого своя статистика. И свои проблемы (в том числе и финансовые), над решением которых мы работаем.
Нам важно НЕ слышать от заказчика фразу: "то, что вы сделали работает, но это не то, что мне нужно...", потому что после такой фразы заказчик плохо платит.
Для вас же эта антифраза, по-моему (я много читал вас на infostart), звучит так: "вы сделали то, что мне нужно, на как это всё глючит...".

Если упростить workflow разработки до вида:
1. Бизнес-анализ
2. Формализация требований
3. Разработка
4. Тестирование
то нас интересует (и в чём мы видим, прости Господи, challenge) в большей степени 1, 2 и 3. Для вас же, как мне кажется, в приоритете 3 и 4. То есть "что нужно реализовать" - у вас с этим всё чётко и понятно, осталось реализовать и протестировать. А у нас проблема понять мутного и нечёткого заказчика, вывести его на проверяемые критерии приёмки по его хотелкам, и после реализации убедиться в том, что критерии приёмки реализованы в разработанном функционале.

Соответственно мы не рассматриваем Vanessa как инструмент тестирования. Для нас это инструмент валидации реализации критериев приёмки. То что на выходе в качестве побочного эффекта мы получаем регрессионку - это бонус. Но ключевое - это показать клиенту, что то, что мы реализовали - это то, что он хотел.

То есть вот та низовая техника работы с Vanessa, которую описывает Владимир - это как бы must have, но не core feature. Человекочитаемые, основанные на примерах сценарии, ориентированные на заказчика - вот то, ради чего, на мой взгляд, стоит пользоваться Vanessa. Если это не нужно, и нет такой проблемы и задачи - то конечно надо пользоваться вашим тестером. Он намного ближе программисту и тестировщику, и те самые проблемы изменяющихся эталонных данных, обхода последствий обновления конфигурации у вас проработаны методически лучше (о чём я уже писал выше).

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

P.S.
Что до проблемы с обновлением - мы работаем над этим, это своего рода творческий процесс. Как разрабатывать, и как оформить сценарии, чтобы это было устойчиво к обновлению. Ещё пара мучительных обновлений и я сойду с ума будет выработана какая-то методика.

P.P.S.
При достаточном финансировании было бы даже интересно провести эксперимент с комбинированием использования Vanessa и Тестер на одном проекте. Чтобы на каждом этапе упрощенного workflow применялся подходящий для него инструмент.
1ceo_2015; grumagargler; +2 Ответить
70. grumagargler 597 29.01.19 01:23 Сейчас в теме
(69)
Если упростить workflow разработки до вида:
1. Бизнес-анализ
2. Формализация требований
3. Разработка
4. Тестирование
то нас интересует (и в чём мы видим, прости Господи, challenge) в большей степени 1, 2 и 3. Для вас же, как мне кажется, в приоритете 3 и 4. То есть "что нужно реализовать" - у вас с этим всё чётко и понятно, осталось реализовать и протестировать.

Верно. Но сказать, что у нас совсем нет проблем с 1 и 2, значит солгать. Проблемы есть, но нам никогда не удавалось их успешно формализовывать. Формализовать - можно, успешно в общем смысле этого слова - нет. Можно доказать, что заказчик это и просил, и заставить его рассчитаться, но это не делает нас лучше, если мы по факту, не уловили исходную проблематику (оставим за скобками непорядочных клиентов). Поэтому, кроме, понятное дело, воспитания у себя чувства задачи, мы решили сместить проблемы такого рода в процесс разработки, чтобы развязать себе руки используя гибкие средства по тестированию, чтобы делать задачи не по принципу “не навредить”, и по принципу - как это должно быть, чтобы не бояться перекраивать код, как решения, так и тестов, ведь согласитесь, в больших проектах, значительно чаще возникает страх что-то сломать, чем изменить. Поэтому, когда функционал приклеивается тестами в силу сложности их создания/модификации, я нахожу это противоречивым самой идее тестирования.
tsukanov; +1 Ответить
71. Pr-Mex 122 29.01.19 13:59 Сейчас в теме
(63)
На мой взгляд проблемы, которые решает bdd важны, но уж сильно переоценены. У каждого своя статистика, но моя говорит о том, что проблемы в продуктах существенно чаще связаны с чистыми ошибками, недосмотрами, и недостаточным качеством тестирования, и совсем не часто с тем, что кто-то кого-то не понял.


Ошибки проектирования самые дорогие.
Реализация того, что не просил заказчик - тоже стоит дорого.
72. Pr-Mex 122 29.01.19 14:00 Сейчас в теме
(63)
По поводу покрытия готового функционала. Как раз описываемый bdd-инструментаций, по факту, и выводит тестирование уже готового функционала. Вести разработку (программирование) с такими инструментами очень сложно, начиная от перезапусков приложения и заканчивая подготовкой тестовых данных, а в тестере - этот процесс бесшовный. То, что должен делать функционал - легко описывается в комментарии, а дальше - чистый код, без особенностей поведения.


Расскажите, что вам мешает сделать "бесшовным" процесс разработки в Ванессе?
73. Pr-Mex 122 29.01.19 14:02 Сейчас в теме
(63)
Я прочитал последнюю статью Владимира. Парни, вы всерьёз утверждаете, что овладеть технологией в состоянии простой тестировщик, что всем всё понятно, и такие шаги как “И я запоминаю значение поля с именем "Дата" как "ДатаДокумента"” не являются артефактом того, что подход протекает под реальностью?


Да, простой тестировщик (в том числе без навыков программирования) легко осваивает.
74. 1ceo_2015 29.01.19 15:56 Сейчас в теме
(73)
Да, простой тестировщик (в том числе без навыков программирования) легко осваивает.


Приходит секретарша устраиваться на работу:
HR у нее спрашивает: с какой скоростью печатаете?
С: - 10 000 знаков в минуту?
HR: -ЧТО, правда???
C: - правда. Но такая херня получается...

освоить кликерство оно конечно просто. Главное тут освоить осмысленное кликерство имхо ;)

Интересен кейс когда один такой кликер уволился и вместо него посадили другого кликера. И еще произошло обновление с 2.4.2 до 2.4.7 и тесты на этом ГеркинАссемблере упали и надо понять это они упали или функционал.
Такой опыт у кого-то был?
tsukanov; acanta; +2 Ответить
75. Pr-Mex 122 30.01.19 09:27 Сейчас в теме
(74)
У нас тестировщик - это ещё методолог в своей области.
Он хорошо понимает, что там происходит.

А чтобы сценарий не превращался в стену текста - существует практика кодревью.
1ceo_2015; Vladimir Litvinenko; +2 Ответить
76. 1ceo_2015 30.01.19 13:15 Сейчас в теме
(75) Леонид, я другой кейс уточнял. Передачу контекста между тестировщиками в случае критического обновления конфы.
Когда один тестировщик и он методолог и вечный раб компании - это идеальный вариант из идеального мира))
80. tsukanov 54 31.01.19 12:14 Сейчас в теме
(73) Минус походу ткнул простой тестировщик )))

Ну а вообще простой тестировщик и программирование легко осваивает.
Объективных экспериментов и сравнения (что легче) вроде никто не публиковал.
1ceo_2015; +1 Ответить
52. Pr-Mex 122 25.01.19 19:56 Сейчас в теме
(47)
Тут, на мой взгляд, подмена понятий происходит.
Инструментарий на геркине позволяет реализовывать в жизнь и такие и такие подходы.
И создавать сценари от верхнеуровневых требований - тогда речь про BDD.
И просто покрыть сценариями то, что уже есть. Это просто тестирование.

У вас же была на сайте статья, как вы используете BDD. Скинешь ссылку?
57. oleynik.dv 120 26.01.19 03:01 Сейчас в теме
(52) К пуговицам претензий нет ;-)
Инструмент хороший и с каждым релизом всё хорошеет.
А статья была про то, как мы пытаемся разрабатывать по BDD, и как у нас это НЕ получается.
Про подходы написал в (55).
46. Pr-Mex 122 25.01.19 17:36 Сейчас в теме
(44)
Сценарии в СППР связаны с функциональной моделью.
Также в СППР есть средства для моделирования и запуска бизнес-процессов.
Похоже, ты не очень в теме как оно там устроено )
48. oleynik.dv 120 25.01.19 18:35 Сейчас в теме
(46) Покажешь на партнёрке ;-)
51. Pr-Mex 122 25.01.19 19:53 Сейчас в теме
(48)
Приходи. И все кому интересна эта тема, тоже приходите.
53. tsukanov 54 25.01.19 20:25 Сейчас в теме
(44) В порядке смолтока (типа на перекуре):
Вот вы набежали в комменты и судя по всему записали меня в какой-то лагерь.
Шутка юмора в том, что я не принадлежу никакому лагерю и никакой идеологии.
Все эти ваши BDD, TDD, User Story, Геркины, Лустины, Нортоны....
Как бы вам сказать... Для меня все это шелуха. И все эти идеологические вопросы и кто по какой модной аббревиатуре работает или тестирует - все это не важно.
Я постигал программерское ремесло совершенно другим способом. И тестирование для меня - это просто искусство тыкать палкой. А базируется мое представление на том, что писал Дейкстра (и многие другие пионеры).
Возможно вы будете удивлены, но понятия "предусловие" и "постусловие" известны многим образованным людям очень давно. И вот когда эти люди всю профессиональную жизнь оперировали этими понятиями, а им начинают втирать про идеологию BDD....
Наверно не надо объяснять как глупо это выглядит со стороны? )

И я вам даже больше скажу. Мы, было дело, составляли технические задания с табличкой:
|предусловие|действие|постусловие|
Где описывался сценарий поведения юзера. Вот прям те же яйца в профиль. И это использовалось для согласования. И мы на тот момент о существовании аббревиатуры BDD и не слыхивали даже.

А все потому что:
1. Формальный подход, который позаимствовал BDD существует как минимум с 70х
2. Все, кто читает первоисточники, о нем знают уже цать лет (почти вся пионерская работа активно переводилась в союзе).
3. Самое вкусное - этот подход же совершенно очевиден. Иначе тестить и нельзя вовсе.

И вот с какого перепугу я должен перестать мыслить в исходных категориях и начать с вами тереть какие три буквы идеологически верней?

Надеюсь мне удалось показать world in my eyes ) Так будет больше взаимопонимания.
oleynik.dv; 1ceo_2015; +2 Ответить
56. oleynik.dv 120 26.01.19 02:53 Сейчас в теме
(53) Да бросьте вы, какие лагеря и три буквы... ;-)

Если человек мыслит в терминах:
|предусловие|действие|постусловие|

то это наш человек ))).

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

Ситуация сейчас напоминает вот эту картинку из блога Асхата Уразбаева:

Собственно, на фоне этой картинки и ситуации из меня так много текста )
tsukanov; +1 Ответить
59. tsukanov 54 26.01.19 14:01 Сейчас в теме
(56) Понимаю ваше негодование )

Правда есть один тонкий момент. Подобную картинку (в нашем контексте) можно понимать двояко:
1. Нарушение принципов BDD
2. Нарушение принципов тестирования как такового

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

И вот теперь, когда все прояснилось, перечитайте о чем я спрашивал в самом начале (26) :)
43. Pr-Mex 122 25.01.19 14:44 Сейчас в теме
(41)
Обкладывать тестами готовый функционал можно на чём угодно. И с помощью Геркина и без него.
tsukanov; 1ceo_2015; +2 Ответить
40. tsukanov 54 25.01.19 11:48 Сейчас в теме
(38) Удивительно что ваш комментарий плюсуют. Ведь он абсолютно мимо кассы. Без обид.
Сломанный телефон какой-то. Видимо мне стоит как нибудь выделить время и разобрать все по косточкам так, чтобы не было не единого шанса появляться комментам, подобным вашему.

Совершенно парадоксальное недопонимание. Прям как с синезолотым платьем.
27. tormozit 5509 21.01.19 22:40 Сейчас в теме
Статья хороша. А вот гифки без паузы - неудобно. Неплохим решением было бы приостанавливать гиф-анимацию при нахождении курсора на области картинки. Интересно, существуют ли такие плагины для браузеров?
30. grumagargler 597 22.01.19 01:54 Сейчас в теме
Но здесь Вы должны понимать, что продукты создаются на энтузиазме разработчиков

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

Понимаете, этим почти всё можно оправдать, начиная от качества кода, и заканчивая отсутствием документации и/или поддержки. Я считаю это не совсем честно по отношению к коллегам. По моим наблюдениям, энтузиастов-разработчиков чаще распирает от желания показать свои наработки, обретенные знания или просто желание заявить о себе, и при этом - не учитывается потеря времени людьми, которые пытаются безуспешно овладеть этими новациями. То, что распирает - хорошо, до тех пор, пока не нарушается баланс заявлено/по факту. Давайте будем честными, очень часто, отсутствие документации или статей практического характера далеко не всегда связано с тем, что просто “руки не дошли написать”, причины чаще кроются за недостаточной проработкой темы как таковой. Вот и получается, заявляется одно, народ на волне мыкается как слепые котята, мало что получается...ну а какие проблемы, опенсорс ведь.
Я это делаю через специальный этап сборочной линии - подготовка тестовых данных. Разворачиваю тестовую базу из копии рабочей (да да из копии рабочей, потому что программисты накодили там поиск по наименованию, кое где вшиты GUID и прочий хардкод, алгоритмы зависят от текущей даты, просто так маленькую демо базу не сделать). Затем запускаю обработку инициализации - она готовит пользователей, сбрасывает пароли. Затем стартовые сценарии - подготовка тестовых данных.

У вас для прохождения тестов требуется восстановление рабочей базы (вынесем за скобки её потенциально большой размер) и последующая подготовка данных. Я правильно понимаю, что в этом случае тестирование не интегрировано в процесс программирования (разработчики не могут оперативно обмениваться тестами, не могут создавать ситуации на лету, повторно запускать тесты без очистки данных), либо эта задача не кажется первостепенной ?
31. Vladimir Litvinenko 1738 22.01.19 02:42 Сейчас в теме
По моим наблюдениям, энтузиастов-разработчиков чаще распирает от желания показать свои наработки....
Давайте будем честными, очень часто, отсутствие документации или статей практического характера далеко не всегда связано с тем, что просто “руки не дошли написать”, причины чаще кроются за недостаточной проработкой темы как таковой.


Вижу недостижимый для меня уровень абстракции. Если в прошлой или этой публикации есть недостаточно проработанные темы, то напишите, пожалуйста, про них. Постараюсь раскрыть их в следующий раз. В этой публикации старался расписать всё максимально подробно. Есть ли пункт, который не получилось проработать руками по тексту статьи?
32. grumagargler 597 22.01.19 05:09 Сейчас в теме
(31)
Вижу недостижимый для меня уровень абстракции. Если в прошлой или этой публикации есть недостаточно проработанные темы, то напишите, пожалуйста, про них. Постараюсь раскрыть их в следующий раз. В этой публикации старался расписать всё максимально подробно.

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

Нет, я даже и не думал придираться. Перефразируя коллегу выше, по форме - всё отлично, по сути - выхлоп на уровне прошлых статей. И не думайте обижаться! Вы объяснили, решили начать с начала. Продолжайте, и потом вернемся к разговору тестовых данных, применимости методологии для программистов, изменчивости состава метаданных, рефакторингу тестовых данных и сценариев, и другим интересным проверкам, например проверить что в журнале стало на одну запись больше, заведомо не зная сколько там было, прокрутить период кнопками назад до нужного значения, когда начальное не статично и определяется текущим периодом и многое-многое другое.
slax; tsukanov; oleynik.dv; Vladimir Litvinenko; +4 Ответить
77. user670203_terskovaoa 30.01.19 14:46 Сейчас в теме
При запуске Vanessa Behavior не запускается запись действий пользователя, появляется ошибка "Значение не является значением объектного типа (ДопПараметры)" и еще вот это "30.01.2019 14:45:40 Не найден TestClient для подключения."
Подскажите пожалуйста что не так?
78. Vladimir Litvinenko 1738 30.01.19 17:56 Сейчас в теме
(77) Этой информации мало, чтобы сделать какие-то предположения о причинах такого поведения.
Запись действий пользователя всё же не должна запускаться при запуске Vanessa Behavior. Она должна запускаться отдельной командой. Нужно более точно описать момент возникновения проблемы - при запуске VB или при нажатии на кнопку записи действий пользователя.
Также не помешал бы скриншот, иначе долго гадать будем.
79. user670203_terskovaoa 31.01.19 09:29 Сейчас в теме
Я только знакомлюсь с этим функционалом, и установила компоненты как показано в статье, хотела проверить все ли нормально, а тут такая ошибка... При запуске VB все нормально. Когда пытаюсь подключиться к тестовой базе появляется окно с ошибкой, а когда пытаюсь начать запись действий, то появляется сообщение.
Прикрепленные файлы:
81. Vladimir Litvinenko 1738 31.01.19 16:49 Сейчас в теме
(79) Ошибка может быть как в VB, так и в тестируемом приложении. Нужен стек исключения. А лучше отладчик подключить.

Вообще окно VB выглядит странно. В нём нет информации о версии. Заголовок должен быть похож на "ver 5.6.0: Vanessa Behavior". А у вас там написано просто Vanessa Behavior. Похоже, что либо установка некорректно прошла либо какая-то старая версия установлена.
82. user670203_terskovaoa 31.01.19 16:59 Сейчас в теме
Спасибо. Устанавливала, через 1script. Попробую еще раз установить.
83. user670203_terskovaoa 12.02.19 10:09 Сейчас в теме
Добрый день. Переустановила несколько раз, все по инструкции, но при открытии bddRunner.epf появляются два окошка и она не запускается так как нужно.
Прикрепленные файлы:
85. Vladimir Litvinenko 1738 12.02.19 10:28 Сейчас в теме
(83) (83) В публикации есть раздел

"Необходимые права на установку библиотек OneScript и настройка прав на запуск внешних обработок"

В нём описано, что необходимо сделать, чтобы избавиться от этого предупреждающего окна. Также информация есть на ИТС здесь: https://its.1c.ru/db/v838doc#bookmark:dev:TI000001873
84. user670203_terskovaoa 12.02.19 10:09 Сейчас в теме
Подскажите пожалуйста что я делаю не так????
86. user670203_terskovaoa 12.02.19 10:59 Сейчас в теме
87. nvv1970 03.03.19 23:35 Сейчас в теме
Коллеги, просветите: откуда название пошло Vanessa ? ))
88. Vladimir Litvinenko 1738 04.03.19 10:52 Сейчас в теме
91. nvv1970 19.03.19 13:10 Сейчас в теме
(88) Уан эс са = One S 'a = 1C
Как же я сразу не допер )
for_sale; +1 Ответить
89. NightBreez 13.03.19 11:33 Сейчас в теме
А когда ожидать следующую публикацию ? Очень интересно посмотреть примеры про тестирование обмена в РИБ.
90. Vladimir Litvinenko 1738 13.03.19 11:39 Сейчас в теме
(89) Ссылки на три следующие части можно найти в профиле.
92. for_sale 755 06.05.19 17:23 Сейчас в теме
Большое спасибо за статьи, очень ценный материал.

Есть вопросы, пожелания и предложения))

1. Открыл обработку, включил УИ, записал сценарий, жму Подготовить сценарий. Вываливается ошибка о том, что папка Ц-Юзерс-итакдалее\Temp\vanessa-add не найдена. Оказалось, что темповый файл пытается туда записать, хотя эту папку никто не создавал.

2. Есть ли какая-то библиотека знаний на эту огромную тему? Не форумы, а именно кладезь? Вопросы сыпятся на каждый прочтённый абзац и на каждую нажатую кнопку. Или всё-таки придётся лезть в конфигуратор?

3. Простой пример вопросов - у нас в разрабатываемом модуле есть версии. И эти версии выводятся в заголовок окна. Соответственно, если писать сценарий "И я открываю окно ""Обработка в.1""", то завтра этот сценарий надо будет переписать на "И я открываю окно ""Обработка в.2""". Есть ли возможность указывать что-то вроде "Окно, имя которого начинается на "Обработка в."". Если нет, то как это создать?

4. По циклу статей. Автору за труд - низкий поклон. Но всё же материал довольно путанно изложен и длина текста просто нереальная. Вначале идёт пример, потом установка, потом постянные отсылки к примеру, всё это промежается геркином и настройками. В результате приходится бегать между статьями, одни абзацы пропускать, другие искать и т.п. Может разбить материалы на статьи длиной 10001 символ (иф ю ноу ват ай мин) и пронумеровать их в том порядке, в котором человек, который вообще ничего не знает по теме, мог бы, постепенно сталкиваясь с функционалом, его гармонично познавать? Заодно тогда можно было бы задавать вопросы по конкретной небольшой части, что и комментарии бы сделало полезным источником информации, где реально что-то найти. Очень не хочу обидеть автора, действительно, труд титанический. Просто конструктивное предложение, как этот труд заставить служить людям ещё более эффективно :)
93. for_sale 755 06.05.19 18:28 Сейчас в теме
(92)
И ещё вопрос - как сделать простой цикл проверки? Например, открывается форма, в неё грузится что-то, форма пока не доступна (у элементов через код выключена доступность), через пару секунд всё загрузилось и доступность у элементов появляется. Как можно установить примерно такой цикл:

Пока Истина Цикл
Если у элемента "Имя" доступность = Истина Тогда
Прервать
Иначе
Пауза 1

Как при этом ограничить тело цикла, чтобы следующие строки не считались (или наоборот, считались) продолжением кода в цикле и в разделе Иначе? (т.е. есть ли какой-то аналог директив КонецЦикла и КонецЕсли?)
94. for_sale 755 06.05.19 18:40 Сейчас в теме
Ещё вопрос по принципу разработки шагов.

Шаг полностью создаётся разработчиками или пользователем Ванессы или же есть какие-то служебные операторы (если тогда иначе цикл пока для каждого), и разработка шага - это только разработка проверки условия?

Например, я хочу иметь шаги
1. Если Погода = -30ИСнег Тогда
2. Пока Погода = -30ИСнег Цикл

Мне нужно разработать оба шага в описанном виде или же можно сделать шаг, который будет проверять условие Погода = -30ИСнег, а дальше я просто делаю конструкции
Если <МойШагПроПогоду> Тогда
Пока <МойШагПроПогоду> Цикл
?
95. for_sale 755 06.05.19 18:45 Сейчас в теме
(92)
Отвечаю на свой же вопрос:


3. Простой пример вопросов - у нас в разрабатываемом модуле есть версии. И эти версии выводятся в заголовок окна. Соответственно, если писать сценарий "И я открываю окно ""Обработка в.1""", то завтра этот сценарий надо будет переписать на "И я открываю окно ""Обработка в.2""". Есть ли возможность указывать что-то вроде "Окно, имя которого начинается на "Обработка в."". Если нет, то как это создать?

В параметре, описывающем заголовок формы, можно использовать символы подстановки ? (любой один символ) и * (любая последовательность символов). Т.е. можно написать "Обработка в.*" или "Обработка в.2.?"
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

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

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

Консультант 1С
Нижний Новгород
зарплата до 100 000 руб.
Полный день

Программист стажер 1С
Нижний Новгород
зарплата от 30 000 руб.
Полный день

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