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

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

Вас послушать — тестировщик просто Ленин какой-то получается.

n>Т.к. у вас вероятно оно не проводится, а тестирование сводится к тупой проверке работы с интерфейсом, то и тестировщики у вас соответвующие...

Хотелось бы понять, в чём, по вашему мнению, разница между «функциональным тестированием» и «тупой проверкой работы с интерфейсом».

Действительность же такова, что хороших тестировщиков очень мало. В разы — в десятки раз! — меньше, чем хороших программистов. Для «плохих» тестировщиков действует правило «up or out», зачастую используемое в практике консалтинговых компаний: «плохой» тестировщик либо стремится стать программистом, либо будет уволен.

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

Слово «качество» здесь — ключевое. Вот, что вы пишете:

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

Получается, что у программистов есть некие загадочные «свои» задачи, и качество среди этих задач занимает почему-то далеко не лидирующие позиции. Увы, в подавляющем большинстве случаев это именно так: гони на гора строки кода, главное — сроки (успел — премия, не успел — PM виноват). И в первую очередь поэтому неэффективно использование программистов для тестирования продукта.

Следовательно, в команде должен быть человек (или группа), который поставит своей главной целью качество продукта.

n>В любом случае опытом многих и своим доказано что тестирование собственно созданной функциональности мало эффективно. Более эффективно даже обменяться двум программистам функционалом для тестирования.

Вторая причина неэффективности программиста как тестировщика, на мой взгяд, в том, что программист при тестировании будет стараться «сыграть результат». Это такой театральный термин, означающий, что актёр реагирует на событие ещё до того, как оно воспринято зрителем (потому что актёр знает, что это событие обязательно произойдёт и именно в этот момент, и он заранее готов к нему). Программист знает, что делает его код, поэтому играет best case scenario, и, убедившись в его работоспособности, рапортует о том, что тестирование завершено успешно.

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

Здравствуйте, Аноним, Вы писали:

GZ>>Но у пользователя, еще меньше.

А>Связи не понял
Проясню, вчера не было времени дописать.
1. Возьму пример из жизни. При ошибке коннекта через DCOM, пользователю выводится ошибка: "Произошла системная ошибка в процедуре CoCreateInstanceEx". Для любого программиста, это вполне достаточная и главное понятная информация. Однако приходит тестировщик, и говорит что это является ошибкой. Для него, как для пользователя, данная информация не понятна. Программист возражает: "А если я выведу другую ошибку, то я не пойму что произошло". Безусловно, что в данном случае, тестировщик прав, потому что он оценивает ситуацию со стороны потребителя. Это наиболее явный пример.
2. Тестировщик ничего не знает об архитектуре. На моей практике, ошибку выдавало даже переименование окна в ресурсах. Программист, так как знает, что это не должно выдавать ошибку, даже проверять не станет. Для тестировщика эту информацию всегда нужно проверять.

С уважением, Gleb.

Здравствуйте, byur, Вы писали:

B>Идеальность тут не причем. Вариант первый -- если маленькая контора, и ее менеджмент не в состянии решать проблему дефектов софта в силу того, что "лежит под заказчиком с широко раскинутыми ногами", а руководство конторы не имеет планов на будущее и использует контору как возможность заработка первоначального капитала -- а там как кривая выведет . То скорее всего в этом случеа будет наблюдаться "соковыжималка" разработчиков. И видимо именно разработчики будут выспрашивать заказчика "что спрограммировать-то?" и заказчик будет им звонить непосредственно и говорить что нужно доваять, скорее всего у конторы то и скретаря нет. И это не вина разработчика, что он так попал ... а скорее беда. И руководство такой конторы будет вести разговоры, про то что в России "буржуйские" технологии не приживаются, что "они все это 100 раз пробовали", что "русский программист и кашу из топора сварит ..." ... и т.п.

К чему этот весь текст и какое он имеет отношение к нашему обсуждения — я не понимаю.

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

Так....и что?

B>У каждого свой "настоящий" мир ... лично мне описанный мир не очень. В данном случае тимлидер подменяет собой менеджера.

А вот это совсем мимо. Если проект крупный (мой случай) — то у менеджера в подчинении несколько тимов — каждый из которых отвечает за свою команду.

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

Сорри, я твой предыдущий посте не внимательно прочитал. Почему то решил, что ты под техническими решениями архитектуру имеешь ввиду

T>>>>Ну фиг знает. Где как, наверное. У нас — ставят именно программера, в первую очередь. Так что снова не согласен!
B>Согласитесь, вы это еще не весь "мир". Везде по-разному.

То, что я весь мир — я точно не говорил!

T>>Правда, я не совсем корректно выразился, наверное. Я имел ввиду — рабочее тестирование. Тогда — виноват программер. Если после выпуска — то, конечно, доля вины тестера большАя (тут уже, я затруднюсь сказать, кто виноват больше). Зачастую, в самом деле тестер.
B>Да, похоже вы используете термины, которые мне не понятны. Что такое "рабочее тестирование"? Разработчики могут делать юнит-тестирование ... могут проверить работает ли формочка ...

Тут вообще речь не про разработчиков -а про тестеров. Под рабочим тестированием я имею ввиду тестирование _до_ выпуска продукта. Ещё бывает после выпуска — это фидбеки

B>Если у конторы нет денег на тестировщиков -- то нужно договариваться с заказчиками, чтобы они проводят тестирование, в т.ч. и приемочное ... Обычно для малобюджетных проектов это нормальная практика.

Брррр.....Ну мы совсем куда то не туда зашли. Конкретно у нашего проекта тестеры есть. Около 10 человек. У всех остальных 20ти проектов в нашей конторе они тоже есть. Такое ощущение, что мы о разных вещах говорим.

Итак, отбрасывая весь предыдущий флейм вот моя основная мысль:
Использовать разработчиков в качестве тестеров можно. И более того — иногда нужно — в случае если тестеров не хватает или разработчикам временно нечего делать или надо проверить качество тестирования. Да и наверное в других случаях. И зачастую — это даёт хорошие результаты. Речь сейчас не идёт о том, что бы программер после написания очередной строчки кода проверял её — это само собой. Речь о том, что можно выделить несколько дней (или они могут сами выделиться), что бы программеры по спущенному сверху тест-плану (это, кстати, не всегда обязательно) провели тестирование.

Здравствуйте, trial, Вы писали:

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

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

Здравствуйте, cvoronin, Вы писали:

A>>Т.е. по факту человек подделывающий проектную документацию. Замечательно...

A>>По факту проектная документация нужна не чтобы ее "писать" — никто не хочет ее писать.
A>>А чтобы ее использовать(это хотят все и ради это некоторые даже готовы ее писать).
A>>Поэтому write-only документация бесполезна, а для начальства даже вредна.

C>Кто работал в гос. конторе — тот поймет, сколько мусороподобной бумаги приходится оформлять — абсолютно не имеющей отношения к проекту. Например, "Разрешение на эксплуатацию электрического прибора" — дабы поставить чайник, кучу бумаг чтобы заказать расходники и проч.
C>Вот это имелось в виду...

Помоему проще не работать в гос конторах.

Господа, по видимому, RUP — это хорошо, но всё-же каждый подстраивает его под свои нужды и выделяет из него наиболее подходящие, практичные вещи, да и видимо есть альтернативы RUP.
Вопрос вот в чём: кто какие роли использует в ходе проектов ? Понятно, что зависит от проекта, но видимо есть устоявшиеся основные роли. И по возможности процесс взаимодейстия между ними.
Т.е. например: разработчик и тестировщик. Разработчик пишет всю документацию и код, тестер пишет баги и отдаёт разработчику, внедряет отлаженный продукт. А все остальные роли — ненужное разделение труда. Или как-то ещё.
В частности очень интересует тонкий момент рабочего процесса проектирования и его связка с другими, т.е. есть ли некий архитектор, или лид-проектировщик, или ещё как-то и каким образом подобная роль взаимодействует с остальными.
Спасибо.

Здравствуйте, BalTun, Вы писали:

BT>Господа, по видимому, RUP — это хорошо, но всё-же каждый подстраивает его под свои нужды и выделяет из него наиболее подходящие, практичные вещи, да и видимо есть альтернативы RUP.
BT>Вопрос вот в чём: кто какие роли использует в ходе проектов ? Понятно, что зависит от проекта, но видимо есть устоявшиеся основные роли. И по возможности процесс взаимодейстия между ними.
BT>Т.е. например: разработчик и тестировщик. Разработчик пишет всю документацию и код, тестер пишет баги и отдаёт разработчику, внедряет отлаженный продукт. А все остальные роли — ненужное разделение труда. Или как-то ещё.
BT>В частности очень интересует тонкий момент рабочего процесса проектирования и его связка с другими, т.е. есть ли некий архитектор, или лид-проектировщик, или ещё как-то и каким образом подобная роль взаимодействует с остальными.
BT>Спасибо.

Почитайте нативную доку. Там все описано.

Здравствуйте, BalTun, Вы писали:

BT>Вопрос вот в чём: кто какие роли использует в ходе проектов ? Понятно, что зависит от проекта, но видимо есть устоявшиеся основные роли. И по возможности процесс взаимодейстия между ними.

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

S>В проекте должны использоваться все роли, но один человек может сочетать в себе несколько ролей. По RUP не помню, но практика показала, что не все роли могут сочетаться безболезненно в одном человеке. Примером может служить плохое сочетание программиста-кодера и тестировщика.
Что любопытно, в XP приветствуется написание и прогон тестов программистом-кодером

Однозначно можно сказать, что весьма необходимая роль в проекте — администратор. Дабы не отвлекать разработчиков/программеров на написание бумаг, отчетов и прочей ерунды, нужной только начальству.

S>> Примером может служить плохое сочетание программиста-кодера и тестировщика.
c> Что любопытно, в XP приветствуется написание и прогон тестов программистом-кодером

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

Здравствуйте, cvoronin, Вы писали:

S>>В проекте должны использоваться все роли, но один человек может сочетать в себе несколько ролей. По RUP не помню, но практика показала, что не все роли могут сочетаться безболезненно в одном человеке. Примером может служить плохое сочетание программиста-кодера и тестировщика.
C>Что любопытно, в XP приветствуется написание и прогон тестов программистом-кодером
Практика показывает, что человек, который написал программу, не в состоянии корректно оттестировать ее.

C>>Что любопытно, в XP приветствуется написание и прогон тестов программистом-кодером
А>Практика показывает, что человек, который написал программу, не в состоянии корректно оттестировать ее.
XP утверждает, что человек не в состоянии корректно написать программу, не имея для неё тестов

Здравствуйте, cvoronin, Вы писали:

S>>В проекте должны использоваться все роли, но один человек может сочетать в себе несколько ролей. По RUP не помню, но практика показала, что не все роли могут сочетаться безболезненно в одном человеке. Примером может служить плохое сочетание программиста-кодера и тестировщика.
C>Что любопытно, в XP приветствуется написание и прогон тестов программистом-кодером

Не надо путать юнит-тесты, с полноценным приемочным и др. функциональным тестированием.

Здравствуйте, BalTun, Вы писали:

BT>Господа, по видимому, RUP — это хорошо, но всё-же каждый подстраивает его под свои нужды и выделяет из него наиболее подходящие, практичные вещи, да и видимо есть альтернативы RUP.
BT>Вопрос вот в чём: кто какие роли использует в ходе проектов ? Понятно, что зависит от проекта, но видимо есть устоявшиеся основные роли. И по возможности процесс взаимодейстия между ними.
BT>Т.е. например: разработчик и тестировщик. Разработчик пишет всю документацию и код, тестер пишет баги и отдаёт разработчику, внедряет отлаженный продукт. А все остальные роли — ненужное разделение труда. Или как-то ещё.
BT>В частности очень интересует тонкий момент рабочего процесса проектирования и его связка с другими, т.е. есть ли некий архитектор, или лид-проектировщик, или ещё как-то и каким образом подобная роль взаимодействует с остальными.
BT>Спасибо.

Дьявол, как обычно кроется в деталях . Это какую документацию пишет разработчик??? Требования к системе? Не всякий разработчик сможет это сделать хорошо. Если речь о проектной документации (т.е. описание дизайна и архитектуры), то опять-таки смотря что вкладывать в эти понятия. Основная проблема -- волюнтаризм (или просто откровенная безграмотность???) менеджеров проектов или тех кто исполняет их роль, которые не понимают разницу например м/у системной и программной архитектурой и тем более не знают как ее правильно задокументировать. Естетственно если это необходимо для данного конкретного проекта.
Вообще -- все определется целями которыми вы перед собой ставите (использование ролей и прочия). Но разумно не изобретать велосипед, что любят делать многие отечественные менеджеры даже не имя систематизированных знаний о методологиях, а обратиться к накопленному опыту.
Посему подстраивать RUP под свои нужды -- это тоже нужно уметь. Классика, если огрубить, выделяет как минимум роли Менеджера проекта, системного аналитика (или аналитика требований), разработчика, тестера, ну еще про деплоймент можно вспомнить в качестве основных позиций. Очевидно, что фиксировать требования в каком либо виде к системе нужно, при понимании этого -- необходимость роли системного аналитика (или аналитика требований) очевидна. Проектирование ... -- это зависит от проекта. Но как минимум, особенно в отечественной практике, неоправданно большое внимание (IMHO!!!) уделяется проектированию структуры БД (правда это все статическая модель, не понятно как при таком подходе описать бизнес-логику ... но это др. вопрос), так что роль системного аналитика, тоже выходит нужна. Разработка -- ну куда без этого . Тестирование -- это тоже от проекта заваисит. Можно, например, возложить часть тестирования на заказчика. Так что необходимость не всегда очевидна. Про деплоймент молчим.
Да, естетсвенно в некоторых случаях эти рольи может выполнять и один человек (это о совмещении).
Если говорить про agile то там все по-разному. Но дизайн никто не отменяет. XP -- это отдельная песня со своими условиями. Там есть зачатки требований (user story), а недостаток дизайна как тоакового компенсируется постоянным РЕФАКТОРИНГОМ, про это не нужно забыать.

Здравствуйте, Аноним, Вы писали:

сорри, это был я ... забыл залогиниться ...

Здравствуйте, stasukas, Вы писали:

S>Примером может служить плохое сочетание программиста-кодера и тестировщика.

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

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

И выходило это — очень хорошо. Во многом — гораздо продуктивнее тестеров.

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

Но ИМХО основная причина всё же в том, что у некого "среднего" программиста квалификация (общекомпьютерная, что ли) выше, чем у некого "среднего" тестера.

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

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

Здравствуйте, trial, Вы писали:

T>Но ИМХО основная причина всё же в том, что у некого "среднего" программиста квалификация (общекомпьютерная, что ли) выше, чем у некого "среднего" тестера.

Но у пользователя, еще меньше.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, trial, Вы писали:

T>>Но ИМХО основная причина всё же в том, что у некого "среднего" программиста квалификация (общекомпьютерная, что ли) выше, чем у некого "среднего" тестера.

GZ>Но у пользователя, еще меньше.

Связи не понял

Здравствуйте, nixite, Вы писали:

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

А такое бывает??? Это не подколка, ни в коем случае!! Мне в самом деле интерестно. Просто за 6 лет вращения в IT я такого не встречал, к сожалению. Всё что я видел — это тестеров-бывших(будущих) администраторов и тестеров-неудавшихся(будущих) программистов. Или просто случайных людей. Говорить о том, что квалификация у них выше — естественно не приходится. И з/п тоже.

N>Т.к. у вас вероятно оно не проводится, а тестирование сводится к тупой проверке работы с интерфейсом, то и тестировщики у вас соответвующие...

Нет, это не так. У нас, преимущественно, серверные проложения — поэтому про интерфейс там особо говорить не приходится — хотя, его конечно тоже проверяют. И тестирование, по большей части сводится к анализу логов по итогам различных действий. И вот тут — программисты оказываются впереди. Я даже больше скажу — когда "в нормально режиме" тестируют тестеры — зачастую логи приходится разбирать всё равно разработчикам — только они, как авторы досконально знающие свой код могут это сделать (по крайней мере быстрее).
И, честно говоря, я не представляю себе тестировщика который будет на голову выше программиста (может свободно ориентироваться в чужом коде и т.д.). Почему же он остаётся тестировщиком при такой крутизне? З/п? Вряд ли. Тестирование, всё таки, достаточно занудное занятие — обычный программер долго не выдержит (ИМХО). Тут, в соседней ветке как раз обсуждают психологию управления программерами.

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

Нет, нет и ещё раз нет. Программа — понятие растяжимое. И если речь едёт о достаточно крупной программе, в которой много модулей, то ни один человек (ИМНО) не в состоянии написать так, что бы всё разаботало на раз-два. А если этой программе ещё и нужно взаимодействовать с чем-то внешним, что работает само по себе (AD, Exchange, MIIS — да мало ли ещё что) — то ИМХО не возможно с первого раза охватить все тест-кейзы. Бывают такие случаи, что даже в голову не приходят. А они бывают

N>В любом случае опытом многих и своим доказано что тестирование собственно созданной функциональности мало эффективно. Более эффективно даже обменяться двум программистам функционалом для тестирования.

Тоже спорно. Видел множество обратных примеров. Если есть вменяемый тест-план — то может оказаться очень даже нормально. Хотя обменяться функциональностью — тоже полезно, конечно же.

И ещё раз повотрюсь: я не за такой подход. Я лишь против его отвергания. Иногда тестирование силами программистов очень эффективно.

Это был я.

Почему то разлогинился.

Здравствуйте, GlebZ, Вы писали:

GZ>Проясню, вчера не было времени дописать.
GZ>1. Возьму пример из жизни. При ошибке коннекта через DCOM, пользователю выводится ошибка: "Произошла системная ошибка в процедуре CoCreateInstanceEx". Для любого программиста, это вполне достаточная и главное понятная информация. Однако приходит тестировщик, и говорит что это является ошибкой. Для него, как для пользователя, данная информация не понятна. Программист возражает: "А если я выведу другую ошибку, то я не пойму что произошло". Безусловно, что в данном случае, тестировщик прав, потому что он оценивает ситуацию со стороны потребителя. Это наиболее явный пример.

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

GZ>2. Тестировщик ничего не знает об архитектуре. На моей практике, ошибку выдавало даже переименование окна в ресурсах. Программист, так как знает, что это не должно выдавать ошибку, даже проверять не станет. Для тестировщика эту информацию всегда нужно проверять.

Если есть тест-план — то проверит в лучшем виде.

Здравствуйте, trial, Вы писали:

T>Здравствуйте, GlebZ, Вы писали:

GZ>>Проясню, вчера не было времени дописать.
GZ>>1. Возьму пример из жизни. При ошибке коннекта через DCOM, пользователю выводится ошибка: "Произошла системная ошибка в процедуре CoCreateInstanceEx". Для любого программиста, это вполне достаточная и главное понятная информация. Однако приходит тестировщик, и говорит что это является ошибкой. Для него, как для пользователя, данная информация не понятна. Программист возражает: "А если я выведу другую ошибку, то я не пойму что произошло". Безусловно, что в данном случае, тестировщик прав, потому что он оценивает ситуацию со стороны потребителя. Это наиболее явный пример.

T>Тестировщик то прав, но, среди достаточно опытных программеров (по крайней мере в моей текущей команде), я не видел людей, которые бы подобное сообщение сами не сочли ошибкой. Так что ИМХО несколько высосано из пальца.
Это просто самый показательный пример. Другой пример, использовал одну библиотеку к девайсу. Нашел ошибку. Звоню производителю. Отвечает программист. Ответ был такой: "Это не бага, а особенности Windows". После чего, объяснил в чем была особенность при работе через USB и почему библиотека выдает ошибку. Меня, как пользователя данной библиотеки, было сильно наплевать на особенности работы USB. И тестировщику, я думаю тоже.

GZ>>2. Тестировщик ничего не знает об архитектуре. На моей практике, ошибку выдавало даже переименование окна в ресурсах. Программист, так как знает, что это не должно выдавать ошибку, даже проверять не станет. Для тестировщика эту информацию всегда нужно проверять.

T>Если есть тест-план — то проверит в лучшем виде.
Да по указанному в пункте 2 причинам, программист и не вставит данный пункт в тест-план, и не будет сообщать о изменении данной функциональности. Я могу вспомнить до фига случаев, когда простые изменения перед релизом, без согласования, приводили к плачевному результату. С точки зрения программиста некоторое изменение может ему показаться простым. А если продукт делали десятки программистов, то такие изменения (даже внутри опубликованного интерфейса), может привести к плачевным результатам. И в данном случае тестировщик, который даже и не догадывается о внутренней архитектуре программы, незаменим. Ему главное, чтобы все работало. А как его уже мало волнует да и не надо ему знать. И именно поэтому, готовность релиза определяет именно тестировщик а не программист.
В этом правда, есть свои плюсы. За багнутую программу ставят именно тестировщика, а не программиста.
Хотя в этом виноваты оба.

IMHO Все вышеперечисленное, естественно, не касается автоматизированного тестирования и стиля XP.
С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Это просто самый показательный пример. Другой пример, использовал одну библиотеку к девайсу. Нашел ошибку. Звоню производителю. Отвечает программист. Ответ был такой: "Это не бага, а особенности Windows". После чего, объяснил в чем была особенность при работе через USB и почему библиотека выдает ошибку. Меня, как пользователя данной библиотеки, было сильно наплевать на особенности работы USB. И тестировщику, я думаю тоже.

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

T>>Если есть тест-план — то проверит в лучшем виде.
GZ>Да по указанному в пункте 2 причинам, программист и не вставит данный пункт в тест-план, и не будет сообщать о изменении данной функциональности.

А вот тест-план пишет не программист, а его тим-лидер. Так что снова не согласен.

GZ>В этом правда, есть свои плюсы. За багнутую программу ставят именно тестировщика, а не программиста.
GZ>Хотя в этом виноваты оба.

Ну фиг знает. Где как, наверное. У нас — ставят именно программера, в первую очередь. Так что снова не согласен!

Здравствуйте, trial, Вы писали:


T>А вот тест-план пишет не программист, а его тим-лидер. Так что снова не согласен.

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

GZ>>В этом правда, есть свои плюсы. За багнутую программу ставят именно тестировщика, а не программиста.
GZ>>Хотя в этом виноваты оба.

T>Ну фиг знает. Где как, наверное. У нас — ставят именно программера, в первую очередь. Так что снова не согласен!

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

Здравствуйте, byur, Вы писали:

B>Здравствуйте, trial, Вы писали:



T>>Ну фиг знает. Где как, наверное. У нас — ставят именно программера, в первую очередь. Так что снова не согласен!

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

Очевидно, уважаемой trial работает небольшой группой, в которой все административные функции и ответсвенность лежит на одном team-leader.

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

С уважением, Gleb.

Здравствуйте, byur, Вы писали:

B>Я всегда был уверен, что тест планы должен писать Тест-аналитик ... причем на основе требований а задача тимлидера -- отслеживать чтобы софт делали в соответствии с архитектурой, продумывать технические решения ... короче "техническая оптимизация при наличии ограничений".

Про тест-аналитика: и часто встречается такая должность? Я вот не видел. Может в идеале оно так и должно быть, но мы то живём в далеко не идеальном мире. Поэтому тут тест-план будет писать тимлидер (тестеров, а не программистов). Или сам тестер...А тест-аналитик...Это что-то из области фантастики.
А если получается так, что тестировать приходится силами программистов — то соответствено тимлидер программистов.
Больше, увы, некому. Се ля ви.
Про тимлидера: он, прежде всего, должен отвечать за то, что бы его команда работала. Работала хорошо и делала то, что надо. Надо код писать — значит он должен сделать так, что бы его люди писали код. Надо тестировать — должны тестировать. Надо мыть полы — он должен найти способ мотивировать их мыть полы. В кратчайшие сроки и с наилучшим качеством. Если уж подходить формально — то он как раз не должен заниматься продумыванием технических решений — для этого есть архитектор. Вот только в нашем неидеальном (зато настоящем!) мире — это часто один и тот же человек (не везде конечно, но часто).

GZ>>>В этом правда, есть свои плюсы. За багнутую программу ставят именно тестировщика, а не программиста.
GZ>>>Хотя в этом виноваты оба.
T>>Ну фиг знает. Где как, наверное. У нас — ставят именно программера, в первую очередь. Так что снова не согласен!

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

Требуют, что бы он допускал миниму дефектов. Это, кстати, тоже работа тима, во многом. Я кстати, не совсем правильно сказал. Сначала нагнут тима, а потом — если он сам сочтёт нужным — то он нагнёт программера.

Правда, я не совсем корректно выразился, наверное. Я имел ввиду — рабочее тестирование. Тогда — виноват программер. Если после выпуска — то, конечно, доля вины тестера большАя (тут уже, я затруднюсь сказать, кто виноват больше). Зачастую, в самом деле тестер.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, byur, Вы писали:


GZ>Очевидно, уважаемой trial работает небольшой группой, в которой все административные функции и ответсвенность лежит на одном team-leader.

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

GZ>То что, надо ставить именно тестировщика, вопрос как-бы не подлежит обсуждению. Ключевое решение лежит на PM и на группе тестирования.(правда, иногда только в идеале, есть начальники и повыше). Прямая обязанность тестировщика выявить все баги (или их максимум).

Во-во. С этим я не в коем разе не спорю. А прямая обязанность программиста — наплодить как можно меньше багов.

GZ>Однако вопрос, а надо ли при этом программиста обрабатывать?(безусловно, если это не криминальный случай, и он производит софт а не набор ошибок).

Обрабатывать — не знаю. Если человек вменяемый и более-менее ответственный, то я думаю не надо — он и сам поймёт. Если невменяемый и безответственный — то можно и поставить на вид. Правда ему всё равно пофиг будет — на то он и безответственный. Зато будут аргументы при увольнении.

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

Здравствуйте, trial, Вы писали:

T>Здравствуйте, byur, Вы писали:

B>>Я всегда был уверен, что тест планы должен писать Тест-аналитик ... причем на основе требований а задача тимлидера -- отслеживать чтобы софт делали в соответствии с архитектурой, продумывать технические решения ... короче "техническая оптимизация при наличии ограничений".

T>Про тест-аналитика: и часто встречается такая должность? Я вот не видел. Может в идеале оно так и должно быть, но мы то живём в далеко не идеальном мире. Поэтому тут тест-план будет писать тимлидер (тестеров, а не программистов). Или сам тестер...А тест-аналитик...Это что-то из области фантастики.
T>А если получается так, что тестировать приходится силами программистов — то соответствено тимлидер программистов.

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

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


T>Больше, увы, некому. Се ля ви.
T>Про тимлидера: он, прежде всего, должен отвечать за то, что бы его команда работала. Работала хорошо и делала то, что надо. Надо код писать — значит он должен сделать так, что бы его люди писали код. Надо тестировать — должны тестировать. Надо мыть полы — он должен найти способ мотивировать их мыть полы. В кратчайшие сроки и с наилучшим качеством. Если уж подходить формально — то он как раз не должен заниматься продумыванием технических решений — для этого есть архитектор. Вот только в нашем неидеальном (зато настоящем!) мире — это часто один и тот же человек (не везде конечно, но часто).

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

T>>>Ну фиг знает. Где как, наверное. У нас — ставят именно программера, в первую очередь. Так что снова не согласен!

Согласитесь, вы это еще не весь "мир". Везде по-разному.


T>Правда, я не совсем корректно выразился, наверное. Я имел ввиду — рабочее тестирование. Тогда — виноват программер. Если после выпуска — то, конечно, доля вины тестера большАя (тут уже, я затруднюсь сказать, кто виноват больше). Зачастую, в самом деле тестер.

Да, похоже вы используете термины, которые мне не понятны. Что такое "рабочее тестирование"? Разработчики могут делать юнит-тестирование ... могут проверить работает ли формочка ...
Если у конторы нет денег на тестировщиков -- то нужно договариваться с заказчиками, чтобы они проводят тестирование, в т.ч. и приемочное ... Обычно для малобюджетных проектов это нормальная практика.

Здравствуйте, cvoronin, Вы писали:

C>Однозначно можно сказать, что весьма необходимая роль в проекте — администратор. Дабы не отвлекать разработчиков/программеров на написание бумаг, отчетов и прочей ерунды, нужной только начальству.

Т.е. по факту человек подделывающий проектную документацию. Замечательно...

По факту проектная документация нужна не чтобы ее "писать" — никто не хочет ее писать.
А чтобы ее использовать(это хотят все и ради это некоторые даже готовы ее писать).
Поэтому write-only документация бесполезна, а для начальства даже вредна.

A>Т.е. по факту человек подделывающий проектную документацию. Замечательно...

A>По факту проектная документация нужна не чтобы ее "писать" — никто не хочет ее писать.
A>А чтобы ее использовать(это хотят все и ради это некоторые даже готовы ее писать).
A>Поэтому write-only документация бесполезна, а для начальства даже вредна.

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

Здравствуйте, speedballer, Вы писали:


S>Хороший же тестировщик ни в какие программисты не рвётся, его амбиции распространяются на должности менеджера по качеству и директора по качеству.

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

спасибо

Здравствуйте, Dummy, Вы писали:

D> объясните пожалуйста чем отличается менеджер по качеству от директора
D> по качеству. какие обязанности у директора по качеству?

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

Это, конечно, очень общо — но мы же не ставим себе целью здесь разработать должностную инструкцию конкретного директора по качеству конкретной компании.

Или ставим?

Здравствуйте, speedballer, Вы писали:

S>Здравствуйте, Dummy, Вы писали:

D>> объясните пожалуйста чем отличается менеджер по качеству от директора
D>> по качеству. какие обязанности у директора по качеству?

S>Полагаю, что директор по качеству (если таковой имеется) определяет политику компании в области качества, разрабатывает, внедряет и сопровождает процессы, связанные с обеспечением качества, в рамках компании в целом. Руководит (непосредственно или методологически) менеджерами по качеству.

S>Это, конечно, очень общо — но мы же не ставим себе целью здесь разработать должностную инструкцию конкретного директора по качеству конкретной компании.

S>Или ставим?

спасибо, понятно, почему то раньше думал, что всем этим занимается QA Manager

Здравствуйте, cvoronin, Вы писали:

S>>В проекте должны использоваться все роли, но один человек может сочетать в себе несколько ролей. По RUP не помню, но практика показала, что не все роли могут сочетаться безболезненно в одном человеке. Примером может служить плохое сочетание программиста-кодера и тестировщика.

C>Что любопытно, в XP приветствуется написание и прогон тестов программистом-кодером

Это так, но в таком случае (по XP) теста программист должен написать раньше чем начнет кодировать...

Здравствуйте, trial, Вы писали:

T>Не знаю, что говорит теория, и где берутся такие примеры, но вот практика показывает, что такое сочетание далеко не всегда плохое.
T>Мне лично, уже не один раз приходилось руководить тестированием именно программистами — из-за того, что тестеров в данный момент не было или надо было проверить качество их тестирования.
T>И выходило это — очень хорошо. Во многом — гораздо продуктивнее тестеров.
T>Отчасти, это происходило потому что мы лучше ориентируемся в логах нашего продукта — и как следствие можем находить "скрытые" баги — т.е. те, у которых нет моментального проявления на "зрительном" уровне.
T>Но ИМХО основная причина всё же в том, что у некого "среднего" программиста квалификация (общекомпьютерная, что ли) выше, чем у некого "среднего" тестера.
T>Я отнють не говорю, что это классно, правильно и т.д. тестирование силами программистов, как минимум — невыгодно фирме, т.к. получается, что разработчики за свою з/п занимаются трудом, за который обычно платят меньше.
T>Я лишь утверждаю, что при грамотном подходе используя программистов в качестве тестров можно очень многого добиться.

Граматные программисты умеющие и понимающие важность качественного тестирования легко могут протестировать свою разработку, куда лучше чем тестеры.
Однако подход к тестерам как к людям менее грамотным чем программисты — пагубный. Уровень знаний программиста и тестера не должен сильно различатся. Мало того, в крупных западных компаниях з/п программиста и тестера отличаются минимально. А кстати, вы сами пробовали когда-нибудь провести качественное тестирование продукта, да не для заказного, а для коробочного, когда тесты необходимо делать перед каждым релизом? Это безумно сложная задача? Необходимо владеть рядом инструментов для автоматизации, составлять планы тестирования, проверять результаты тестов...
Резюме: Тестер должен быть не менее квалифицирован чем разработчик, а так как разработчики на вес золота, то они иногда должны выполнять тестирование. Но главное не гнушаться этой работы, как делают большенство разработчиков, а подходить к ней как к одной из важнейших частей процесса разработки

Здравствуйте, NickSm, Вы писали:

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

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

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

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