Сообщений в теме: 73

[innovator]

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

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

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

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

[dlg99]

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

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

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

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

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

- разработчик плохо справится даже с простой задачей для тестировщика пройти тест кейс

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

- дублирование работы негативно скажется на ресурсе времени

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

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

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

- время разработчика стоит дороже

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

[rlabs]

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

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

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

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

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

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

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

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

- разработчик плохо справится даже с простой задачей для тестировщика пройти тест кейс

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

- дублирование работы негативно скажется на ресурсе времени

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

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

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

- время разработчика стоит дороже

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

[Clauster]

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

[SALar]

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

[barancev]

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

[innovator]

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

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

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

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

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

[ShortLegged]

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

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

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

[greesha]

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

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

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

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

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

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

[Clauster]

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

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

[Clauster]

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

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

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

[Boltick]

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

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

[JimR]

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

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

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

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

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

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

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

[Vasiliy]

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

[innovator]

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

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

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

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

[innovator]

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

[barancev]

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

[Boltick]

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

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

[Boltick]

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

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

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

[SALar]

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

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