по сути у кажой команды есть свое po

*свой

и каждой команды спринты различаются

У каждой команды есть тех эксперты

Плюсом

Это от раз разработки+ тестирования

Есть общие сервисные команды

Со своим циклом

Если идти по тупой, но дорогой схеме, каждая команда разработки делает себе тестовый фреймворк под свой продукт на C++/gtest/или что там в QT есть.
QA пишет что нужно автоматизировать для каждой фичи, автоматизация является частью стоимости фичи, нет автоматизации - нет фичи. Кто пишет тесты будет зависеть он хреновости фреймворка. Если фрейм будет простой и понятный, тесты смогут писать и тестировщики, если нет, то только разработчики.

Все это засовывается в CI/CD, тестировщики смотрять PR на наличие и адекватность тестов.

PyTest выкидываете нафиг.

Это если очень сумбурно про автоматизацию сегодня в 2017-2019 годах.

т.е. лучше писать тесты на нативном для продкта языке?

приложения пишутся на плюсах

Смысл такой: тесты это неотемлимая часть продукта, нет тестов - нет фичи, кто пишет фичи тот и пишет тесты.
Если где то используется в продукте скриптовые языки типа JS, Lua, Python - там можно  или даже нужно писать тесты на нем.

QA в этой схеме анализирует системные проблемы и решает их через автомазиацию.

"и решает их через автомазиацию." - своими силами?

Как хочет или как может, я вот спросил QA lead и Team lead это разные люди или нет, потому что тесты это часть скопа фичи, а скопом управляет Team Lead

QA также смотрит на code coverage, может подтянуть его до приемлемого уровня и контроллировать через CI на каждом PR что он не падает

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

Ок

Олег, так в Плеске?

У мну так