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

[P_R]

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

1. поле психики отдельной личности (тестировщика),

2. поле взаимодействия психик двух личностей (тестировщик-разработчик, тестировщик - PM или TPM),

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

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

[rlabs]

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

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

[Galina]

Согласна с rlabs.

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

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

[Case]

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

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

[NLord]

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

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

Очень притянуто. Стороны занимают различные позиции в вопросах"как" и "что".

"К чему может привести постоянный поиск чужых ошибок, неточностей и пр.?. " - к изменению собственной психики прежде всего, изменению системы ценностей и приоритетов.


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

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

[rlabs]

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

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

И тем не менее, можно пару-тройку примеров противоречий?

[YuP]

Не знаю, как у вас, но в нашей компании место конфликту между тестировщиками и разработчиками есть.

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

Так что учитывать психологические аспекты просто необходимо. И они не простые.

[greyver]

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

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

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

И не будет, если эффективно работает только тестирование.

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

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

Так что учитывать психологические аспекты просто необходимо. И они не простые.

Не могу не согласиться. Необходимо!

[rlabs]

Не знаю, как у вас, но в нашей компании место конфликту между тестировщиками и разработчиками есть.

Это у вас не конфликт, это у вас отсутствие управления.

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

Вот он, книжный пример "как делать нельзя". *Никогда* так не поступайте, ибо вы наносите продукту еще больший удар. Максимум ценности группа тестирования приносит в виде объективной информации о продукте. Искажать информацию - чистый криминал.

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

Добейтесь с разработчиками единого понимания цели работы. Продукт не разрабатывается "просто так", а готовится к очередному релизу. У каждого релиза есть свои цели: выпуск новой функциональности (feature release), исправление ошибок (maintenance). Когда есть много ошибок (я бы сказал "проблем"), и они все свалены в кучу - это значит, что вы не понимаете целей.

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

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

Так что учитывать психологические аспекты просто необходимо. И они не простые.

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

[YuP]

rlabs и greyver, спасибо за комментарии .

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

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

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

[YuP]

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

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

[rlabs]

rlabs и greyver, спасибо за комментарии :smile:.

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

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

Найденная проблема - еще не задача. Задачей она становится, когда попадает в число актуальных для текущего релиза (итерации, тд и тп).

[greyver]

Так все-таки, чего же больше в тестировщике: созидания или разрушения?

Конечно созидания.
Тестеры ничего не ломают.

[atermath]

rlabs и greyver, спасибо за комментарии .

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

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

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

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

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

[YuP]

Вы знаете.. внимательно следил за дискуссией, и не понял одного: у вас команда или нет?

Следил-следил и не выдержал, решил написать ...

Предлагаю вернуться обратно на тему "Тестирование, конфликт, стресс" и рассматривать мой пример как один из клинических случаев противопоставления тестеров и программеров. Не думаю, что это редкий случай, т.к. он вызвал очень живой интерес. А, согласно психологии, больше всего нас раздражают в других людях те отрицательные черты, которые есть в нас самих . Можно перенести эту логику и на команду. atermath, постарайтесь осознать это и переключиться с моего ЧАСТНОГО примера на более высокий уровень абстракции. Если вы занимаетесь тестированием, то не могли не испытать радости от виртуозно сломанной программы или от обнаружения архитектурной ошибки в системе . Где тут созидание?

Тестирование, как армия - направлено на созидание, но выражается в разрушении.

[atermath]

Можно перенести эту логику и на команду. atermath, постарайтесь осознать это и переключиться с моего ЧАСТНОГО примера на более высокий уровень абстракции. Если вы занимаетесь тестированием, то не могли не испытать радости от виртуозно сломанной программы или от обнаружения архитектурной ошибки в системе . Где тут созидание?
Тестирование, как армия - направлено на созидание, но выражается в разрушении.

Для меня тестирование направлено на исследование прежде всего. Средства этого исследования иногда бывают сродни атомной бомбе, результаты - как в Хиросиме и Нагасаки, но это исследование. Можно радоваться, обнаружив багу в виде "Ребята, смотрите, какая интересная штука. Надо бы исправить", а можно "Вы, долбо..., фигню напрограммили, а я весь такой красивый ее сломал. Переделывайте, ушлепки". И радость я получаю не от деструкции, а от исследования, открытия багов, недокументированных возможностей и т.п. И это вопрос целей, которые видит тестировщик в своей работе. Т.о. разрушение это не цель. Листер и ДеМарко приводили пример удачной команды тестировщиков из IBM (Черная команда), но это скорее исключение, чем правило (там самоцелью было именно сломать).
Резюмируя: конфликт может быть а может и не быть. Иными словами, это необязательная составляющая взаимодействия внутри/между командой(ами). Ваша правда: вам нравится разрушать, и поэтому вы пошли в тестировщики. Моя правда: мне нравится исследовать, ставить эксперименты. Одно в другое может даже переходить. Вопрос в приоритетах и тех тараканах, которые будут сыты после удовлетворения страсти тестировщика к (нужное подставить)

[P_R]

Спасибо всем за ваши мысли, замечания, комментарии. Может быть формулировка немного резковата, но внимание мне хотелось акцентировать на отпечатке професии тестирования.
Как тестирование повлияло (если повлияло) на ваш характер, мировоззрение? поведение? Поверьте у хирурга тоже свои тараканы, одни проф. анекдоты достойны изучения психотерапевтов. Мы занимаемся своей работой в среднем по 8 часов. Что треть суток мы делаем? Большую часть времени мы "анализируем" Систему на наличие уязвимостей, ошибок, дефектов, противоречий. Это состояние "анализа" каждый день тренеруется и оттачивается, как ката в каратэ, оно становится частью "Я", оказывая влияние на наше мировозрение. Тестирование не может рассматриватся уже как отстраненная, независимая компонента нашей жизни, но как интегрированная составная часть ее.
Основная мысль - поиск недостатков. .... уже не только в ПО, но и в обыденной жизни (пр., обслуживание в магазине, поездка в транспорте, техника и пр.). Хочу всем поставить вопрос: если мы заботимся о качестве Продукта над которым работем, требуем ли мы от других такого же отношения (в смысле качества, правильности и т.п.)? В первом высказывании я хотел обратить внимание, что поиск недостатков во всем претендует на "вызов", возникновения конфликта причем в разных психоплоскостях, рузультат стрессовые встряски...

[atermath]

Как тестирование повлияло (если повлияло) на ваш характер, мировоззрение? поведение? Поверьте у хирурга тоже свои тараканы, одни проф. анекдоты достойны изучения психотерапевтов. Мы занимаемся своей работой в среднем по 8 часов. Что треть суток мы делаем? Большую часть времени мы "анализируем" Систему на наличие уязвимостей, ошибок, дефектов, противоречий. Это состояние "анализа" каждый день тренеруется и оттачивается, как ката в каратэ, оно становится частью "Я", оказывая влияние на наше мировозрение. Тестирование не может рассматриватся уже как отстраненная, независимая компонента нашей жизни, но как интегрированная составная часть ее.

Повлияло. Мне кажется - позитивно. Кому-то из моего окружения, наоборот, видится, что я стал занудливее и хуже. В себе заметил: большее внимание к мелочам, придирчивость, постоянное задавание вопроса "а что если" и т.п. Студенты говорят, что стал жестче проверять работы. В общем - повлияло

Основная мысль - поиск недостатков. .... уже не только в ПО, но и в обыденной жизни (пр., обслуживание в магазине, поездка в транспорте, техника и пр.). Хочу всем поставить вопрос: если мы заботимся о качестве Продукта над которым работем, требуем ли мы от других такого же отношения (в смысле качества, правильности и т.п.)? В первом высказывании я хотел обратить внимание, что поиск недостатков во всем претендует на "вызов", возникновения конфликта причем в разных психоплоскостях, рузультат стрессовые встряски...

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

[Darkus]

Есть отличный способ отучить программеров так относиться к багам.
Натравите на них хотя бы раз! разъярённого клиента, который их будет носом в баги тыкать... и на глазах менеджера желательно.
При необходимости - повторить.
Ситуация изменится ровно на 180 градусов.
Будут вас на руках носить, только бы не встречаться с клиентурой, которая находит баги вместо вас.

[barancev]

Товарищи, а кто-нибудь знает тестировщика с разрушенной личностью, а?
Причём разрушенной не чем-нибудь иным, а именно профессиональной деятельностью?