Плюс не совсем понял про оценку трудозатрат по исправлению сценариев. Трудно заранее сказать, какие изменения за собой повлекут небольшие изменения тестов, а какие - большие.

мне кажется, у @krainev есть опасения, что при изменении метаданных (добавили/удалили колонку к регистре) сценарии будут падать из-за того, что полученные данные не сходятся с эталонными (сравнение движений, например)

в общем, насколько тяжело поддерживать эталонные данные в актуальном состоянии

Ну здесь 100% решения в принципе нет, написать и забыть не получится никак.
Мы например, входные данные делаем не импортом, а экспортными сценариями, имхо так устойчивее получается. Но с эталонами движений да, беда, уже сталкивались пару раз.
Тут можно максимально аккуратно писать сами фичи, чтобы проверять не полностью весь макет, а на вхождения строк, чтобы тест не ломался, а просто пропускал новые движения - но тогда встает вопрос к методике и общим задачам тестирования - лично мне кажется, что в такой ситуации тест должен все таки отломаться, т.к. он уже не соответствует поведению, и об этом лучше знать, а не смотреть на стену зеленых лампочек и пребывать в уверенности, что все отлично.
Ну и декомпозиция конечно, чтобы минимизировать копипасту - это главное, присоединюсь.
Правда у нас через СППР, не уверен удобно ли делать сквозные сценарии на чистых фичах, но вроде бы тоже есть люди и с таким подходом.

Переписывать придется огромное количество строк сценариев. Ну, или доходить до не совсем красивых подходов. Пример:
в старой БСП окно печатной формы называлось "Печать документа", в новой БСП по имени объекта ("Реализация ххх"). Приходится переписывать все сценарии, связанные с печатными формами, а их не одна сотня.
Сразу начинают лезть в голову мысли как этого избежать: экспортный сценарий один на это заточить, вместо имени окна использовать только "*" и т.д.
Пока решения красивого не нашли, переписываем каждый сценарий, передавая "привет" разработчикам БСП 👌, и таких исправлений масса на ровном месте (команды вызова отчетов, ввода на основании и пр.)

да, Антон, одно из опасений

Про "входные данные делаем не импортом" можете пояснить, что это?

Экспортный сценарий вида "я жму на смысловую кнопку  "Печать"" )) и  в одном месте исправлять Печать документа , Реализация...

Не грузим данные готовые из заготовок. Т.е. для тестирования перемещения например, остатки вводим не загрузкой из фикстур, а создаем вызовом сценария создания документа ввод остатков.

К своей теме массовой замены. Была мысль базы эталонных движений, откуда экспортировать готовые данные и фичи. Но будет ли выхлоп...

Бывает и подольше цепочки подготовки, зависит от процесса

ага, понял. Спасибо.

Мне такой подход не нравится, от многих других тоже слышал такое же мнение. Но это не  100% - кому то заходит. У всех все по разному, у нас например вообще нет прода, тиражное решение пилим, поэтому даже не думали в эту сторону

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

Делаю авто-инструкцию html
1 Как сделать подсветку кнопки на форме, которую нажимают?
2 Как уменьшить разрешение скриншотов без постобработки. Чтобы скрин сразу делался с нужным разрешением.

1. Эффекты (рамки, стрелочки) делаются также как и для видео инструкций.
2. Этой опции нет.

Для видео инструкций, это использовать сикуликс?

Зависит от типа клиента: если тонкий то SikuliX, если web то VanessaExt + SikuliX (по необходимости)

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

Вообще должен сниматься, но у меня как то не очень это получается, поэтому готовлю отдельно картинки