здравствуйте, коллеги!
возник такой вопрос при обсуждении разделения труда: должен ли программист тестировать и как?

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

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

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

у нас все просто - он не должен, он обязан тестировать.
юнит тесты + по базовым юзкейзам пробежаться.

Как иначе девелопер узнает о том, что вместо полезной фичи он просто все разломал? через более длинную итерацию с тест-командой?



просто не уловил мысли



как он програмировать-то научился?



во всем нужна умеренность, а то, как известно, и лоб расшибить можно



аргументация молодых лентяев.
__как__ он узнает, что хоть-что-то полезное сделал? зачем ему итерации по 1 дню, если можно за 20 минут это самому понять?
Заодно, это стимулирует юнит тесты писать, тест-хуки добавлять.



аргумент на уровне предыдущего. Я не потрачу 30 мин на тест, но тест-команда потратит 3 раза по часу + час на troubleshooting, + все потратят полчаса на обсуждение и перетаскование бага из одного статуса в другой. такая вот экономия.
хороший девелопер заинтересован в конечном результате.
если не нравится тестировать руками - помогите автоматизировать, добавьте нужные интерфейсы.
Качество - ответственность команды.

Разумеется, не должен.
Хороший разработчик будет тестировать сам, а посредственный просто не сможет, как ни заставляй.


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


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


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


Нужно использовать сильные стороны. Разработчик может придумать, как сделать тестирование быстрее и проще. А с покрытием, вариациями и прочими деталями ему может помочь тестировщик. Симбиоз!


Не надо дублировать работу. Тестировщик не найдет проблемы, которые обнаружит модульное тестирование. И наоборот.


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


В общем случае - урбанистическая легенда.

ощущение, что это провокация

Коллеги. Ну, напишите что ли статью на эту тему. Паттерны применимости с ограничениями.

Провокация? Вот вам ещё, свеженькая заметка Виктора Ронина: http://victorronin.com/2009/01/15/programmist-vs-qc

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

к сожалению, не на просторах СНГ.

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

Возможно, тест будет выполнен быстрее, но скорее всего feedback о состоянии продукта разработчик получит гораздо позже. Об этом уже писали.

Наверное проходить по всем тест-кейсам и не нужно, но если попробовать юнит-тесты и сontinuous integration в связке со smoke test, то это будет полезно.

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

Вот, например, одно такое мнение.



Эрик Синк, "Бизнес для программистов. Как начать своё дело"

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

Поясните, а чем просторы СНГ отличаются от других? Там квалификация тестеров выше или у них зарплата с разработчиками одинаковая?
Не судите по себе о всех остальных.

Тестирование со стороны разработчиков не ограничивается только Юнит тестами. Есть также Integration & System тесты. Ну и вообще, как правило хорошего тона для разработчика должно быть не просто написание кода, проверка Unit, Integration и System тестов, но и ручной тест того, что они "наколбасили" перед выкатом, хотя бы на своей девелоперской платформе... Т.е. они, по-хорошему, должны провести свой Smoke тест до того как отдадут версию в тестирование.

Конечно, не все это делают... именно поэтому и появляются топики такого плана.

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

Лет 7 где-то назад тестировал я изменения в продукте, которые затрагивали печатную форму типа квитанции или чего-то подобного, составленную в Cristall Report.

Так вот: там второе слово в одном из названий не помещалось в длину и обрезалось.

Я завёл багу. Через день пришло исправление.
Как думаете, как выглядело новое изменение?

Слова теперь писались в две строки и обрезались оба: одно сверху, второе снизу.

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

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

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

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

с юнит тестами это понятно, что ими занят разработчик. про автотесты речи нет.
более конкретный вопрос: должен ли разработчик проводить ручное тестирование с использованием тест кейсов? если да, то в каком объеме?

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

ИМХО. Проверять он должен лишь плоды своего труда. А вот тест кейсы проходить это уже дело тестера.

Думаю, что так должен был выглядеть первоначальный пост :)

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

Алексей! Ты читаешь статьи Виктора?! Может ты еще и рекомендовать их начнешь?!
Да,... Ну от тебя то я этого не ожидал ;-).