Kull DamnedПМ отвечает за весь проект и если что-то идет не так - виноват ПМ. Программер отвечает за ту часть проекта, которую ведет он и если эта часть не интегряется с другими либо косячит - опять же парят мозги программеру. Таким образом эти люди - залог того, что проект будет сделан вообще. Тестер отвечает за то, чтобы проект создавался в соответствии с требованиями к этому проекту, т.е. степень влияния на проект ниже чем у других.
Вцелом согласен. Добавлю.

1. Исправление ошибки на уровне тестера стоит куда больше, чем еще на уровне программиста. Исключения бывают, но редко. Например, типичные изменения в сотне изолированных мест, было 100 разных кусков кода - стал один, просто его надо звать десятком разных методов, проверять все методы сначала программистом, потом тестером полностью дважды - слишком дорого, в этом случае дешевле программисту убедиться, что в принципе оно работает и не более, а все 100 разных вызовов уже только тестеру проверять, если будут незначительные ошибки, их исправление займет меньше времени, чем первоначальное тестирование программистом всего, что он сделал.

2. Влияние тестера и кодера на продукт в целом с точки зрения определения архитектуры и требований тождественно равно нулю. Ибо если тестер сегодня тестит, а завтра пишет спецификацию на доработку и едет к заказчику, то он уже не как тестер едет, а просто совмещает (официально или нет - неважно) две и более роли в проекте. Проекты, когда за неделю из-за ошибки в проектировании надо все переделывать я в расчет не беру.

3. Задача тестера однозначно стоит в требовании соответствия продукта заявленным требованиям (качествам). Тестер может искать баги, но баги в смысле несоответствия продукта требованиям к нему. Если сказано в требовании, что система не должна позволять вводить в номенклатурный справочник позицию с кодом "А" и при вводе такой позиции возникает AV и позиция не вводится - продукт удовлетворяет явно определенным требованиям, но не требованиям usability. В этом смысле, не все требования явно формулируются, но тем не менее, это требования и ничего больше. Из этого с необходимостью следует, что проверки своего (или соседнего программиста) труда запросто может выполнять (опять же с редкими исключениями) программист, если ему написать все требования, а он будет идти по бумажке и ставить галочки (или аналогично, запускать тулзы, смотреть отчеты и т.п.). Поэтому ничего удивительного, что ставка тестера в общем случае ниже ставки программиста. Бывают ситуации, связанные с опытом работы, знанием нормативно-правовой базы и т.п., если тестер по совместительству и аналитик и поддержкой занимается, но вообще говоря как вид деятельности тестирование дешевле программирования, консультирования, планирования архитектуры, поддержки и других видов деятельности.

4. Нельзя путать руководителя отдела тестирования и тестера. Руководитель не только тестированием занимается. А в нормальных ситуациях - даже и не столько тестированием, сколько именно руководством.

По теме топика - ИМХО - стоит идти, только если будет отдел не только тестированием, но и поддержкой, сопровождением и консультированием заниматься, да еще и обязательно производить рецензирование (читай, тестирование) всех спецификаций на доработку. Если нет, очень велика вероятность описанного выше отношения типа игнорирования. Просто деятельность в целом в проекте реально не будет играть весомой роли, чтобы влиять на сроки, объемы и проект в целом.