С удовольствием почитал бы ответы про тест-менеджмент, а комментарии что-то не по теме...)

Аналитики не может оценить риск? Вот и смотрите сколько раз сработал тест вашего тестировщика и умножайте на убыток и среднее время реакции вашими операционнистами их время переключения окружений и т.д. например можно так. А менеджер вообще занят распределением задачек какое он отношение к предмету тестирования имеет. Знай не пересекай задачи, помогай с зависонами и организуй встречи. 🤝

На стороне заказчика легко проследить. Особенно, когда разработка у вас на субподряде. Тестирование становится для вас белым пятном - вы не получаете доступ к актуальным планам, отчетам о проведенном тестировании; сущности проработаны, но вы не знаете, тестировались ли они, и какой был результат. Как вишенка на торте - если вам необходимо пройти сертификацию ФСТЭК и подтвердить, что ПО разрабатывалось по ГОСТ 56939 (безопасная разработка), то вы потратите уйму сил на доказательство того, что каждый тип тестирования проводился в соответствии с требованиями и по нему имеется вся необходимая документация.

Если говорить про менеджера (руководителя), то у него всегда верхнеуровневые kpi. Т.е. по сути вот большая задача, он как руководитель разбил ее на подзадачи среди своих работников, на выходе смотрим чего получилось. Сколько в проде багов по итогу, что выполнено, а что не очень, учел ли какие-то входящие изменения от смежников и вот это вот все.

А если тестировщик А нашел 10 мелких багов в UI на каком-нибудь айфон 7, а тестировщик Б нашел 1 баг, который очень неочевидный и мешает пройти регистрацию или пройти какой-нибудь главный процесс (например, оформление заказа), то это будет все равно означать, что тестировщик А принес больше пользы?