"Есть определённый объём работ по программированию, который надо выполнить" - как определить, что объем работ выполнен? то есть критерий передачи кода в тестирование? мой руководитель предлагает использовать ручное тестирование силами разработчиков для определения завершенности их работы.
увольнять никто никого не будет :) разработчики люди покладистые и готовы пойти навстречу.

Читаю. Рекомендовать не начну. Но вы же хотели провокацию, а? :)

Почему слабо, вы утверждаете что на просторах СНГ время разработчика дороже чем тестировщика. И это обсуждение одного из ваших тезисов.
Я не зря про зарплату спросил, вы заблуждаетесь, когда оцениваете время разработчиков и тестировщиков на сайтах с вакансиями. С другой стороны смысл сравнивать есть только в отдельно взятой компании. Очевидно, что у вас в компании время тестировщиков ценится ниже разработчиков. Я бы вам рекомендовал стремиться нивелировать эту разницу.
Ну и ещё, к теме зарплат, за рубежом тестировщики тоже меньше разработчиков получают. Зайдите на любой сайт с вакансиями и сравните.

Так для этого мнения есть вполне определенная область применения :-)

Мне кажется, что здесь какое-то противоречие :-)

А по сути, отличия "там" тоже есть, но не такие разительные как "здесь".
Возможно по этой причине "два в одном флаконе" там экономически обоснованы.

Я передумал. Рекомендую почитать :) Но не столько саму статью, сколько комментарии к ней.

Ага, вот Вы что имеете в виду. Тестирование разработчиком как способ определения того, что система в достаточной степени завершена/стабильна и может быть передана в тестирование. Давайте рассмотрим этот аспект.

Итак, у нас есть разработка и тестирование, и мы хотим между ними вставить некую деятельность, которую можно условно назвать "приёмка в тестирование". Кто её должен делать? Кто-то должен. Главное, чтобы человек обладал достаточной квалификацией.

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

В чём же тогда может быть различие, кого выбрать -- разработчика или тестировщика? Это зависит от конкретной ситуации.

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

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

Верно. Но далеко не все компании большие. Я бы даже сказал, что их меньшинство, причём самые успешные из них тоже когда-то были маленькими.

Жёсткое разделение труда, возможно, имеет смысл при идеально поставленном процессе разработки. Но где вы его видели, этот идеальный процесс?

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

С помощью тест-кейсов, которые написал тестировщик?
Нет, нет, и еще раз - нет!

Во-первых это немного противоречит предыдущему посту про смоки-тесты (их тоже вполне могли написать тестировщики).
А во-вторых -- почему всё-таки нет? Есть обоснование? Или просто "нет и всё"? :)

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

Универсального ответа нет. Поделитесь секретом, расскажите, какого рода приложения вы разрабатываете.

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

1-3 человека? Значит к ним ещё один тестировщик прилагается. И они не могут договориться? Не смешите меня! Зачем вам формальные критерии?

1. Автоматизируйте процесс сборки (компиляция, выполнение юнит-тестов)
2. Автоматизируйте установку (если десктопные приложения) или деплоймент (если web-based)
3. Автоматизируйте 5-10 тестов, которые проверяют 5-10 основных сценариев, только основу, без отклонений.

Всё.

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

к сожалению, автотесты не планируются в ближайшем будущем

Я вас уверяю, программисты лучше согласятся один раз автоматизировать, чем каждый раз вручную проверять по чек-листу. Такой у них склад характера :)
Я же не предлагаю всё автоматизировать -- только то, что вы собирались включить в чек-лист.

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

В любом случае должна быть практика выдачи/приема новых версий, которая будет принята и будет соблюдаться всеми участниками проекта.