Автоматизацію тестування нема сенсу робити для короткотривалих проєктів

Якщо ваш

1 senior test automation

інсталить тестовий проект 40годин, то мабуть так, короткотривалі проекти не для вас)).

Якщо ручний регрес займає 3 дні двома працівниками — шанс провмикати більший ніж при автоматизації.

автоматизація окупить витрати і почне приносити чистий прибуток лише на 11-й ⚠️ місяць

Це поки у вас downtime в проді певної функціональності не вимірюється в секундах($x сума в секунду — збитків).
Рахувати витрати-прибуток в людино-годинах дивно.
Якщо ціна помилки, іміджові ризики для кінцевих користувачів нижча ніж людино-години

1 senior test automation

, то для подібного проекту з релізом 1 в 2 тижні краще найняти ще 3 manual QC за ту ж ціну сумарно, і діло в шляпі.

Всю статью прослеживается нотка, что отдел QA — причина бед не частых и обьемных релизов, отсутствия приемлемого coverage, культуры написания unit тестов dev специалистами.

Очень забавная история, каким образом команда QA виновата в отсутствии CI/CD, а главное каким образом отказ от QA команды решил проблему его внедрения))
Опять же если узким местом для позадачного деплоя было регрессионное тестирование(чек того что старый рабочий функционал не ломаем), то кто останавливал автоматизировать этот процесс и избавится от ручного регресса? От отказа QA команды регресс то моментально не пропал))
Кто мешал развивать культуру написания unit тестов dev специалистами? Представляю как QA бубнит «ребята, не пишите тесты, есть же мы, мы и без тестов все сами проверим».

Странно, что недостаточно оптимизированные/автоматизированные процессы в команде слили на QA.
Даже если после отказа от QA «хуже не стало» (не холиварю за то нужна QA команда или нет) , обьяснять достижения о появлении абсолютно нормальных процессов в команде тем что, мы отказались от QA — какие-то странные параллели.