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

Фотография

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


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

#1 Grafnaf202

Grafnaf202

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

  • Members
  • Pip
  • 8 сообщений
  • ФИО:Иван
  • Город:Мск

Отправлено 19 февраля 2016 - 10:36

Господа, сразу прошу прощения, если создал вопрос не в той теме.

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

В общем, к вопросу.

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

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

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

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

Заранее спасибо. 

 


  • 0

#2 Lzk

Lzk

    Специалист

  • Members
  • PipPipPipPipPip
  • 504 сообщений
  • ФИО:Олег
  • Город:Мск

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

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

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


  • 0

#3 Freiman

Freiman

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 591 сообщений
  • ФИО:Андрей Адеркин
  • Город:Йошкар-Ола

Отправлено 19 февраля 2016 - 10:54

Возможен такой вариант:

Есть два поля - found in build и fixed in build

Если баг найден в версии 1.0, а пофикшен только 1.2 - то ясно ж, что в версиях 1.0 и 1.1 он был. 

Соответственно, если вам надо найти все баги, которые существовали в 1.1, то в поиске делаем фильтр found in <=1.1, fixed in > 1.1

По-моему, это наиболее простой способ.


  • 0

#4 Grafnaf202

Grafnaf202

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

  • Members
  • Pip
  • 8 сообщений
  • ФИО:Иван
  • Город:Мск

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

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

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

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

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

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

http://imgur.com/9XZBGCy


  • 0

#5 Lzk

Lzk

    Специалист

  • Members
  • PipPipPipPipPip
  • 504 сообщений
  • ФИО:Олег
  • Город:Мск

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

 

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

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

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

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

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

http://imgur.com/9XZBGCy

 

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


  • 1

#6 Grafnaf202

Grafnaf202

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

  • Members
  • Pip
  • 8 сообщений
  • ФИО:Иван
  • Город:Мск

Отправлено 19 февраля 2016 - 11:09

Возможен такой вариант:

Есть два поля - found in build и fixed in build

Если баг найден в версии 1.0, а пофикшен только 1.2 - то ясно ж, что в версиях 1.0 и 1.1 он был. 

Соответственно, если вам надо найти все баги, которые существовали в 1.1, то в поиске делаем фильтр found in <=1.1, fixed in > 1.1

По-моему, это наиболее простой способ.

Да такой способ обсуждался, но в нем получается следующее.

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


  • 0

#7 Vasiliy

Vasiliy

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 959 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

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

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

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


  • 0

#8 Grafnaf202

Grafnaf202

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

  • Members
  • Pip
  • 8 сообщений
  • ФИО:Иван
  • Город:Мск

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

 

 

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

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

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

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

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

http://imgur.com/9XZBGCy

 

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

 

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

 

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


  • 0

#9 Freiman

Freiman

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 591 сообщений
  • ФИО:Андрей Адеркин
  • Город:Йошкар-Ола

Отправлено 19 февраля 2016 - 11:20

Да такой способ обсуждался, но в нем получается следующее.
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 итд и искать по тэгам
  • 1

#10 Grafnaf202

Grafnaf202

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

  • Members
  • Pip
  • 8 сообщений
  • ФИО:Иван
  • Город:Мск

Отправлено 19 февраля 2016 - 11:20

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

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

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


  • 0

#11 Grafnaf202

Grafnaf202

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

  • Members
  • Pip
  • 8 сообщений
  • ФИО:Иван
  • Город:Мск

Отправлено 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 итд и искать по тэгам

 

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


  • 0

#12 Freiman

Freiman

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 591 сообщений
  • ФИО:Андрей Адеркин
  • Город:Йошкар-Ола

Отправлено 19 февраля 2016 - 11:36

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

#13 Grafnaf202

Grafnaf202

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

  • Members
  • Pip
  • 8 сообщений
  • ФИО:Иван
  • Город:Мск

Отправлено 19 февраля 2016 - 12:39

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

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

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


  • 0

#14 Molechka

Molechka

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 224 сообщений
  • ФИО:Ольга Назина (Киселева)
  • Город:Москва


Отправлено 19 февраля 2016 - 12:52

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


  • 0
Автор сайта для начинающих тестировщиков http://testbase.ru/
Автор портала проверки названий багов http://bugred.ru/
Веду блог http://okiseleva.blogspot.com/

#15 Сергей

Сергей

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 245 сообщений
  • Город:Москва

Отправлено 19 февраля 2016 - 15:00

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


  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс


#16 Grafnaf202

Grafnaf202

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

  • Members
  • Pip
  • 8 сообщений
  • ФИО:Иван
  • Город:Мск

Отправлено 19 февраля 2016 - 15:23

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

 

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

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

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

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

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


  • 0

#17 Сергей

Сергей

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 245 сообщений
  • Город:Москва

Отправлено 20 февраля 2016 - 08:01

По п.1 у нас аналогичная ситуация, только продукт на 5 лет старше))) По п.2, думаю, зашьется начальство. Продукт старый, техдолг будет скорее всего расти, баги в итоге будут считать за спам, исходящий от тестировщиков, кторые мешают сдать продукт вовремя))) В общем, не завидую я вам с вашим старым продуктом и с вашим начальством, которое не понимало и вдруг решило понять, что делает ваш отдел. Видимо дебит с кредитом не сходится, кризис...


  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс



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

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