Перейти к содержимому

Фотография

ЖЦ бага в BT Mantis


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 32

#1 Victorea

Victorea

    Активный участник

  • Members
  • PipPip
  • 89 сообщений
  • ФИО:Klimova Victorea
  • Город:Ukraine, Kiev

Отправлено 10 февраля 2005 - 14:07

В баг трэкере Мантис существуют такие статусы для бага:
new
feedback
acknowledged
confirmed
assigned
resolved
closed
Также существует три персонажа: тестировщик, программист и менеджер проекта.
Изначально статус созданного бага new
Интересует вопрос: с какими статусами и кому дальше перенаправляются баги в различных случаях, т.е. фактически жизненный цикл ошибки?
  • 0

#2 Mad Cat

Mad Cat

    Постоянный участник

  • Members
  • PipPipPip
  • 222 сообщений
  • ФИО:Александр Балабанов
  • Город:Киев

Отправлено 10 февраля 2005 - 22:45

Сначала баг эссайнится (assign) программисту. При этом сс письма падает на менеджера.
Как только заявлен следующий билд - баг проверяется. Если он исправлен - багу присваивается статус resolved. ИМХО все вполне прозрачно.
  • 0

#3 van

van

    Опытный участник

  • Members
  • PipPipPipPip
  • 475 сообщений
  • ФИО:Ваулин Артем Николаевич
  • Город:Россия, Санкт - Петербург

Отправлено 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

А вообще, это все настраиваемо, так что можно настроить так, как удобно для конкретного проекта.
  • 0
Ваулин Артем
КОРУС Консалтинг
Руководитель отдела тестирования

Мой дневник

#4 Nadezhda

Nadezhda

    Активный участник

  • Members
  • PipPip
  • 81 сообщений
  • Город:Харьков

Отправлено 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 мы не используем
  • 0

#5 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 11 февраля 2005 - 08:38

Только к Мантиссу или другой подобной системе ЖЦ бага привязан мало. Как вы захотите так баг и "ходит". Как вы себе поймёте так и будете ему статусы менять. Это к bts мало отношения имеет.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#6 Victorea

Victorea

    Активный участник

  • Members
  • PipPip
  • 89 сообщений
  • ФИО:Klimova Victorea
  • Город:Ukraine, Kiev

Отправлено 11 февраля 2005 - 11:37

Mad Cat Дата Feb 11 2005, 12:45 AM
Сначала баг эссайнится (assign) программисту. При этом сс письма падает на менеджера.
Как только заявлен следующий билд - баг проверяется. Если он исправлен - багу присваивается статус resolved. ИМХО все вполне прозрачно.

Mad Cat, а зачем тогда нужны все остальные статусы, если баг можно только ассайнить или резолвить? Это узкое использование возможностей Мантисы
  • 0

#7 Mad Cat

Mad Cat

    Постоянный участник

  • Members
  • PipPipPip
  • 222 сообщений
  • ФИО:Александр Балабанов
  • Город:Киев

Отправлено 11 февраля 2005 - 11:54

Mad Cat Дата Feb 11 2005, 12:45 AM
Сначала баг эссайнится (assign) программисту. При этом сс письма падает на менеджера.
Как только заявлен следующий билд - баг проверяется. Если он исправлен - багу присваивается статус resolved. ИМХО все вполне прозрачно.

Mad Cat, а зачем тогда нужны все остальные статусы, если баг можно только ассайнить или резолвить? Это узкое использование возможностей Мантисы

Смысла нету... ЖЦ бага ИМХО вообще не такая уж и нужная штука. [щас меня как закидают шапками...]

Есть баг, есть исправляющий его человек, есть проверяющий его человек и есть манагер, обозревающий все это. Зачем еще лишние сущности? <_<
  • 0

#8 Victorea

Victorea

    Активный участник

  • Members
  • PipPip
  • 89 сообщений
  • ФИО:Klimova Victorea
  • Город:Ukraine, Kiev

Отправлено 11 февраля 2005 - 12:08

Nadezhda, мне близок ваш способ использовать Mantis. Приблизительно такой же ЖЦ бага и у нас в компании. Но хотелось бы использовать еще и статусы confirmed и acknowledged... Зачем-то же они в Mantis придуманы.
  • 0

#9 Victorea

Victorea

    Активный участник

  • Members
  • PipPip
  • 89 сообщений
  • ФИО:Klimova Victorea
  • Город:Ukraine, Kiev

Отправлено 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? Это же некорректно!
  • 0

#10 Mad Cat

Mad Cat

    Постоянный участник

  • Members
  • PipPipPip
  • 222 сообщений
  • ФИО:Александр Балабанов
  • Город:Киев

Отправлено 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 :
;-)


  • 0

#11 Mad Cat

Mad Cat

    Постоянный участник

  • Members
  • PipPipPip
  • 222 сообщений
  • ФИО:Александр Балабанов
  • Город:Киев

Отправлено 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? Это же некорректно!

Начинающий, начинающий ;) куда мне...

Что значит "некорректно"? ;)

Если не секрет конечно, каковы масштабы ваших проектов? Так... в среднем...
  • 0

#12 Victorea

Victorea

    Активный участник

  • Members
  • PipPip
  • 89 сообщений
  • ФИО:Klimova Victorea
  • Город:Ukraine, Kiev

Отправлено 11 февраля 2005 - 12:50

Начинающий, начинающий  куда мне...

Что значит "некорректно"? 

Если не секрет конечно, каковы масштабы ваших проектов? Так... в среднем...

Могу сказать, что изначально использовала лишь assign и resolve. Знание, как и понимание пришло со временем.
Как к примеру поступить в случае, если не знаешь, на кого асайнить баг? Надо создавать его как new. И тогда программисты (или МП) сами решают, кому эта ошибка принадлежит.
А если баг из состояния resolved надо опять вернуть программисту, как неисправленный или недоработанный, то есть такое состояние, как feedback.
Когда ошибка (в очередной раз) зарезолвленная на тестировщика считается тестировщиком исчерпанной, она закрывается приобретая статус closed

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

Насчет масштабов проектов. Есть несколько действительно больших проектов с постоянным суппортом, который длиться уже более пяти лет. Есть и небольшие (сравнительно) проекты. Хотя фирма моя небольших размеров.
  • 0

#13 archmage

archmage

    Новый участник

  • Members
  • Pip
  • 10 сообщений
  • ФИО:Хижняк Андрей
  • Город:Киев

Отправлено 11 февраля 2005 - 12:50

Victorea  Дата Feb 11 2005, 02:08 PM
Но хотелось бы использовать еще и статусы confirmed и acknowledged... Зачем-то же они в Mantis придуманы.


ИМХО, не сколько не рационально использовать какие-либо возможности не испытывая в них потребности. А простое удлинение ЖЦ за счет дополнительных статусов даст только потерб времени как разработчика, так и quality.
  • 0
------
Вкалывают роботы - счастлив человек
Testlab²
http://testlab2.com

#14 Victorea

Victorea

    Активный участник

  • Members
  • PipPip
  • 89 сообщений
  • ФИО:Klimova Victorea
  • Город:Ukraine, Kiev

Отправлено 11 февраля 2005 - 12:55

archmage Дата Feb 11 2005, 02:50 PM
QUOTE 
Victorea  Дата Feb 11 2005, 02:08 PM
Но хотелось бы использовать еще и статусы confirmed и acknowledged... Зачем-то же они в Mantis придуманы.

ИМХО, не сколько не рационально использовать какие-либо возможности не испытывая в них потребности. А простое удлинение ЖЦ за счет дополнительных статусов даст только потерб времени как разработчика, так и quality.

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

#15 Mad Cat

Mad Cat

    Постоянный участник

  • Members
  • PipPipPip
  • 222 сообщений
  • ФИО:Александр Балабанов
  • Город:Киев

Отправлено 11 февраля 2005 - 13:10

мешая удобному просмотру Мантисы

Встает извечный вопрос: "Вам шашечки или ехать?"

Для каждого варианта цикла разработки и тестирования есть отдельные, непереносимые features. Но удлинять и усложнять цикл обработки ошибки за счет промежуточных и некритичных статусов - ИМХО бессмысленно.

Если в день в багбазу падает 50-60 багов то из-за лишних действий теряется время. А это ценнее чем удобный просмотр багбазы.
  • 0

#16 archmage

archmage

    Новый участник

  • Members
  • Pip
  • 10 сообщений
  • ФИО:Хижняк Андрей
  • Город:Киев

Отправлено 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

Вот такое объяснение я нашел. По-моему достаточно полное.
Получается, если хотите рационально использовать все возможности системы - не ленитесь читать документацию. :)
  • 0
------
Вкалывают роботы - счастлив человек
Testlab²
http://testlab2.com

#17 Victorea

Victorea

    Активный участник

  • Members
  • PipPip
  • 89 сообщений
  • ФИО:Klimova Victorea
  • Город:Ukraine, Kiev

Отправлено 11 февраля 2005 - 13:51

(Mad Cat)
Для каждого варианта цикла разработки и тестирования есть отдельные, непереносимые features. Но удлинять и усложнять цикл обработки ошибки за счет промежуточных и некритичных статусов - ИМХО бессмысленно.

Если в день в багбазу падает 50-60 багов то из-за лишних действий теряется время. А это ценнее чем удобный просмотр багбазы.

Мне кажется этот спор бесполезен, пока у вас в приритетах стоит скорость, а не качество.
  • 0

#18 Victorea

Victorea

    Активный участник

  • Members
  • PipPip
  • 89 сообщений
  • ФИО:Klimova Victorea
  • Город:Ukraine, Kiev

Отправлено 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, спасибо за определения. Я бы не начинала эту тему, если бы у меня была документация по Мантис, а также меня не итнересовали бы мнения других тестировщиков
  • 0

#19 p.s

p.s

    Новый участник

  • Members
  • Pip
  • 6 сообщений

Отправлено 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 - тоже трата времени.
  • 0

#20 p.s

p.s

    Новый участник

  • Members
  • Pip
  • 6 сообщений

Отправлено 11 февраля 2005 - 14:03

Ух!. Арч .... Ух! Моторный.
:huh:
  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных