ЖЦ бага в BT Mantis
#1
Отправлено 10 февраля 2005 - 14:07
new
feedback
acknowledged
confirmed
assigned
resolved
closed
Также существует три персонажа: тестировщик, программист и менеджер проекта.
Изначально статус созданного бага new
Интересует вопрос: с какими статусами и кому дальше перенаправляются баги в различных случаях, т.е. фактически жизненный цикл ошибки?
#2
Отправлено 10 февраля 2005 - 22:45
Как только заявлен следующий билд - баг проверяется. Если он исправлен - багу присваивается статус resolved. ИМХО все вполне прозрачно.
#3
Отправлено 11 февраля 2005 - 06:28
New->(Assign Issue)->Open->(Start Progress)->In Progress->(Resolve Issue)->Resolve->(Put Testing Issue)->Put Testing->(Close Issue)->Close->(Put Industrial Issue)->Put Industrial
А вообще, это все настраиваемо, так что можно настроить так, как удобно для конкретного проекта.
#4
Отправлено 11 февраля 2005 - 07:03
1. Тестировщик добавляет баг. Баг получает статус New.
2. Если тестировщик знает, какой разработчик ответственен за данный модуль/функциональность, то тестировщик ассайнит баг на девелопера, и баг становится Assigned.
3. Если девелопер видит баг со статусом New, который он может починить, то он ассайнит баг на себя.
4. Если никто не заасайнил баг, то менеджер ассайнит баг на одного из девелоперов.
5. Когда девелопер починил баг, он ставит ему статус Resolved.
6. При выходе новой версии тестировщики проверяют все баги, которые имеют статус Resolved. Если проблема действительно решена, то тестировщик закрывает баг (статус становится Closed). А если проблема осталась, то тестировщик переоткрывает баг (Reopen) и баг становится Feedback. И дальше пункт 5.
7. Добавлять баги может каждый участник проекта. У нас Mantis используется как issues tracker, т.е. не только ошибки, но и различные проблемы могут туда заноситься. Правило остается таким: кто запостил issues, тот и проверяет и закрывает.
Статусы Acknowledged и Confirmed мы не используем
#5
Отправлено 11 февраля 2005 - 08:38
Редактор портала www.it4business.ru
#6
Отправлено 11 февраля 2005 - 11:37
Mad Cat, а зачем тогда нужны все остальные статусы, если баг можно только ассайнить или резолвить? Это узкое использование возможностей МантисыMad Cat Дата Feb 11 2005, 12:45 AM
Сначала баг эссайнится (assign) программисту. При этом сс письма падает на менеджера.
Как только заявлен следующий билд - баг проверяется. Если он исправлен - багу присваивается статус resolved. ИМХО все вполне прозрачно.
#7
Отправлено 11 февраля 2005 - 11:54
Смысла нету... ЖЦ бага ИМХО вообще не такая уж и нужная штука. [щас меня как закидают шапками...]Mad Cat, а зачем тогда нужны все остальные статусы, если баг можно только ассайнить или резолвить? Это узкое использование возможностей МантисыMad Cat Дата Feb 11 2005, 12:45 AM
Сначала баг эссайнится (assign) программисту. При этом сс письма падает на менеджера.
Как только заявлен следующий билд - баг проверяется. Если он исправлен - багу присваивается статус resolved. ИМХО все вполне прозрачно.
Есть баг, есть исправляющий его человек, есть проверяющий его человек и есть манагер, обозревающий все это. Зачем еще лишние сущности? <_<
#8
Отправлено 11 февраля 2005 - 12:08
#9
Отправлено 11 февраля 2005 - 12:16
Mad Cat Дата Feb 11 2005, 01:54 PM
QUOTE (Victorea @ Feb 11 2005, 01:37 PM)
QUOTE
Mad Cat Дата Feb 11 2005, 12:45 AM
Сначала баг эссайнится (assign) программисту. При этом сс письма падает на менеджера.
Как только заявлен следующий билд - баг проверяется. Если он исправлен - багу присваивается статус resolved. ИМХО все вполне прозрачно.
Mad Cat, а зачем тогда нужны все остальные статусы, если баг можно только ассайнить или резолвить? Это узкое использование возможностей Мантисы
Смысла нету... ЖЦ бага ИМХО вообще не такая уж и нужная штука. [щас меня как закидают шапками...]
Есть баг, есть исправляющий его человек, есть проверяющий его человек и есть манагер, обозревающий все это. Зачем еще лишние сущности?
Mad Cat, если вы считаете ЖЦ бага ненужной вещью, то скорее всего вы начинающий тестировщик. Процесс создания бага и его дальнейшая жизнь в системе это вещи, требующие аккуратности и систематизированности, главных качеств присущих тестеровщику. Если вы не используете даже close, то ошибки извечно висят у вас в Мантисе в статусе resolved? Это же некорректно!
#10
Отправлено 11 февраля 2005 - 12:20
Немного не понимаю я такого подхода. А если бы там был еще и статус "Отложен в долгий ящик", "Не буду фиксить" или еще что-то? Тоже надо было бы использовать?Nadezhda, мне близок ваш способ использовать Mantis. Приблизительно такой же ЖЦ бага и у нас в компании. Но хотелось бы использовать еще и статусы confirmed и acknowledged... Зачем-то же они в Mantis придуманы.
По поводу моего предыдущего поста - не очень он правильный. Перечитал сам, не все так просто, согласен.
Думаю, будет в тему:
Mad Cat, 11.02.2005 13:55 :
http://forums.softwa...t=0
чувствую будет буча...
archmage, 11.02.2005 13:57 :
ну ты кончено череcчур упростил :))
archmage, 11.02.2005 13:57 :
*конечно
Mad Cat, 11.02.2005 13:58 :
:) да ладно... у нас на самом деле в основной багбазе (CQ) все еще проще чем я написал :) у нас даже баги девелоперам не эссайнятся :)
archmage, 11.02.2005 13:59 :
согласен. Но по идее это не правильно.
Mad Cat, 11.02.2005 13:59 :
в наших масштабах схема себя оправдывает
Mad Cat, 11.02.2005 13:59 :
быстрее получается
archmage, 11.02.2005 14:00 :
вот и нет! Поскольку получается что программеры только код пишут. А разбор и актуализация багов ложится на ПМа или КИ.
Mad Cat, 11.02.2005 14:00 :
на qe стопудово
Mad Cat, 11.02.2005 14:01 :
хорошо... построй тогда цепочку включив туда программера... мне интересно как ты это видишь
archmage, 11.02.2005 14:02 :
Очень нравиться схема с ветки, которую предложила Nadezhda, только ее надо поменять под нас.
archmage, 11.02.2005 14:03 :
То есть выглядеть должно вот так:
New (Tester) -> Assign (Programmer or PM) -> Resolved (Programme) -> Closed (Tester).
archmage, 11.02.2005 14:04 :
Ессесно с возможностью Reopen на стороне тестера.
Mad Cat, 11.02.2005 14:05 :
хорошо... а какова выгода в этом случае? Кроме разбора и актуализации багов... это не так сложно.
А программеров это не загружает... они пишут код и не отвелкаются.
archmage, 11.02.2005 14:08 :
Проще контролировать ситуацию, кто что фиксит/л (естественно это можно поднять из VSS, но как показывает практика для старых багов это оччень сложно). А во вторых ускоряется работа тестировщика (исключен тупой перебор багов, которые НИКТО и не трогал), хотя конечно есть возможность что баг пофиксили косвенно, но это уже второй разговор.
archmage, 11.02.2005 14:08 :
И того получаем 2 плюса при минимальной потере времени программера (меньше будут серфиться:).
Mad Cat, 11.02.2005 14:09 :
уговорил.
archmage, 11.02.2005 14:09 :
;-)
#11
Отправлено 11 февраля 2005 - 12:24
Начинающий, начинающий ;) куда мне...Mad Cat Дата Feb 11 2005, 01:54 PM
QUOTE (Victorea @ Feb 11 2005, 01:37 PM)
QUOTE
Mad Cat Дата Feb 11 2005, 12:45 AM
Сначала баг эссайнится (assign) программисту. При этом сс письма падает на менеджера.
Как только заявлен следующий билд - баг проверяется. Если он исправлен - багу присваивается статус resolved. ИМХО все вполне прозрачно.
Mad Cat, а зачем тогда нужны все остальные статусы, если баг можно только ассайнить или резолвить? Это узкое использование возможностей Мантисы
Смысла нету... ЖЦ бага ИМХО вообще не такая уж и нужная штука. [щас меня как закидают шапками...]
Есть баг, есть исправляющий его человек, есть проверяющий его человек и есть манагер, обозревающий все это. Зачем еще лишние сущности?
Mad Cat, если вы считаете ЖЦ бага ненужной вещью, то скорее всего вы начинающий тестировщик. Процесс создания бага и его дальнейшая жизнь в системе это вещи, требующие аккуратности и систематизированности, главных качеств присущих тестеровщику. Если вы не используете даже close, то ошибки извечно висят у вас в Мантисе в статусе resolved? Это же некорректно!
Что значит "некорректно"? ;)
Если не секрет конечно, каковы масштабы ваших проектов? Так... в среднем...
#12
Отправлено 11 февраля 2005 - 12:50
Могу сказать, что изначально использовала лишь assign и resolve. Знание, как и понимание пришло со временем.Начинающий, начинающий куда мне...
Что значит "некорректно"?
Если не секрет конечно, каковы масштабы ваших проектов? Так... в среднем...
Как к примеру поступить в случае, если не знаешь, на кого асайнить баг? Надо создавать его как new. И тогда программисты (или МП) сами решают, кому эта ошибка принадлежит.
А если баг из состояния resolved надо опять вернуть программисту, как неисправленный или недоработанный, то есть такое состояние, как feedback.
Когда ошибка (в очередной раз) зарезолвленная на тестировщика считается тестировщиком исчерпанной, она закрывается приобретая статус closed
Некорректно, так как баг, который уже не баг должен закрываться, а не висеть вечно в состоянии resolved, мешая удобному просмотру Мантисы.
Насчет масштабов проектов. Есть несколько действительно больших проектов с постоянным суппортом, который длиться уже более пяти лет. Есть и небольшие (сравнительно) проекты. Хотя фирма моя небольших размеров.
#13
Отправлено 11 февраля 2005 - 12:50
Victorea Дата Feb 11 2005, 02:08 PM
Но хотелось бы использовать еще и статусы confirmed и acknowledged... Зачем-то же они в Mantis придуманы.
ИМХО, не сколько не рационально использовать какие-либо возможности не испытывая в них потребности. А простое удлинение ЖЦ за счет дополнительных статусов даст только потерб времени как разработчика, так и quality.
#14
Отправлено 11 февраля 2005 - 12:55
Возможно, это действительно так. Но только в том случае, если у статусов confirmed и acknowledged нет рационального применения. Пока я их не использовала, но зачем-то они были созданы разработчиками Мантисы. И мне бы хотелось знать, как они могут использоваться.archmage Дата Feb 11 2005, 02:50 PM
QUOTE
Victorea Дата Feb 11 2005, 02:08 PM
Но хотелось бы использовать еще и статусы confirmed и acknowledged... Зачем-то же они в Mantis придуманы.
ИМХО, не сколько не рационально использовать какие-либо возможности не испытывая в них потребности. А простое удлинение ЖЦ за счет дополнительных статусов даст только потерб времени как разработчика, так и quality.
#15
Отправлено 11 февраля 2005 - 13:10
Встает извечный вопрос: "Вам шашечки или ехать?"мешая удобному просмотру Мантисы
Для каждого варианта цикла разработки и тестирования есть отдельные, непереносимые features. Но удлинять и усложнять цикл обработки ошибки за счет промежуточных и некритичных статусов - ИМХО бессмысленно.
Если в день в багбазу падает 50-60 багов то из-за лишних действий теряется время. А это ценнее чем удобный просмотр багбазы.
#16
Отправлено 11 февраля 2005 - 13:14
acknowledged - lets the user know that the bug has been examined but probably not by the proper developer
confirmed - bug has been confirmed by an updater or developer
Mantis User Documentation
by Kenzaburo Ito (kenito@300baud.org) for 0.17.2
Mantis User Documentation
Вот такое объяснение я нашел. По-моему достаточно полное.
Получается, если хотите рационально использовать все возможности системы - не ленитесь читать документацию. :)
#17
Отправлено 11 февраля 2005 - 13:51
Мне кажется этот спор бесполезен, пока у вас в приритетах стоит скорость, а не качество.(Mad Cat)
Для каждого варианта цикла разработки и тестирования есть отдельные, непереносимые features. Но удлинять и усложнять цикл обработки ошибки за счет промежуточных и некритичных статусов - ИМХО бессмысленно.
Если в день в багбазу падает 50-60 багов то из-за лишних действий теряется время. А это ценнее чем удобный просмотр багбазы.
#18
Отправлено 11 февраля 2005 - 13:55
acknowledged - lets the user know that the bug has been examined but probably not by the proper developer
confirmed - bug has been confirmed by an updater or developer
archmage, спасибо за определения. Я бы не начинала эту тему, если бы у меня была документация по Мантис, а также меня не итнересовали бы мнения других тестировщиков
#19
Отправлено 11 февраля 2005 - 14:01
ну вот собственно парочка примеров с сайта Мантиса.
Victorea Дата Feb 11 2005, 02:08 PM
Но хотелось бы использовать еще и статусы confirmed и acknowledged... Зачем-то же они в Mantis придуманы.
Наглядные примеры.
1. Confirmed - http://www.mantisbt.....php?id=0004376
2. Acknowledged - http://www.mantisbt....iew.php?id=5220
В самом конце страницы раздел Issue History
Вывод:
1. Confirmed - лишнее действие для программера :D
2. Acknowledged - тоже трата времени.
#20
Отправлено 11 февраля 2005 - 14:03
:huh:
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных