Возьмите условные:
Смоук
Ассептанс
Регресс
И автоматизируйте переходя от одного к другому
Считайте процент от того, сколько вы проходите на каждом релизе.

100 кейсов на релиз, из них 20 робот проходит.

Из них 5 должны работать всегда. 10 это то что приносит прибыль компании. Ещё 10 мелочевка.
Вот вам надо увеличивать первые 2 набора кейсов в автотестах
(Образно)

Считать теоретически такое можно, конечно, как соотношение ручных и автоматизированных тестов, но полезность этой метрики сомнительна. Автотесты нужны не «чтобы было», а с какой-то целью. Какая у вас цель внедрения автотестов?

Повышение качества продукта :)

Это надо процессы разработки улучшать

Автотесты сами по себе вам продукт не улучшат вообще

чем быстрее принимающие решение люди признаются всем и себе, что цель не "улучшение качества продукта", а "покрытие автотестами", тем меньше ресурсов вы на это потратите 🙂

Ладно, а если переформулировать цель как: "снижение количества обращений от пользователей за счёт лучшего отлова багов на этапе тестирования"

Улучшать тест-дизайн, например.
Писать более качественные требования.
Делать код-ревью.
Анализировать обращения пользователей и пытаться предотвращать подобные проблемы в будущем.

Хах :) Похоже, сейчас так и есть :)

1. Провести трассировку между ТЗ и тестами, которые их покрывают.
Возьмите ваши фичи и определите полноту их покрытия.
Дальше можно извращаться с тест-дизайном сколько влезет.
2. Проговорить с бизнесом что будет у вас являться ключевым и критичным бизнес-функционалом и на что надо делать самый главный фокус и упор (оплата или показ или что там у вас). Эти тесты декомпозировать подробнее.
3. проговорить с тем же бизнесом. что быстро, качественно и дешево не бывает, поэтому надо установить некий порог качества, который бы устроил бизнес по количеству обращений и вас по времени и затратам.
4. Определить цель и стратегию вашей автоматизации. Какую проблему вы ей решаете. Будете ли вы автоматизировать новьё или важнейшее или старьё/регрессию.

И самое главное - пункт 0: какую проблему бизнес пытается решить, придя к вам со своими хотелками.

Ладно, а какие задачи тогда решает автотестирование?

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

Странно, мне казалось, что автотесты просто тестируют намного больше всего, засчет чего повышается эффективность тестов (= нахождение новых багов)

Тем самым меньше багов пройдёт в релиз и вернётся в виде обращений

или сразу на новый функционал. пока все не зелёные дальше не катим.

Нет, автотесты обычно тестируют ровно столько, сколько указано в их алгоритме. В общем случае их вариативность меньше, чем у ручных.

Ага, в идеале бы так

Так вот, результатом этого ведь и является повышение качества продукта? Разве нет?