У меня сейчас в проекте есть именно девелопер, который выполняет роль тестера - отлично вписался в команду, я почувствовал такой баланс!
Слава, он больше не девелопер, теперь он -- тестер
Лучше говорить, что вы взяли в команду программиста, который раньше был девелопером, а теперь стал тестером. Программист -- это профессия, специальность, а девелопер и тестер -- это роли.
Задам такой вопрос - что существеннее для качества проекта (при этом не суть - аутсорсинговый он или любой другой): анализ требований и поиск несоответствия в логике или же функциональное несоотвествие кода требованиям? Например, по стоимости внесения изменений?
Это вопрос не по теме, или по крайней мере уведет далеко в сторону. Но отвечу -- по стоимости изменений существеннее те деятельности, которые раньше в цикле разработки, поэтому они влияют на большее количество других. Конечно же, ошибки анализа и проектирования дороже обходятся. Ну вот пусть аналитики и въезжают в предметную область
(не забываем, аналитик -- роль, её вполне может играть тот же человек, что и роль тестера, а может и другой).
Что видится мне: если проект ведётся внутри компании целиком и не столь важно, аутсорсится оно или же нет - то я бы сдвигал приоритет в предметную область и использовал модель подключения ресурсов девелопмента. Тут, как по мне, от тестера требуется больше аналитических способностей, нежели знаний языка или технологии. Если же у вас аутсорсинговый проект именно по тестированию и задача №1 - верификация требований к функционалу, да - сдвиг в сторону задач автоматизации очевиден (если только не аутсорсится, дейтсивтельно, что-то редкое - юзабилити, etc).
Слава, Вы к девелоперам относитесь как к подсобной рабочей силе, нужно попрограммировать -- а ну, давайте позовем кого-нибудь кто умеет. Но это отрывает их от основной работы, понимаете? Я бы предложил рассмотрел другую модель, когда участники проекта не находятся постоянно в одной роли, а иногда играют "чужую" роль. Например, программист четыре дня в разработке -- и день в парном тестировании, в роли "второго тестера". Или тестировщику передается какой-то готовый модуль на полное сопровождение -- сам нашел ошибку, сам и исправляй. И чтобы это всё было учтено в плане проекта, чтобы тестировщики не отрывали разработчиков от работы в авральном порядке, и не просили их "сделать им маленькую штучку после работы".
Что касается автоматизации, я вообще никогда бы не рискнул давать такое задание человеку, не умеющему программировать. Ну, запишет он тестовые последовательности. А через два дня программисты поменяют название диалога или в визарде два шага местами переставят, или ещё что-то сделают -- и тесты работать перестанут. Тогда он должен пойти и поправить код, это не должно вызывать у человека проблем, ни технических, ни психологических. Иначе -- пусть тестирует вручную, это тоже кому-то нужно делать.
