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

[Vasiliy]

Тема кажется эта.

Коллеги, подскажите по ситуации, пожалуйста.

Есть система таскменеджмента - Jira. В нее пишутся задачи, анализируются, разрешаются, etc. После того как разработчик поставил Resolved Fixed задача переходит в отдел тестирования. Если найдены какие-либо ошибки, то задача переоткрывается обратно на разработчика с описанием что и как. То есть все ошибки фигурируют внутри этой задачи, отдельной записи на баг не создается. Если проверка прошла и ошибок нет - задача отправляется дальше по этапам своего жизненного цикла.
При таком подходе можно отследить, что происходит с версией - N задач в разработке, М - в тестировании, Q - сделано. Но нельзя понять, сколько ошибок найдено по той или иной задаче. В принципе можно считать количество переоткрытий на каждую задачу, но это не самый легкий и удобный путь.
Собственно вопрос. Кто-нибудь еще живет по таким процессам? Как отслеживаются ошибки в таком случае? Или по каждой задаче идет отдельный поток ошибок дополнительно?

[SALar]

Такое встречается в жизни. Жить так живете вы - мучительно. Другие, виденные мной варианты тоже не сахар. Выход есть и очень простой:
Купите наконец нормальную BTS! С иерархией объектов.
Стоит она - копейки. Все эти багзилы, мантисы и прочие джиры отлично подходят для гаражного кооператива. И в какой то момент становятся чемоданом без ручки. Бесплатен, но как неудобен!

[Vasiliy]

Jira кажется не бесплатна, насколько я помню сейчас.
Совет принят)

[rlabs]

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

Я, конечно, ничего не понял, но.

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

Во-вторых, переоткрытие задачи - тоже противоестественно.

С оптимистичной и очень ответственной точки зрения, пока задача не дотестирована и не доведена до ума, она должна быть открыта (и открытостью своей сигнализировать).
С реалистичной, при любом процессе у задачи есть две стадии - development ready и testing ready. Поэтому я бы ставил девелопмент-задачу в resolved, когда основная разработка закончена, заносил бы нормальные баги, пока они находятся, и ставил бы задачу в closed, когда открытых багов больше нет и приемочный тест пройден.

Разумно?

[Case]

Стоит она - копейки. Все эти багзилы, мантисы и прочие джиры отлично подходят для гаражного кооператива.

Ты видимо не работал с Jira, Сергей? Это платный и офигенно удобный продукт - после Борландовского еще Стартима - Jira самое лучшее решение для трекинга что я видел. Мы еще года 3-4 назад (на самой дорогой, правда, версии) построили полноценную систему управления проектом от получения требований через WBS и тренкинга ошибок. С кнопкой Relise даже :) Срастили с SVN для трекинга на код и с Confluence для автоматического построения документации и отчетов. Заметь - внутрь допиливать никто не лазил.

[Case]

Есть система таскменеджмента - Jira. В нее пишутся задачи, анализируются, разрешаются, etc. После того как разработчик поставил Resolved Fixed задача переходит в отдел тестирования. Если найдены какие-либо ошибки, то задача переоткрывается обратно на разработчика с описанием что и как. То есть все ошибки фигурируют внутри этой задачи, отдельной записи на баг не создается.

Здесь маленькая поправка, которая починит процесс: баги заводим отдельно именно как баги и линкуем на таску. Если версия позвляет - можно делать баги сабтасками - пока сабтаск открыт - родитель не закроется. Пока есть не закрытый таск - не релизится версия.

[Vasiliy]

А можно теперь немного философии.
Программистов вроде как все устраивает. Как можно подтолкнуть к таким изменениям и какие аргументы привести, чтобы доказать, что нужны отдельные записи для каждой ошибки?

[astenix]

Кого именно надо "подтолкнуть к таким изменениям"?

ЗЫ Философский настрой генерирует вопросы вроде "А следует ли толкать?" и "А следует ли толкать того, кто толкает тебя?"

[Vita]

А можно теперь немного философии.
Как можно подтолкнуть к таким изменениям и какие аргументы привести, чтобы доказать, что нужны отдельные записи для каждой ошибки?

Хочется добавить, отдельные внятные (понятные) записи по каждой ошибке, изменению.

Мне нужно подробное знание ошибок и исправлений, чтобы знать, где и какие связи глубже "смотреть и анализировать", а кому-то просто затем, чтобы проверить сделано ли :)

По части философии Вы сами легко справитесь, если представите, что у Вас самого спрашивают такого совета, что бы Вы мне посоветовали, чтобы я могла доказать, что нужны отдельные записи для каждой ошибки?

К каждому человеку свой подход найти нужно.

[rlabs]

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

Количество ошибок и оценки времени на их исправление помогают предсказать время завершения работ. Не подойдет?

[barancev]

А можно теперь немного философии.
Программистов вроде как все устраивает. Как можно подтолкнуть к таким изменениям и какие аргументы привести, чтобы доказать, что нужны отдельные записи для каждой ошибки?

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

[Vasiliy]

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

Не устраивает вышестоящее руководство, да. Хочется больше информации, чем просто количество переоткрытий на задачу.

[DrVal]

Доводы простые bug tracker потому так и называется, что позволяет трекать каждый баг отдельно.

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

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

А можно теперь немного философии.
Программистов вроде как все устраивает. Как можно подтолкнуть к таким изменениям и какие аргументы привести, чтобы доказать, что нужны отдельные записи для каждой ошибки?

[kabriolett]

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

Не устраивает вышестоящее руководство, да. Хочется больше информации, чем просто количество переоткрытий на задачу.

Хм, если не устраивает начальство, то все делается через административные рычаги.
Пишется письмо, процедура или устно (все зависит от развития компании) с содержанием:

С этого момента мы живем по следующим правилам:
Правила....

И всем в ознакомление...

А через месяц желательно внутренний аудит для контроля выполнения правил игры с JIRA.

[OliaBudn]

Есть система таскменеджмента - Jira. В нее пишутся задачи, анализируются, разрешаются, etc. После того как разработчик поставил Resolved Fixed задача переходит в отдел тестирования. Если найдены какие-либо ошибки, то задача переоткрывается обратно на разработчика с описанием что и как. То есть все ошибки фигурируют внутри этой задачи, отдельной записи на баг не создается.

Здесь маленькая поправка, которая починит процесс: баги заводим отдельно именно как баги и линкуем на таску. Если версия позвляет - можно делать баги сабтасками - пока сабтаск открыт - родитель не закроется. Пока есть не закрытый таск - не релизится версия.

Вот мы именно так и работаем. Я, как тестер захожу, смотрю. Баг нашла (2,3... сколько хочешь) - все отдельно зарепортила, прицепила к таску (ЮС в нашем случае), и таск переоткрыла. Программеру нотификейшен пришел про все. Он зашел, исправил все баги. Когда они все fixed он может вернуть статус resolved на таск. Как только он вернул статус резолвед - я опять нотификейшен получила. Зашла, проверила все прицепленные баги (у них тоже отдельно статус меняется), проверила опять функционал. Когда всё внутри проверено - меняю статус таска, что он проверен.
Трекается все туда и обратно включая имя тестера, который все проверял (могут быть и разные тестеры).
ЗЫ: работаем с Мантисом. Хотя ИМХО большого значения это не имеет. Главное всем договориться.

[Drag]

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

[jjjzmey]

Ну как, процесс настроили нормально?

[Vasiliy]

Мы построили процесс и признали его нормальным:)

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

[jjjzmey]

За 2 прошедших года что-то сдвинулось в лучшую сторону?

[Vasiliy]

Почти нет.