Заменят ли автоматизаторы ручных тестировщиков

Поддержка автотестов занимает просто колоссальное количество времени

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

Почему же ручные тестировщики не могут быть в полном объеме заменены автотестами?

По той же причине почему шуруповерт не вытеснил из продажи отвертки. У них разные задачи.

вряд ли заменят, но на дуде игрец требуется уже в двух вакансиях из трех, мануал а требования знания языка лови, и в тестовом задании автотест или скрипт напиши

Вы посмотрели на автотесты с позиции конкретно вашего проекта, вашей инфраструктуры.

Теперь берем другой момент. Крупное приложение, множество зависимостей, которые сложно уже описать. Изменение какой-либо мелочи может аукнуться в старых проверенных местах, надо все перетестить.
100 разработчиков, каждый делает хотя бы парочку коммитов в день, в идеале хочет хотя бы раз в день прогнать интеграционные тесты на своем пулл реквесте, а то и на двух-трех-пяти.

Сколько нужно ручных тестировщиков, чтобы прогнать все тесты для 100 разработчиков в день?

А ПРАВИЛЬНО сделанные автотесты могут это делать без проблем.

Да, их надо поддерживать. Да, для прогона автотестов нужны ресурсы и время. И грамотно все это настроить для минимизации и ресурсов и времени.

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

Уже отсюда и исходить как и где покрывать, как их писать.

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

За час рабочего времени могут дернуть все — ПМ, разработчик, аналитик и прочие

Возможно, проблема обретается где-то здесь, а автотесты не виноваты. Но это не точно.

Будет не лишним упомянуть "проблему оракулов". Если кратко, ее суть в том, что в тестах тоже бывают ошибки, и абсолютно корректный тест может быть сложнее тестируемого кода. Перефразируя древнеримское изречение, кто будет тестировать сами тесты?

Написать автотест гораздо проще и быстрее, чем искать неточность в уже написанном

Смотря, как написаны автотесты. Если по коду теста сложно понять, что пошло не так, то следует «посмотреть в глаза» автору такого автотеста.

Переключаться с автотестов на другие задачи приходилось очень часто. За час рабочего времени могут дернуть все — ПМ, разработчик, аналитик и прочие. После консультаций приходилось заново вливаться в разработку автотеста, что так же крадет ценное время.

Позволить отвлекать себя может только Senior, который может легко переключаться между контекстами. В любом случае — это не проблема автотестов.

автотест способен проверить только конкретные значения

Почему вы так решили? Автотест может проверить все возможные значения, заданные или случайные. Ровно также себя ведёт и ручной тестировщик.

Почему же ручные тестировщики не могут быть в полном объеме заменены автотестами?

По одной простой причине. Это разные сущности. Суть автоматизатора автоматизировать регулярно воспроизводимый сценарий. Ручной тестировщик при этом должен уметь исследовать причину появления ошибок / падения приложения.

Автотест делает POST /users. Ожидает 200, получает 500. Его задача отрапортовать об этом и не более того.

Когда у ручного тестировщика получается поймать пятисотую, то он должен пройтись по всем логам, посмотреть в код, если умеет, найти и понять причину ошибку, предложить варианты её исправления и завести задачу в Jira.

Он (или она) в свою очередь правят автотест или подписывают его ошибкой

А какое ПО для этого используете? Что у вас за отчеты, которые линкуются с ошибками?

Мне кажется, тут ключевая проблема в некорректном менеджменте: а давайте уберем автоматизатора, а ручных тестировщиков оставим как есть, по сути - нагрузим работу автоматизатора на тестера не увеличивая количество тестеров. Гениальная идея, денег сэкономим.
То что смена контекста сжирает до 70% продуктивности - это мелочи.

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

"Скорость написания самих автотестов оставляла желать лучшего. Круг замкнулся — Из-за поддержки автотестов не хватало времени на прямые обязанности"

Не хватило скилла. Бывает. Train hard - go pro. No pain - no gain. Пилякать автоматизацию ради автоматизации вообще тупая идея. Автотесты - это такой же инструмент тестировщика как постман или джира. Просто инструменты использовать надо по назначению и по инструкции. Можно ли топором копать яму? - можно. Можно ли лопатой рубить деревья? Можно. Можно даже научится очень круто рубить лопатой, но может все-таки посмотреть что и в какой ситуации удобнее?

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

Называть "ручными" - в целом пренебрежительно, и это какое-то клеймо, ограничение, придуманное руководством компании.