Знаем про проблему, но не чиним

Привет!
Этот вопрос у меня появился давно, только сейчас решилась создать тему. В общем...
Есть программист. Во время работы (когда закрывает баг, или дописывает фичу) он видит, что есть небольшая ошибочка, но незаметная: вроде в IE отображается коряво, или после каких-то определённых действий что-то на страничке не туда "поплыло". То есть всё работает, но есть недочёт - баг с приоритетом minor. Так вот. Если он такое находит - сознательно это не исправляет сразу. Ждёт, когда найду я, тогда исправляет за короткое время (т.к. этот же баг не новинка, программист про него знал). Человек таким образом повышает свою значимость в глазах начальства - типа умеет быстро исправлять проблемы.
Как думаете, наличие такой коллеги в команде для меня (как для тестировщика) хорошо, или плохо? Или фиолетово?

Как думаете, наличие такой коллеги в команде для меня (как для тестировщика) хорошо, или плохо? Или фиолетово?

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

Но.
Как у вас осуществляется отчетность по задачам и затраченному времени?
Может ли программист в рамках одной задачи делать еще и другие? или для внесения исправлений обязательно требуется тикет в BTS?

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

А разве не падает оценка работы сотрудника в связи с бОльшим количеством багов? Или Вам известно, что если быстро править, то это самое главное?


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

Не совсем понимаю, как такой коллега может влиять на Вас...

...Ждёт, когда найду я, тогда исправляет...

А с чего вы взяли, что это так??

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

Привет!
Этот вопрос у меня появился давно, только сейчас решилась создать тему. В общем...
Есть программист. Во время работы (когда закрывает баг, или дописывает фичу) он видит, что есть небольшая ошибочка, но незаметная: вроде в IE отображается коряво, или после каких-то определённых действий что-то на страничке не туда "поплыло". То есть всё работает, но есть недочёт - баг с приоритетом minor. Так вот. Если он такое находит - сознательно это не исправляет сразу. Ждёт, когда найду я, тогда исправляет за короткое время (т.к. этот же баг не новинка, программист про него знал). Человек таким образом повышает свою значимость в глазах начальства - типа умеет быстро исправлять проблемы.
Как думаете, наличие такой коллеги в команде для меня (как для тестировщика) хорошо, или плохо? Или фиолетово?

Есть два типа программистов. Одни, если находят баг в своем коде обычно заносят его в трекер. Другие, зная о багах (неважно мелких, крупных) никогда не будут писать баги в трекер. (Шопотом: И да, есть даже фирмы, в которых программистам _запрещено_ заводить баги, но только тсс об этом). Так вот второй тип программистов - это, скажем так, не совсем качественные программисты, типа осетрины второй свежести.
Что касается мелких багов, так многие программисты их в силу некоторых особенностей (вполне объяснимых) не замечают. Или вернее не ищут. А иногда они сомневаются или считают, что это и не баг вовсе.
Но когда тестировщик пишет баг в трекер, то скорее всего его починить легко, вот и чинят быстро. А если бы тестировщик не нашел какую-то мелочь - то может и прав был программист, когда думал, что это и не баг вовсе?

Привет!
Этот вопрос у меня появился давно, только сейчас решилась создать тему. В общем...
Есть программист. Во время работы (когда закрывает баг, или дописывает фичу) он видит, что есть небольшая ошибочка, но незаметная: вроде в IE отображается коряво, или после каких-то определённых действий что-то на страничке не туда "поплыло". То есть всё работает, но есть недочёт - баг с приоритетом minor. Так вот. Если он такое находит - сознательно это не исправляет сразу. Ждёт, когда найду я, тогда исправляет за короткое время (т.к. этот же баг не новинка, программист про него знал). Человек таким образом повышает свою значимость в глазах начальства - типа умеет быстро исправлять проблемы.
Как думаете, наличие такой коллеги в команде для меня (как для тестировщика) хорошо, или плохо? Или фиолетово?

Есть два типа программистов. Одни, если находят баг в своем коде обычно заносят его в трекер. Другие, зная о багах (неважно мелких, крупных) никогда не будут писать баги в трекер. (Шопотом: И да, есть даже фирмы, в которых программистам _запрещено_ заводить баги, но только тсс об этом). Так вот второй тип программистов - это, скажем так, не совсем качественные программисты, типа осетрины второй свежести.
Что касается мелких багов, так многие программисты их в силу некоторых особенностей (вполне объяснимых) не замечают. Или вернее не ищут. А иногда они сомневаются или считают, что это и не баг вовсе.
Но когда тестировщик пишет баг в трекер, то скорее всего его починить легко, вот и чинят быстро. А если бы тестировщик не нашел какую-то мелочь - то может и прав был программист, когда думал, что это и не баг вовсе?

Позитивный ответ)

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

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

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

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

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

Насчет анализа. По программистам никогда бы делать не стала. Задачи/нагрузки у программистов разные, соответственно - и баги разные в разном количестве; и не тестировщику анализы проводить. Это прямая дорога испортить напрочь отношения с программистами, и , соответственно - еще одна помеха проекту!

Теперь, что бы я делала в таких условиях (ну, если реально раздражает...): реально неплохо иногда собирать статистику по программистам и предоставлять ее менеджменту с соответствующим анализом. У этого программиста наверняка количество минорных багов будет гораздо выше, чем у других. Что и показывает низкую культуру программирования. Эту статистику можно представить на очередном совещании.

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

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

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

уф.....
Надо нажимать "Спасибо"!!!

Но.
Как у вас осуществляется отчетность по задачам и затраченному времени?
Может ли программист в рамках одной задачи делать еще и другие? или для внесения исправлений обязательно требуется тикет в BTS?

Добавляем в BTS время в соответствующий тикет.
Нет, не обязательно. Я могу переоткрыть уже существующий тикет.

А вы можете как-то повлиять на наличие или отсутствие у вас такой коллеги?)

Нет.

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

Лично мне кажется, что не повышает. Но она считает не так. Это её мнение.
Куча других положительных качеств есть. Я просто задумалась, как ЭТО конкретное качество сказывается или может сказаться на мне.

...Ждёт, когда найду я, тогда исправляет...

А с чего вы взяли, что это так??

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

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

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

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

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

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

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

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

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

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

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

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