Ну что ж, теперь давайте попробуем разобраться с автотестами. Тут, наверное, я бы тоже отметил две вещи. Первая - прежде чем написать автотесты, надо ещё понять, что в них надо протестировать. И здесь нам, вообще-то, снова нужен QA-инженер такой же, который может проверить руками и создать нам базу знаний про тест-кейсы. Потому что одно дело сказать, что что-то покрыто автотестами, а другое дело иметь возможность понять, какие сценарии, какими тестами покрыты. Т.е. опять же хорошо автоматизировать тестирование без QA-инженера невозможно. Да, возможно он не должен постоянно прокликивать всё руками, но он точно нужен для того, чтобы консультровать команду по тест-кейсам.

И тут мы переходим ко второй вещи - границы применимости автотестов. Я видел отлично покрытые автотестами SDK. Более того, я считаю, что делать хороший SDK без очень плотного покрытия автотестами невозможно. Я видел неплохо покрытые автотестами API. Особенно, когда они были статичными и редко менялись. Я почти никогда не видел хорошо покрытые тестами интерфейсы. И я также почти никогда не видел покрытые автотестами сценарии взаимодействия нескольких независимых систем. И вот это, пожалуй, самая сложная история. Когда мы говорим про автотесты, то чаще всего они хорошо покрывают очень ограниченный скоуп, а не продукт целиком. Да, действительно, сочетание автотестов и постепенной раскатки может заменить собой сложные интеграционные тесты - бизнес-показатели не упали, значит всё ok. Правда, это своеобразное перекладывание нагрузки с QA на девопсов, аналитиков и кого-нибудь ещё, но, скорее всего вам все равно и такая система деплоя, и такая аналитика нужна ещё и для других целей. Но, не забываем, что для того, чтобы у вас были хорошие автотесты, вам все равно нужен QA-инженер и, возможно, ещё и QA-автоматизатор, который поможет развернуть систему автотестов или проконсультирует о применимости тех или иных подходов в каждом конкретном случае.

Что мы получаем в сухом остатке? Мне кажется странным считать, что можно обойтись без выделенной роли QA-инженера, потому что это человек и с компетенциями и с персональными качествами отличающимися от тех, которые есть у других людей в команде. А вот что мне кажется очень полезным - это максимально плотное вовлечение QA-инженеров в продуктовый процесс. QA - это клей клиентского и инженерного. Он агрегирует в себе всё, что видит пользователь и то, что знает только команда разработки. Чем раньше вы привлечёте его к работе над требованиями, тем больше корнер-кейсов получите, тем больше контекста для принятия решений об уровне критичности багов у него будет, тем лучшие тест-кейсы у вас будут к моменту, когда придётся решать, что из них надо автоматизировать, а что можно раз в какое-то время протыкать руками.

Ну и ещё одна мысль, которая следует из предыдущего абзаца. Я её довольно часто повторяю, но она для многих звучит неожиданно. Если вы пришли в команду продукта на роль менеджера (почти не важно какого), всё уже построено и настроено до вас и вам надо разобраться с тем, как продукт и команда работает, попробуйте начать знакомство с QA. QA должны знать про продукт больше всех. Спросите, как понять какие есть тест-кейсы, в какие скоупы тестирования они входят и почему, какие проверки автоматизированы и что нужно проверить, чтобы выкатить хотфикс. Ответы на все эти вопросы вам очень пригодятся в самые неожиданные моменты. А отстутвие ответов может подсветить вам на чем действительно важно сфокусироваться.