Работать дальше

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

Тестировщик, QA, QC, тестинг Инжинер, софтваре тестинг, это все тестировщик...
Разделения реально нет в СНГ\

>тестировщик сообщает
Именно, в этом и функция

>запускать ли релиз/мерж или отправиться на доработку
А вот это - нет. Вы можете это делать (как может это делать любой участник процесса), в вашей компании даже может считаться, что вы за это отвечаете. Но, еще раз, мысленный эксперимент: собственник бизнеса сказал, что завтра фича должна быть на проде. В этот момент, даже если фича - отстой, она поедет на прод. То есть полномочия не ваши, а делегированные.

и оставаться макакой ?

hh => поиск => QA
hh => поиск => QС

Сравните результаты выдачи, обязанности и т.п.

Иногда есть же)

если верить дарвинистам - много труда сделают из вас человека
а много труда + хитрость жопы мб даже сверхчеловека )

Я уже выше описываю: это не его, это делегированные :)

А, ага

Мб даже Лида😂

Тогда и собственник бизнеса может не решать. А решать будет заказчик. Пришел, кулаком по столу стукнул и сказал: фича в проде или фигу вам, а не деньги

По существующим реалиям - разделения нет, а по сути/определениям - макаки отдельно, бананы отдельно)

карчое я понял надо изучать код

Именно :)

Тогда вообще никто не обеспечивает качество

А зачем вам привязывать два определения к одной сущности? Чтобы просто?

:)
Процессом обеспечения качества занимается вся команда :)

Потому что собственника бизнеса также трясут его пользователи.

Вот только quality assurance - это не "обеспечение", это (за неимением менее корявого варианта) "убеждение в качестве"