В идеальном мире у всех есть интерес “сделать хороший (тут начинаются интерпретации хорошести) продукт для Клиента”.
Разделение на команды и сферы ответственности порой создаёт организационную политику и люди отчасти забывают зачем они собственно собрались и начинают отстаивать интересы QA, интересы девелоперов,
начинают метрики ради метрик собирать и.т.д =)
Ещё один риск в копилку команды QA
Мне ещё очень нравится как в Spotify это построено
Человек в команде, но в то же время и в отдельном функциональном Chapter ( например QA chapter)
и ещё может в специализированной гильдии учавствовать (например Angular guild, UX guild).
Более хипстерский и клёвый на мой взгляд чем класическая командная организация 
Для короткосрочных проектов тестировщик в команде - думаю более эффективен.
А вод для того чтобы тестировщики не только находили баги но и профессионально развивались - что актуально на долгосрочных проектах - больше подходит команда тестировщиков. В команде возможно шарить знания и планировать обучение. Да и набор и обучение новых сотрудников организовать легче.
Ох, крайне редко тут бываю, плюс читатель, а не писатель.
Но в этот раз пожалуй поделюсь ситуацией в своей конторе - мы продуктовая фирма. CRM|CMS. Я QA-java (автоматизация ест-но). С весны 2013-го. Один. Совсем один-один.
Работаю с командой (больше и нет тестировщиков). Когда приходил, то хотел быть разработчиком, но у руководства оказалось иное мнение, причем уже постфактум, после “мы тебя берем” (впрочем, мне тогда выбирать не приходилось).
Сейчас мутировал до комбайна: css-grid, webpack, smarty, hibernate - все без разницы… по всему спектру веду работы в плане “требуется”->“реализовано” (да и если надо в разработке чем-то помочь или самостоятельно ликвидировать мелкие баги). Было трудно. Да и сейчас не легко. Но без малого уже 5 лет этим занимаюсь.
Так что вполне возможно найти того, кто:
Это всё круто, конечно. Но только лично для вас. А вот для организации такой порядок вещей рано или поздно приведет к коллапсу. Например, вы таки скисните, забьете на все и уедете на острова. Хана бизнес-процессам 
Тут должен быть мой смайлик “рука-лицо”
Не, серьезно, вы и в правду думаете, что уж за 5 лет я не мог бы что-то изменить, если меня тут что-то бы капитально не устраивало?
Ну не “девочко-блондинко” я чтобы “ох, надоело, всем покедова!” - так дела в enterprise не делаются же.
Репутация в моем деле очень важна. Весь код, что в плане “автоматизированного тестирования” лежит в репозитории. Я пишу документацию. Поддерживаю (ну хорошо, стараюсь это делать) её в актуальном виде.
Если бы были на счет меня какие-то сомнения, я уверен, фирма постаралась бы как-то себя ещё подстраховать. Но этого никак не вижу, что, в прочем, не дает мне права как-то фирму шантажировать или просто относиться к делу на “пофиг”. Ибо, “репутация очень важна”.
Ну и да, я за эти годы сросся с основным продуктом фирмы и лично для меня важно, чтобы дела у “продукта” шли хорошо.
P.S. А уехать за бугор уже были возможности - мне Сибирь все же ближе как-то. Не уехал.
Ваша репутация не ставится под сомнение. И с вашей точки зрения все безусловно хорошо.
Но в этой теме вопрос рассматривается с точки зрения организации процессов в команде. И моя речь о том, что такой подход:
категорически не должен приветствоваться. Нельзя выращивать многостаночника и замыкать на нем разные бизнес-процессы. Еще раз - это не выпад лично в ваш адрес, а скорее упрек вашей организации и пример того, как не надо делать.
testomat.io управление авто тестами