Ключевой функционал предположим на 200 тестов, предположим это 200 рабочих дней одного автоматизатора

Задача - превратить это в упорядоченный беклог и разбивать на спринты

Или как вы обычно решаете, что конкретно делать и когда?

То есть я и так рассматриваю ключевой важный функционал, что примерно 10% от всего функционала, но и его же тоже достаточно

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

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

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

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

Ну вот у нас тоже это все сделано, все поделено на 16 тест сьюитов, внутри них - тесты разной критичности. Я копаюсь соответственно только с самыми критичными

Несколько основных самых важных workflow уже покрыты, это было в рамках proof of concept автоматизации

Менеджерам это зашло и теперь они ждут бэклог по автомазации

Также они надеются, что это поможет понять, сколько новых автоматизаторов надо привлекать на проект

Опять эффективные менеджеры)?
Ну если некая основа покрыта , то да думаю как подсказал коллега - смотреть по частоте обращений к задаче.  Просто иногда есть минус таких задач — если у вас постоянно переделываются некоторые задачи, то как и исход их автоматизировать можно, но нет смысла.


Можно конечно угореть и выделить задачи по количеству комментариев к ней - но наверное не самое умное решение.

Сейчас не понял. Надо им было доказать что нужна автоматизация? Вау

У нас очень не значительные переделки, продукту 10+ лет, делаем только стабильные мелкие апдейты

Везёт.

Надо брали показать возможности и скорость автоматизации

*было

привет) туплю с сетевыми настройками в докере. есть реальные устройства андроид и айос. подключены по usb к macmini. на macmini баш скриптом поднимается selenium-grid затем регятся в нем устройства с помощью appium.

хотела перевести env в докеры. чтобы разворачивался сам. с докер с appiumом не получилось из-за прокидывания портов от девайса в виртуалку с linux скоре всего из-за  USB-C портов в macmini. хотела хотя бы grid в докер. аппиум регится в grid норм по 'http://localhost:4444/grid/console', а затем тестовый фреймворк запрашивает дейвас у 'http://localhost:4444/grid/console' а в ответ тишина ><  какая-то шляпа с сетью и IP видимо

А почему Фреймворк запрашивает девайс не на localhost:4444/wd/hub?
/grid/console не предназначен для запросов к нему, для этого есть другие эндпоинты

ты прав.
там http://${SELENIUM_GRID_IP}:${SELENIUM_GRID_PORT}/wd/hub
без докера все работает.