Надеюсь, что с форумом я не ошибся.
Вопрос вот какой. Недавно наш отдел попросили описывать мелкие баги (интерфейс, строковые данные) просто в отчете, не занося их в специализированную систему. И только баги по функциональности заводить в багтрекинг. Через некоторое время выяснилось, что из отчета баги видимо не доходят до получателей и соответственно не правятся. Сейчас возвращаем все на круги своя:)
Все дело просто в том, что программистам лень (не знаю как еще это сказать) менять статус исправленного бага и потом остается куча багов, которых на самом деле давно уже нет, но их статус New.
Вопрос к остальным. Как Вы проводите баги различной важности и все ли они сохраняются в системе багтрекинга?
Создание отчетов и багобаза
Автор Vasiliy, 20 янв 2005 16:17
Сообщений в теме: 28
#1
Vasiliy
-
- Members
-
- 2 959 сообщений
Профессионал
- ФИО:Касимов Василий
- Город:Москва
Отправлено 20 января 2005 - 16:17
#2
Dmitry_NJ
-
- Members
-
- 3 122 сообщений
Консультант
- ФИО:Дмитрий Шевченко
- Город:New Jersey, USA
Отправлено 20 января 2005 - 16:36
IMHO, все баги должны фиксироваться. Вне зависимости от степени их критичности. Это позволяет получать более точную картину того, в каком состоянии находится проект. Другое дело, что в случае таких вот "мелких" багов можно заводить один дефект с описанием сразу нескольких таких ошибок. Один человек легко их поправит сразу все и закрыть один баг в bug tracker'e не займет много времени.
Ну а "лень" программистов лечится очень быстро и просто административными мерами воздействия.
Ну а "лень" программистов лечится очень быстро и просто административными мерами воздействия.
#3
Vasiliy
-
- Members
-
- 2 959 сообщений
Профессионал
- ФИО:Касимов Василий
- Город:Москва
Отправлено 20 января 2005 - 17:05
Вот тут не соглашусь. А вдруг он исправит не все и что потом делать? Переоткрывать баг с указанием что именно исправленно, а что нет? На мой взгляд лучше уж пусть будет одно описание на один баг.Другое дело, что в случае таких вот "мелких" багов можно заводить один дефект с описанием сразу нескольких таких ошибок. Один человек легко их поправит сразу все и закрыть один баг в bug tracker'e не займет много времени.
#4
Dmitry_NJ
-
- Members
-
- 3 122 сообщений
Консультант
- ФИО:Дмитрий Шевченко
- Город:New Jersey, USA
Отправлено 20 января 2005 - 17:30
Тогда в чем вопрос, если можно каждый баг занести отдельно? Если это не является проблемой, то и обсуждать нечего. Мне казалось, что вы пытаетесь найти компромисс между фиксацией любого (даже очень мелкого) бага в bug tracker'е, что не нравится девелоперам, и незанесением таких багов вообще, используя отчеты.
#5
Vasiliy
-
- Members
-
- 2 959 сообщений
Профессионал
- ФИО:Касимов Василий
- Город:Москва
Отправлено 20 января 2005 - 18:00
Немного не так. Изначально я говорил о незначительных багах.
А объединять можно однотипные баги, допустим в продукт входит три утилиты и в каждой в About стоит неправильная строка.
Вопрос не в том заносить вместе или по одному? Вопрос стоит заносить ли вообще или можно отправить в виде отчета и все. Исправили и забыли.
А объединять можно однотипные баги, допустим в продукт входит три утилиты и в каждой в About стоит неправильная строка.
Вопрос не в том заносить вместе или по одному? Вопрос стоит заносить ли вообще или можно отправить в виде отчета и все. Исправили и забыли.
#6
Petr
-
- Members
-
- 317 сообщений
Опытный участник
- ФИО:Можаев Петр
- Город:Москва
Отправлено 20 января 2005 - 18:12
Отчеты могут со временем затеряться, а bug tracker никуда не денется. Т.е. спустя даже продолжительное время у Вас будет возможность посмотреть то, как эволюционировал проект, если вдруг понадобится. Ну и еще при использовании bug tracker'а не будет вопросов про то, исправлен баг или еще нет, нужно только "заставить" программистов менять статус бага (это не занимает много времени).
У нас для каждого бага указывается приоритет - "немедленно", "срочно", "в обычном порядке" ну и т.д. и все баги заносятся в bug tracker.Вопрос к остальным. Как Вы проводите баги различной важности и все ли они сохраняются в системе багтрекинга?
#7
alex-golder
-
- Members
-
- 39 сообщений
Консультант проекта
- ФИО:Новичков Александр
Отправлено 20 января 2005 - 21:50
:rolleyes: мое мнение - баги должны храниться в репозитории :D
А теперь можно развернуть разговор на тему кто находит багу?
Если брать технологию Rational (пардон), то по РУП багу может найти как разработчик так и тестировщик ;)
а теперь вопрос: будет ли разработчик сам документировать найденную багу в своем модуле?
Вопрос простой... ответ очевидный... что думаете?
А теперь можно развернуть разговор на тему кто находит багу?
Если брать технологию Rational (пардон), то по РУП багу может найти как разработчик так и тестировщик ;)
а теперь вопрос: будет ли разработчик сам документировать найденную багу в своем модуле?
Вопрос простой... ответ очевидный... что думаете?
#8
Vasiliy
-
- Members
-
- 2 959 сообщений
Профессионал
- ФИО:Касимов Василий
- Город:Москва
Отправлено 20 января 2005 - 22:08
Эх, идилия....нужно только "заставить" программистов менять статус бага (это не занимает много времени).
....
У нас для каждого бага указывается приоритет - "немедленно", "срочно", "в обычном порядке" ну и т.д. и все баги заносятся в bug tracker.
#9
Dmitry_NJ
-
- Members
-
- 3 122 сообщений
Консультант
- ФИО:Дмитрий Шевченко
- Город:New Jersey, USA
Отправлено 21 января 2005 - 00:15
Не пойман - не вор :)а теперь вопрос: будет ли разработчик сам документировать найденную багу в своем модуле?
Вопрос простой... ответ очевидный... что думаете?
#10
Case
-
- Members
-
- 7 071 сообщений
Основатель
- ФИО:Панкратов Вячеслав
- Город:Украина, Киев.
Отправлено 21 января 2005 - 07:54
Вопрос: а нужно ли разработчику заноситть багу если он её тут же и починил? Он в процессе отладки таких "багов" может найти кучку. А в процессе поиска какого-то воркэраунда так наверное только то и делает, что на них натыкается, в поисках обходного пути. Все фиксировать? Мы в своё время просто не считали такие штуки за баги.
То есть может и кривовато звучит, но у нас ошибка это тот дефект который искал тестировщик, а то что нашёл разработчик у себя - не баг. А вот если проверяя что-то своё, девелопер находил ошибку в чужом коде или чудом модуле, то он её репортил как обычный тестер. То есть тут разработчик выступал в роли тестера и работал по обычному пути.
По обсуждению "тестер" и "разработчик" это роли, а не люди.
То есть может и кривовато звучит, но у нас ошибка это тот дефект который искал тестировщик, а то что нашёл разработчик у себя - не баг. А вот если проверяя что-то своё, девелопер находил ошибку в чужом коде или чудом модуле, то он её репортил как обычный тестер. То есть тут разработчик выступал в роли тестера и работал по обычному пути.
По обсуждению "тестер" и "разработчик" это роли, а не люди.
Слава Панкратов
Редактор портала www.it4business.ru
Редактор портала www.it4business.ru
#11
Doveangel
-
- Members
-
- 221 сообщений
Постоянный участник
- ФИО:Дроздова Анжелика
- Город:Беларусь
Отправлено 21 января 2005 - 08:00
У нас заносятся все баги- и мне кажется, что документирование багов низкого уровня в отдельном отчете - потеря их истории. Зачем заводить отдельную папку на сетке для хранения этих документов? Ведь когда придет время анализировать состояние продукта - придется просматривать данные багтреккинговой базы и доки по мелким "ляпам", что по-моему не очень удобно. Даже если начальство подразумевает, что доки эти предназначены лишь для информирования программеров об ошибках, неудобство когда-нить возникнет. Скоро появятся мысли и тесторов и программеров: а вот что-то такое уже было (таже синтаксическая ошибка), надо вспомнить чтоже такое было... да-никак не могу вспомнить.. и т.п. А в какой версии? когда было? никто и не помнит.
Так что я считаю, что правильнее всего - заносить все баги, причем по отдельности.
Был у нас на предприятии опыт когда несколько багов заносили в один дефект - потом выяснилось что даже психологически программерам труднее воспринимать такие заявки, не говоря уже о том, что не за один раз исправлялись все ошибки - а потом программер открывает эту незакрытую заявку и ему адо вспомнить что же он из этого сделала - а тчо нет :wacko:
Так что я считаю, что правильнее всего - заносить все баги, причем по отдельности.
Был у нас на предприятии опыт когда несколько багов заносили в один дефект - потом выяснилось что даже психологически программерам труднее воспринимать такие заявки, не говоря уже о том, что не за один раз исправлялись все ошибки - а потом программер открывает эту незакрытую заявку и ему адо вспомнить что же он из этого сделала - а тчо нет :wacko:
#12
van
-
- Members
-
- 475 сообщений
Опытный участник
- ФИО:Ваулин Артем Николаевич
- Город:Россия, Санкт - Петербург
Отправлено 21 января 2005 - 08:04
Постараюсь написать как у нас решаются заданные участниками форума вопросы.
1. Все баги независимо от их важности заносятся в BTS. Но при этом приоритет им проставляется разный от "Дизайн" до "Blocker". И если на Вас давят с какой - либо стороны (программисты, менеджмент), заставляя заносить в BTS только баги связанные с функциональностью, будте непреклонными.
2. Если программистам лень менять статусы на багах о дизайне, то это только их проблемы. Лечится это (как уж)е было написано административными мера. Ваша задача отчитаться перед выпуском продукта о состоянии дел, а забыли они (программисты) закрыть или не захотели - их трудности. Для Вас, как тестировщика, незакрытая проблема не решена.
3. Относительно нескольких ошибок в одном отчете. Я категорически против написания нескольких (пусть даже логически связанных или достаточно мелких) багов в одном запросе. Когда в одном запросе несколько ошибок, внимание программистов расссеивается и вероятность того, что часть ошибок будет не исправлена сильно возрастает. Чисто психологический момент. Второй момент связан со сложностью отслеживания ошибок, оформленных подобным образом. Всегда приходится перечитывать полный список, вспоминать, что исправлено, что нет, писать номера неисправленных ошибок при открытии и т.п. Так что - одна ошибка - один запрос.
4. Что касается нахождения ошибок самими программистами. Конечно же, они не будут регистрировать ошибку в BTS :) Но если о ней еще узнаю и я, то я обязательно ее зарегистрирую, чтобы в дальнейшем не забыть о ней и протестить (несмотря на то, что программист тут же обещает ее исправить). Я отвечаю за качество, а не он - это первый довод. А второй довод таков, что программист может найти баг, но исправлять его и не подумает сославшись на то, что это не его функционал, у него сейчас другие задачи и т.п.
1. Все баги независимо от их важности заносятся в BTS. Но при этом приоритет им проставляется разный от "Дизайн" до "Blocker". И если на Вас давят с какой - либо стороны (программисты, менеджмент), заставляя заносить в BTS только баги связанные с функциональностью, будте непреклонными.
2. Если программистам лень менять статусы на багах о дизайне, то это только их проблемы. Лечится это (как уж)е было написано административными мера. Ваша задача отчитаться перед выпуском продукта о состоянии дел, а забыли они (программисты) закрыть или не захотели - их трудности. Для Вас, как тестировщика, незакрытая проблема не решена.
3. Относительно нескольких ошибок в одном отчете. Я категорически против написания нескольких (пусть даже логически связанных или достаточно мелких) багов в одном запросе. Когда в одном запросе несколько ошибок, внимание программистов расссеивается и вероятность того, что часть ошибок будет не исправлена сильно возрастает. Чисто психологический момент. Второй момент связан со сложностью отслеживания ошибок, оформленных подобным образом. Всегда приходится перечитывать полный список, вспоминать, что исправлено, что нет, писать номера неисправленных ошибок при открытии и т.п. Так что - одна ошибка - один запрос.
4. Что касается нахождения ошибок самими программистами. Конечно же, они не будут регистрировать ошибку в BTS :) Но если о ней еще узнаю и я, то я обязательно ее зарегистрирую, чтобы в дальнейшем не забыть о ней и протестить (несмотря на то, что программист тут же обещает ее исправить). Я отвечаю за качество, а не он - это первый довод. А второй довод таков, что программист может найти баг, но исправлять его и не подумает сославшись на то, что это не его функционал, у него сейчас другие задачи и т.п.
#13
Nadezhda
-
- Members
-
- 81 сообщений
Активный участник
- Город:Харьков
Отправлено 21 января 2005 - 08:23
Похоже, наши программисты являются исключением, но они довольно часто заносят баги в BTS. Хотя у нас BTS используется не только для отслеживания дефектов, но и для отслеживания запросов на новую функциональность (feature request). К тому же, заказчик имеет доступ к нашей BTS и таким образом может отслеживать, чем занимаются программисты. Психологический момент: программист всегда знает, что он за день закрыл столько-то запросов, а если бы он их не заносил, то получается целый день чем-то занимался, а результаты не покажешь.
Что касается отчетов, я считаю, что лучше всего заносить все баги в BTS и, как уже было сказано выше, важность их оценивать соответствующим приоритетом и/или категорией.
Что касается отчетов, я считаю, что лучше всего заносить все баги в BTS и, как уже было сказано выше, важность их оценивать соответствующим приоритетом и/или категорией.
#14
Green
-
- Members
-
- 1 233 сообщений
Профессионал
- ФИО:Гринкевич Сергей
- Город:Москва
Отправлено 21 января 2005 - 08:25
Может быть вам покажется это странным, но иногда программисты вносят свои баги в базу самостоятельно. Ключем к этому является учет времени и его жесткое планирование.
Разработчику руководитель группы выделяет определенный ресурс времени на решение каждой задачи, в том числе и для исправления открытых багов. Если бага нет, то и времени нет. Если хочешь получить дополнительное время на исправление - заноси баг в базу, даже если нашел его сам.
Помимо этого, существует четкое правило по работе с багами. За работу с ними ответственность несет руководитель группы разработчиков. Он может сам, а может поручить кому-нибудь просматривать баги каждый день и назначать задачи на устранение дефекта. Просматриваются не только баги, но и задачи на их устранение. В итоге один человек контролирует, распределяет и отчитывается о програссе в работе с дефектами.
Разработчику руководитель группы выделяет определенный ресурс времени на решение каждой задачи, в том числе и для исправления открытых багов. Если бага нет, то и времени нет. Если хочешь получить дополнительное время на исправление - заноси баг в базу, даже если нашел его сам.
Помимо этого, существует четкое правило по работе с багами. За работу с ними ответственность несет руководитель группы разработчиков. Он может сам, а может поручить кому-нибудь просматривать баги каждый день и назначать задачи на устранение дефекта. Просматриваются не только баги, но и задачи на их устранение. В итоге один человек контролирует, распределяет и отчитывается о програссе в работе с дефектами.
Гринкевич Сергей
#15
Undi
-
- Members
-
- 134 сообщений
Активный участник
- Город:Kiev
Отправлено 21 января 2005 - 09:54
Уу нас делается так:3. Относительно нескольких ошибок в одном отчете. Я категорически против написания нескольких (пусть даже логически связанных или достаточно мелких) багов в одном запросе. Когда в одном запросе несколько ошибок, внимание программистов расссеивается и вероятность того, что часть ошибок будет не исправлена сильно возрастает. Чисто психологический момент. Второй момент связан со сложностью отслеживания ошибок, оформленных подобным образом. Всегда приходится перечитывать полный список, вспоминать, что исправлено, что нет, писать номера неисправленных ошибок при открытии и т.п. Так что - одна ошибка - один запрос.
Мелкие однотипные баги (опечатки, неправильные знаки препинания, Taborder, заголовки) могут заноситься в BTS как одна ошибка. Если при повторной проверке обнаруживается, что часть не исправлена, в комментарии заносится информация что именно не исправлено и повторно направляется программисту. При этом разработчику и позже тестировщику уже не нужно просматривать весь баг, а достаточно прочитать комментарии.
#16
PavelB
-
- Members
-
- 169 сообщений
Постоянный участник
- Город:Санкт-Петербург
Отправлено 21 января 2005 - 11:16
У нас о мелких ошибках иногда устный разговор ведётся. Но я не считаю это правильным, по-моему, лучше всё документировать.
#17
romanl
-
- Members
-
- 129 сообщений
Активный участник
- ФИО:Роман Любунь
- Город:Львов
Отправлено 21 января 2005 - 12:27
Относительно занесения разработчиками багов в ВТС.
У нас разработчики заносят (постят) багги сами на себя, но только в том случае если для исправления бага надо много времени или надо уточнить баг ли это. Это своего рода записная книжка куда разработчики записывают свое недовольство своим же кодом, чтобы не забить потом исправить, проверить еще раз.
У нас разработчики заносят (постят) багги сами на себя, но только в том случае если для исправления бага надо много времени или надо уточнить баг ли это. Это своего рода записная книжка куда разработчики записывают свое недовольство своим же кодом, чтобы не забить потом исправить, проверить еще раз.
#18
Victorea
-
- Members
-
- 89 сообщений
Активный участник
- ФИО:Klimova Victorea
- Город:Ukraine, Kiev
Отправлено 21 января 2005 - 14:53
Конечно, необходимо заносить все баги. Орфографические ошибки, небольшие смещения полей и т.п. Но такие баги лучше заносить в локальную BT System, т.к. заказчику о них лучше даже не знать
#19
Гость_Sulla_*
Гость_Sulla_*
-
- Guests
Отправлено 22 января 2005 - 22:12
1. в BTS заносится все.
распределение по приоритету: прямо сейчас, .... , когда будет время (1P,...,P5)
распределени по типа: хана(делать ничего нельзя), .... , оформление
а при желании можно завести продукты типа редактуры, и заносить туда баги связанные с:
а) опечатки,
б) неправильные знаки препинания,
в) Taborder,
г) заголовки
2.
а вот доступ заказчику к BTS совсем необязателен)
3. разработчики часто сами заносят баги:
а) нет времени сейчас
б) надо подумать а как он вообще вылез
б.1) а баг ли это
распределение по приоритету: прямо сейчас, .... , когда будет время (1P,...,P5)
распределени по типа: хана(делать ничего нельзя), .... , оформление
а при желании можно завести продукты типа редактуры, и заносить туда баги связанные с:
а) опечатки,
б) неправильные знаки препинания,
в) Taborder,
г) заголовки
2.
а вот доступ заказчику к BTS совсем необязателен)
3. разработчики часто сами заносят баги:
а) нет времени сейчас
б) надо подумать а как он вообще вылез
б.1) а баг ли это
#20
Vasiliy
-
- Members
-
- 2 959 сообщений
Профессионал
- ФИО:Касимов Василий
- Город:Москва
Отправлено 23 января 2005 - 13:52
У нас тоже такое бывает. Правда чаще случается другая ситуация. На адрес QA приходит письмо со словами, что вот видели такое-то и там-то. Проверить и занести в BTS.Похоже, наши программисты являются исключением, но они довольно часто заносят баги в BTS. Хотя у нас BTS используется не только для отслеживания дефектов, но и для отслеживания запросов на новую функциональность (feature request).
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных
