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

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

Да у вас не процесс а процещище 😀

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

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

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

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

Исходя из твоего второго пункта: если есть в старье баг и с обновлением этот баг появляется, то значит с этим багом как-то жили и мирились. Значит надо его обозначить и выпилить тест, так как он постоянно падать будет.

Про предотвращение я не говорил.

Если хочешь услышать про предотвращение, то делается просто: сервак или инстанс с тестовой базой на котором будут гоняться тесты из новой/будущей версии прода

Всем привет посоветуйте что можно почитать про тестирование API мобильных приложений и инструменты мб с примерами

Здесь есть шпаргалка с кучей информации по тестированию API

Спасибо

Всем привет, подскажите фреймворк для тестирования мобайла + веб

Если под мобайлом вы подразумеваете приложения, а не мобильный веб, то:
Selenium/Puppeteer/Cypress на выбор для веба.
Нативные тесты для мобильных.

Меня с фронта перенесли на должность QA, и мне сказали что надо какой-то фреймворк, который сможет тестить клиент на мобайле (Android+IOS), желательно 1 кроссплатформенный. Это я говорю о UI тестах, как пример мне привели APPIum

Возможно я сказал какой-то бред. Сам не знаю. Сегодня только начинаю все изучать

Есть кроссплатформенный аппиум.
Я, честно говоря, не знаю никого, кто бы его использовал и не плакал кровью, но возможно у меня смещённая выборка. :)

Если за последние два года ничего не поменялось, то
-- приложения iOS и Android друг от друга не обязаны зависеть никак, и идеология систем вообще разная (вечно не мог привыкнуть к тому что у айфонов нет аппаратной кнопки "Назад").
-- поэтому какой бы ни был кросс-платформенный "мобильный драйвер", одни и те же вещи могут делаться по-разному, и скорее всего будут.
-- что на практике приводит к тому что даже в рамках одной и той же кодовой базы надо поддерживать два варианта

Выгода от "кросс-платформенного фреймворка" в этом плане теряется, а вот проблемы наоборот, находятся.

Работал я на проекте где была нативная автоматизация, и Аппиум. Нативная -- раз пишешь, потом всё время работает. С аппиумной проблемы были постоянно, чинить то одно то другое могли месяцами. Ни Гугл ни Эппл, если ничего не поменялось, саппортить Аппиум не подписывались.

Подскажи тогда конкретные фремворки для работы с андр и айос

Это лучше у девелоперов на местах спросить с чем им лучше бы работать. Потом они будут подсказывать если что, не я.

У Apple стандартный XCUItest был, но под него меня девелоперы на Objective-C учили писать -- а сейчас уже на Свифт перекатились скорее.

Под Андроид несколько раз встречал отзывы в пользу Espresso (емнип), но самому попробовать пока не довелось.

Ребят, подскажите, плиз,как грамотнее ответить на вопрос эйчара:
"Какие типы интеграционного взаимодействия компонент вы знаете?"