Я вам расскажу про среднестатистических тестировщиков. Не про талантливых, а про обыкновенных.

Чтобы тестировщик мог выполнять свою функцию - давать информацию о сборке - надо им обьяснить продукт.
Полезно дать общий обзор архитектуры приложения, чтобы они приблизительно понимали на каком слое ошибка находится. Если им это будет слишком сложно надо брать других тестировщиков. Тестировщики без технического понимания и интереса - это не лучшее вложение.

Если тестировщик никак не проявляет инициативы - тоже плохо.

Спрашиваешь тестировщика:
- Чем ты сегодня занимался?
- Тестировал.
- Что тестировал?
- Все тестировал.

яркий пример того, что тестировщик не понимает, что его продукт - информация. Или ему вообще не обьяснили чего от него хотят. Проблема скорее руководителя.

Если тестировщик не производит информации - он бесполезен.

Еще нельзя тестировщиков сажать в отдельное помещение. В изоляции они будут неэффективно работать.

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

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

Чем чаще вы будете оставлять тестировщика "за бортом" тем менее эффективно он будет работать.

Нужно чтобы тестировщик чувствовал свою отвественность за продукт. Для этого он должен быть частью команды. Чем больше отвестственности вы возложите на тестировщика тем быстрее он вырастет. Будете относиться к нему как к чуваку для мебели - он таким и станет.
Если вы не знаете, что хотите от тестировщика - то он не знает тем более. Разработчик без задания тоже не знает что делать. Нужно поставить тестировщикам задачи. И желательно с письменной отчетностью. Скажу вам сразу это все не так просто, и дополнительная работа для руководителя. Но можно взять тест-менеджера. Он знает как использовать тестировщиков эффективно. Как поставить отчетность и пр.

Еще о предубеждениях.
Часто получается разделение на лагерь разработчиков и тестировщиков - это слышно по лексике употребляемой в общении. Если тестировщик считает, что он должен "сломать продукт", "найти в нем баги", если он думает что он работает "против разработчиков" или если разработчики считают, что работают против тестировщиков - все это нонсенс от которого надо избавляться сразу. Когда клише сложатся - будет поздно. Для этого нужно серьезно относиться к тестировщику и нагрузить его конкретными обязанностями.

Если вы не знаете какие задачи поручить тестировщику - решите этот вопрос в первую очередь.

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

Подведем итог: чем конкретнее задача поставленная тестировщику - тем (внезапно) больше пользы от его работы.

Если вы будете заниматься автоматизированным тестированием вам волей-неволей придется понимать устройство приложения. Хотя бы очень поверхностно. Чем лучше автоматизатор тем лучше его понимание устройства приложения. И тут все зависит от вас, станете вы интересоваться устройством приложения глубже или нет. Требовать от вас этого никто не станет. Будете интересоваться - через какое-то время сможете стать разработчиком.

Если у вы работали ручным тестировщиком - на должность программиста, любой ступени, вас не возьмут.
Если вы работали автоматизатором и знаете профильный язык программирования, то вас могут взять программистом на этом языке программирования, если вы им достаточно уверенно владеете, понимаете шаблоны.

Автоматизатор должен понимать язык на котором он пишет. Он также может понимать как эти тесты выполняются, он может понимать шаблоны проектирования. Он может и должен писать чистый, хорошо поддерживаемый код. Все это ему может в работе понадобиться. Но станет ли это билетом в разработку? Нет, вовсе не обязательно.

У меня сложилось впечатление, что вы хотите через тестирование попасть в разработку. Я бы не стал так делать. Так вы ни хорошим тестировщиком не станете, ни хорошим разработчиком. Я сознательно отказался от работы разработчиком, и остался автоматизатором. Потому что знаю как они работают, и мне иногда грустно. Стать еще одним производителем багов - нет спасибо. А у меня уникальные навыки. Я решаю интересные задачи. Я ковыряюсь в приложении, чтобы понять где к нему прицепиться, чтобы получить нужную информацию. Нормальные интерфейсы, к сожалению, порой не предусмотрены. Я постоянно тусуюсь с разработчиками. Мы обсуждаем баги и я иногда могу подсказать подход к их решению, могу помочь отфутболить баг, или если баг не наш, перенаправить его с нормальным комментарием. Могу зайти в бюро к разработчику и спросить почему баг еще не пофиксили, причем именно техническую причину, и понять ее. Могу прочитать лекцию разработчикам о том, что важно писать внятные коммит-мессаджи. Знаю как пользоваться Джирой. Например трансформировать баг в таск и наоборот. Знаю наши информационные системы. Могу подсказать как с помощью нашего интрумента тестирования продебажить трудно воспроизводимое состояние. Могу читать стектрейс и лог иприложения, и понимая как работает наша программа, обьяснить разработчику, что проблема наша, а не во фреймворке или где-то еще.

Просто я тянусь к знаниям и не считаю себя умным и "все итак знающим".

Можно конечно все время сидеть в бюро и добавлять n+1 тест в тестовый набор у уходить в 17 часов домой. От вас зависит.

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