Мне кажется, что если перед программистом поставить задачу что-то тестировать, то в конце концов он сам за автоматизирует этот тест :) Уж такой у них склад характера :)

Ну если хочется формализма, то схема стандартная:
- пишутся требования
- пока программисты кодируют, тестировщики пишут кейсы по требованиям
- когда программисты заканчивают кодирование, проверяют свой код по кейсам которые написали тестировщики
- передача в тестирование

Алексей, обоснование есть! :)
Под тест-кейсами я понимала документ, написанный тестировщиком, по которому он и будет гонять свои тесты.
Я считаю, что каждый должен заниматься своим делом, но при этом болеть за общий положительный результат.
Несколькими постами ранее я говорила о том, что разработчики должны "убирать за собой" - то есть своими средствами проверять то, что они делают (например, те же юнит-тесты, короткий тест типа smoke). Отдавать каждый раз переломанный код - не есть уважение к коллегам по команде.
Что касается смок-тестов, то я бы их все же оставила в распоряжении тестеров (плохо представляю, что разработчик возьмет документ, и по нему будет тестировать).

И еще к разделению обязанностей: мы ведь не задаем вопрос "должен ли тестировщик исправлять баги, которые сделал разработчик (хоть некоторые (IMG:style_emoticons/default/acute.gif) )?"
Тогда почему разработчик должен тестировать вместо тестера/ совместно с ним?

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

Всем большое спасибо за Ваши мнения по этому вопросу.

Не забывайте что эта схема плохо работает. Как минимум потому, что:
- в природе не существует полного набора требований.
- требования часто меняются
- как правило реализация далека от задумки (здесь известная картинка с качелями на дереве)
- и т.д.
В итоге получится так, что будут писаться формальные кейсы, по которым разработчики будут формально пробегаться, а начальнику будет видно как классно используется драгоценное время разработчиков и чуть менее драгоценное тестировщиков.
Я только одного не понял, зачем вы создали эту тему если изначально все для себя решили.

Очень верное замечание. Почему мы действительно не задаём такой вопрос?

Итак, коллеги, хочу задать вопрос: должен ли тестировщик исправлять баги, которые сделал разработчик, ну хотя бы некоторые?

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

Ну, было бы дешевле :)
А вообще, тестеровщик должен тестировать, разработчик разрабатывать.. если в процессе тестирования тестировщиком найден баг, который тестировщик может/знает как исправить, то он может об этом сообщить разработчику, но не исправлять сам. (Вообще в чужой холодильник лезть со своей диетой не стоит), в тоже время, разработчик вполне может взаимодействовать с тестеровщиком, к примеру, на тему написания тест планов. Как пример: Если разработчик считает, что в тест планах надо проверять моменты, которые являются особенностью архетиктуры, то он вполне может написать модель тест кейсов, которые неплохо было бы включить.(Это как один ИЗ примеров)..
К чему я собственно это, вообще между разработчиками и тестеровщиками должно быть взаимодействие(НО не выполнение работы друг друга.), т. к. это все-таки две разные профессии которые на данный момент неотъемлемы друг от друга если как результат нужен хороший софт.

Предположим, что технически такая возможность есть.


Вы совершенно точно уверены, что ЭТО главное? Если тестировщик сам исправит ошибку, он тем самым ещё больше поможет разработчику, разве нет?


Это всё отмазки :)
Потому что верно и обратное -- за то время, когда разработчик будет исправлять дефект, он мог бы реализовать какую-нибудь новую полезную фичу, или исправить другой, более серьёзный дефект. Чего это мы экономим время тестировщика за счёт времени разработчика?

"должен" - я даже говорить боюсь. у некоторых он и думать логически не должен.

если может и хочет, и организация процесса позволяет - то почему бы и нет.

примеры могут быть простыми
1. white box testing или code review, нашел багу, посоветовал фикс. В случае code review вообще иногда сложно найти проблему и не посоветовать фикс.
2. нашел проблему в запущеном приложении, полез в дебагер посмотреть в чем дело, разобрался, фикснул (чтоб девелопера не ждать), проверил дальше, отправил фикс девелоперу на review.
2.1. непонятно поведение приложения, баг не всегда воспроизводится. полез - добавил логгинг, оттестировал, локализовал проблему с помощью логов. Девелоперу уходит баг + набор изменений для логгинга на review.

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

дальше, как я понимаю, можно просто составить список "должностей" (ПМ, VP, тестировщик, девелопер, сисадмин, ...) и "видов деятельности" (тестировать, разрабатывать, думать, ...). Потом получить все сочетания и разобраться с вопросом раз и навсегда ;^)

Точно. Каждый должен заниматься делом, которое у него лучше получается. Ведь, чтобы "грамотно" исправить ошибку, надо знать все тонкости, фичи программной реализации. Вероятность того, что исправив код в одном месте, из-за этого не сломается что-то в другом у тестировщика ниже чем у программиста. А кто это знает лучше чем сам автор кода (он же программист) ? - никто.

Все же главное для программиста, чтоб тестировщик как можно более подробно описал причину ошибки или максимально подробно способ ее воспроизведения.

Это очень идеализированное представление о программистах :)
Ладно, если это совсем свежая ошибка, я с Вами соглашусь, действительно разработчик ещё по горячим следам всё помнит.
А вы пробовали читать свой код, написанный несколько месяцев или хуже того пару лет тому назад? Да вы его просто не узнаете :)
А бывает ещё ситуация, когда разработчик, который писал какой-то фрагмент кода уже уволился или работает в другом проекте и недоступен для исправления дефекта. И тогда все в равном положении, всем этот код чужой.


Ну хорошо, пусть для программиста это главное, хотя и это спорный вопрос.
А для менеджера? Если помощь в исправлении дефектов со стороны тестировщиков поможет ускорить выпуск продукта, он это оценит по достоинству и даст премии всем :)
А для заказчика? Да ему пофиг вообще, кто из вас исправил этот дефект! Он про него вообще никогда не узнает.

изначально не было это решено, и вопрос был не риторическим

Мы говорим о ролях или о людях?
Встречный вопрос: должен ли менеджер проекта выполнять тест-кейсы?
И должен ли он исправлять найденные баги (хотя бы некоторые), если у него есть такая возможность?

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

Это старообрядческий подход. Типа "не лезь не в свое дело" с одной стороны и "это не моя работа" с другой стороны. Я бы ещё наверное назвал его совковым. Хотя даже в том же совке придумали понятие коллектива. Если все в команде так будут думать, стоящих результатов им никогда не добиться.

Резюмируя процитирую Канера: beware of the not-my-job theory in testing. Это высказывание также справедливо и для разработки, менеджмента и пр.

Само собой, что любой руководитель мечтает о команде супер опытных продвинутых профессионалов в нескольких областях, отсюда и возникает стремление выдавать как можно больше разной работы одному специалисту(код, тесты, планы, отчеты и прочее). Ситуация, когда один человек выполняет несколько ролей, не редкость. А вот ситуация, когда эти с исполнением этих всех ролей справляются успешно, скорее исключение, чем правило. Но оно же забавнее все подтвердить на собственном опыте, как в случае с моим руководством.

Вы, наверное, неправильно поняли. Я не считаю и не писал, что "это не моя работа". Я лишь считаю, что не все тестировщики обладают необходимой квалификацией для исправления кода. Программисты сделают это быстрее и качественнее, даже если ошибка проста и очевидна на первый взгляд, и можно исправить код самому. А бросаться на те ошибки которые "я могу исправить", а те, которые "не могу" и оставлю ее программистам - не стоит. Если бы все было так просто, то зачем тогда отдельно отдел тестирования? Хватит и программистов: один пишет код; другой делает ревью и исправляет найденные ошибки! Мой подход в другом - у кого хватает опыта и квалификации тот и должен заниматься этим. К тому же изначально было условие "если программист занят, а у тестировщика есть свободное время". Я, из личного опыта, такого еще ни разу не видел. А вы? Даже если время тестировщика стоит меньше чем программиста это не повод чтоб данным тип работ передавать тестировщику, это может потом вылиться в сумму "более ощютимую" чем стоимость часов работы программиста.

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


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

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


Я видел такое много раз -- тестировщики ждут, а релиз на тестирование всё не выкатывают и не выкатывают. Неужели правда у вас такого не бывало?


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