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

Grafnaf202

Регистрация: 19 фев 2016
Offline Активность: 20 фев 2016 07:34
-----

Мои сообщения

В теме: Учет времени жизни бага

19 февраля 2016 - 15:23

Мне тоже интересно, для чего все это нужно? Баги они живучие))) Какова конечная цель?

 

А какую задачу вы вообще решаете? :)

Ну смотрите, задача состоит из двух частей

1) Практически все распространяемые нами модули являются частью одной программы, причем таким образом, что одни и те же библиотеки содержат в себе функции от разных модулей (очень криво и плохо, продукт старый(с 1997), но продаваемый, и поправить это, к сожалению, нет возможности), а по договору ИТС (информационно-технического сопровождения), обновления мы предоставляем часто (доработки и какие-то частные ошибки не выявленные при тестировании). Так вот требуется такой учет версий продукта, что бы обновления на некоторые объекты можно было отдавать с неисправленными ошибками, в той части системы, которую этот объект не использует. Так сказать и волки сыты, и овцы целы. Мне конечно не нравится такой подход, но я рядовой сотрудник и существенного влияния не могу оказать на процесс, а задачу решать надо.

2) Отчетность начальству. Начальство задалось вопросом проверки того, что делает наш отдел. Такая отчетность, в принципе, удовлетворяется статистикой в багтрекере, но руководство это не устраивает и они хотят понимать, что меняется в системе от версии к версии. Версионный отчет с учетом времени жизни бага позволяет сразу мониторить как работу отдела тестирования, так и работу отдела разработки.

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


В теме: Учет времени жизни бага

19 февраля 2016 - 12:39

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

Ваша идея с тэгом оказалась верной. Получается все как надо. Спасибо!

Если вдруг кому-то пригодится вот ссылка на плагин https://www.redmine....ns/redmine_tags


В теме: Учет времени жизни бага

19 февраля 2016 - 11:21

 

Да такой способ обсуждался, но в нем получается следующее.
1) Если задача была изменена(создана) до  found in , те в версии 1.0, тогда условие поиска  found in <=1.1, fixed in > 1.1 ее не отобразит
2) Если задача будет закрыта в 1.2, а нужно построить отчет по 1.0, у нее будет статус закрыта и будет не ясно когда ее изменили, это актуально скорее для условия  found in <=1.0, fixed in > 1.1

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

в jira есть лейблы, которыми можно реализовать
в редмайне вроде бы нет лейблов, но точно есть плагин для тэгов. Тогда можно одной задаче вешать тэги типа Reprod_in_1.0, Reprod_in_1.1 итд и искать по тэгам

 

А вот эта очень классная идея, такого не пробовали, возможно подойдет


В теме: Учет времени жизни бага

19 февраля 2016 - 11:20

Поле с весрией когда найдено и после с версией когда исправоено (надо исправить).

Разница между ними дает время жизни.

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


В теме: Учет времени жизни бага

19 февраля 2016 - 11:14

 

 

добавить поле версия в редмайне

не закрытые баги перед релизом версии 1.0 переносить в версию 1.1

Поле уже сделали.

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

В качестве примера, картинка 

http://imgur.com/9XZBGCy

 

тогда добавлять к версии 1.0 версию 1.1 и так далее пока задача не будет закрыта. Если это поле совместить с полем статуса при фильтрации, то думаю проблем не должно быть. Не знаю есть ли такая возможность в редмайн, но в JIRA точно есть

 

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

 

И это еще один плюсик в копилку к JIRA, так как думаем на него перейти. Есть возможность какой-то пример приложить?