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

[Boltick]

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

Всё.

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

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

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

[Clauster]

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

[yamayka80]

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

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

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

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

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

[innovator]

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

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

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

[Clauster]

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

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

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

[barancev]

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

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

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

[Tuchka_84]

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

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

[Bars Master]

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

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

[barancev]

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

Тут тогда другой вопрос а если у него и доступа нет? Нет вижуалки и т.д.

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

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

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

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

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

[dlg99]

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

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

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

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

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

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

[Pryanik]

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

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

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

[barancev]

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

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

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

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

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

[innovator]

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

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

[greesha]

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

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

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

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

[barancev]

Мы говорим о ролях или о людях?

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

[Clauster]

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

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

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

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

[innovator]

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

[Pryanik]

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

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

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

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

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

[Pryanik]

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

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

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

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

[barancev]

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

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

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

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

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

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