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

[Mad Cat]

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

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

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

А у меня в приоритете максимально эффективная работа. Т.е. достижение максимальных результатов при минимальных затратах времени. ;)

[archmage]

2 Victorea: Возможно я не понимаю проблемы, во-первых, документация открыта, во-вторых, как упоминалось выше, статусы бага тоже не являются константой. В результате мы получаем гибкую систему с возможностью настройки под каждый проект (не говоря о компании вообщем). И по всему выходит, что статусы багов обусловлены не bug-track системой, а производственным процесом. И отталкиваться надо именно от процеса.

2 P.S. : Первые идут за нами :)

[Smash]

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

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

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

Инженеры трёх компаний, Motorola, Siemens и Nokia пересеклись в туалете на ежегодном форуме мобильной связи.
Сделав свое дело, инженер Nokia отмотал ворох полотенец и вытер руки. У него спросили "Зачем тебе так много?". Он ответил - "Нас учили достигать цели не жалея ресурсов".
Инженер Motorola, вытирая руки взял небольшой кусок полотенца, сказав "А нас учили добиватся своего с минимальными затратами". На что инженер Siemens ответил
"А нас учили не ссать на руки"

B)

[p.s]

Мдя-я-я-я .... нашли место где .... поговорить ... :-)
Может вы сюда еще и свой канал перенесете :D

[Victorea]

archmage Дата Feb 11 2005, 04:16 PM

2 Victorea: Возможно я не понимаю проблемы, во-первых, документация открыта, во-вторых, как упоминалось выше, статусы бага тоже не являются константой. В результате мы получаем гибкую систему с возможностью настройки под каждый проект (не говоря о компании вообщем). И по всему выходит, что статусы багов обусловлены не bug-track системой, а производственным процесом. И отталкиваться надо именно от процеса.

Разве я против того, что статусы бага не являются константой? :) Но еще раз повторяю, что интересны были дефолтовые статусы и их использование. И собственно проблемы никакой нет. Есть просто здоровый интерес. И вы его практически удовлетворили своим ответом:

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]

Вот и ладушки :) Надо понимать тема исчерпана.

[Angela]

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

А в предыдущей

Так что ЖЦ всегда должен зависеть от процесса в компании и пересматриваться время от времени

[Angela]

Оказывается не дописала :blink:
В предыдущей компании (коробочный софт) был стаус "подтверждения" для улучшений от Product Manager. А с багами проектная команда сама разбиралась.

Так что не инструмент должен диктовать список статусов, а жизнь. Причем именно опыт, возможно с ошибками, но собственный опыт компании, а не советы соседа или статьи.

[Victorea]

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

[Angela]

у нас этим статусом в зависимости от объема и сложности проекта занимаются либо аналитик, либо тест-проектировщик, либо тест-менеджер. У МП вряд ли руки дойдут.... Хотя теоретически тоже возможно. Короче, член проектной команды, который лучше всех остальных знает требования к системе.

[Undi]

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

[Angela]

Чтобы включить "баг" в регрессионное тестирование, надо просто план регрессионного тестирования уточнить. И не нужно дополнительных статусов.

[Undi]

Чтобы включить "баг" в регрессионное тестирование, надо просто план регрессионного тестирования уточнить. И не нужно дополнительных статусов.

конечно, можно в плане регрессионного тестирования указывать номер бага и в случае необходимости переоткрывать его.
Но почему бы не использовать "мантис" для этого? Например, переименовать один из неиспользуемых статусов и таким образом видеть список багов для регрессионного тестирования в mantis.