Исправление багов в нескольких ветках

Всем привет! Столкнулся у себя на работе с одной проблемой.
Вот краткое описание:

Предположим, что мы выпустили версию 1.0.
По ней был зарегистрирован баг.
Решили его исправить в фиксе 1.1.
А также добавить это исправление в версию 2.0.

И вот возникают вопросы:
1. Когда считать баг закрытым?
2. Сколько раз его тестировать?

Как бы особых проблем с ответом не возникает: закрывать нужно, когда проверено исправление во всех ветках.
Однако имеется одно 'но'! Не в любом инструменте можно элементарно реализовать правильный трекинг данной ситуации.

И хотелось бы поинтересоваться: как с этим делом обстоит у других: в процедурной и реализационной плоскостях?

Всем привет! Столкнулся у себя на работе с одной проблемой.
Вот краткое описание:

Предположим, что мы выпустили версию 1.0.
По ней был зарегистрирован баг.
Решили его исправить в фиксе 1.1.
А также добавить это исправление в версию 2.0.

И вот возникают вопросы:
1. Когда считать баг закрытым?
2. Сколько раз его тестировать?

Как бы особых проблем с ответом не возникает: закрывать нужно, когда проверено исправление во всех ветках.
Однако имеется одно 'но'! Не в любом инструменте можно элементарно реализовать правильный трекинг данной ситуации.

И хотелось бы поинтересоваться: как с этим делом обстоит у других: в процедурной и реализационной плоскостях?

Добрый день.

По мне вопрос не сложный. Предложу вариант используя JIRA.
Есть Баг. Надо проверить в версии 1.1 и версии 2.0. Создаем таски на проверку этого бага в версии 1.1 и создании тест кейса для проверки его в версии 2.0. Линкуем их к багу. И пока обе таски не выполнены, бага не закрывается!
В итоге получаем, проверенный фикс для версии 1.1 и регрешн тест кейс, который должен быть пройден в версии 2.0.

Может предложенный мной вариант и излишен, но всеже он рабочий...

Спасибо

Всем привет! Столкнулся у себя на работе с одной проблемой.
Вот краткое описание:

Предположим, что мы выпустили версию 1.0.
По ней был зарегистрирован баг.
Решили его исправить в фиксе 1.1.
А также добавить это исправление в версию 2.0.

И вот возникают вопросы:
1. Когда считать баг закрытым?
2. Сколько раз его тестировать?

Привет!
Знакомая ситуация.
1. Баг считать закрытым, когда проверен во всех версиях.
2. Тестировать дважды - для двух паралельных веток

По процессу, приведу кусочек полиси, которые я составлял для багзилы.
1) Пока версия 1.0 разрабатывается все заверифицированные дефекты получают статус VERIFIED. Статус CLOSED получают только инвалиды и дубликаты.
2) Версия 1.0 зарелизилась. Намечаются версии 1.1 и 2.0. Все баги в положении VERIFIED переводятся в CLOSED (т.к. была только одна версия). Остальные (незафикшеные) меняют версию на 1.1 или 2.0, если не надо чинить в 1.1.
Имеем: для версии 1.0 есть только баги CLOSED именно в этой версии.
3.1) Баг чинится в версии 1.1 и НЕ должен быть проверен в версии 2.0 (допустим в версии 2.0 фичу полностью переписали). Девелопер переводит баг в состояние RESOLVED и ставит ему соотвествующую резолюцию (FIXED|WONTFIX|etc). Пишет ноту, что починен только в 1.1, а в версии 2.0 не имеет смысла.
3.2) Такой баг верифицируется ТОЛЬКО в версии 1.1. Получает статус VERIFIED.
4.1) Баг починен пока только в версии 1.1 и ДОЛЖЕН быть починен в версии 2.0 (возможно нужны разные фиксы). Девелопер переводит баг в состояние RESOLVED и ставит ему резолюцию REMIND.
4.2) Баг верифицируется в версии 1.1. Получает статус VERIFIED. REMIND. После этого или после окончания версии 1.1 он переоткрывается на версию 2.0.
5.1) Баг чинится одновременно в двух версиях. Девелопер переводит баг в состояние RESOLVED и ставит ему соотвествующую резолюцию (FIXED|WONTFIX|etc). Пишет ноту, что починен и в 1.1, и в 2.0.
5.2) Баг верифицируется в версии 1.1. При этом статус не меняется, а меняется версия с 1.1 на 2.0.
Т.о. получаем на момент окончания версии 1.1:
- все баги присущие только этой версии, которые починены и заверифицированы имеют статус VERIFIED и какую-то резолюцию отличную от REMIND. Их все мы можем перевести в CLOSED и забыть.
- все баги, которые починились только в этой версии, но должны быть починены в 2.0 имеют статус VERIFIED и резолюцию REMIND. Переоткрываем их на версию 2.0 (можно делать не обязательно по завершении версии 1.1).
- все баги пофикшеные в обоих версиях в момент верификации уже переползли в следующую версию и их нет в 1.1.

Естественно, все это неплохо сопровождать коментами.
И еще, необходимо ревьювить все поступающие баги. Иначе возможно пропустить дефект, записаный сразу на версию 2.0, но который должен быть починен в 1.1. За это надо бить по рукам, чтобы баги выставляли на правильную версию, коли уж взялись их параллельно разрабатывать.

И хотелось бы поинтересоваться: как с этим делом обстоит у других: в процедурной и реализационной плоскостях?

У нас дефект-трэкер поддерживает multiple release. Получается, как бы 2 разных дефекта с одним и тем же описанием и разными стэйтами. Никаких проблем нету, хоть 22 релиза параллельно разрабатывай.

[У нас дефект-трэкер поддерживает multiple release. Получается, как бы 2 разных дефекта с одним и тем же описанием и разными стэйтами. Никаких проблем нету, хоть 22 релиза параллельно разрабатывай.

Это так багзилла так позволяет или пришлось дописать часть кода самостоятельно?

Кстати, а не бывает такого, что 2.0 выходит раньше 1.1?

[У нас дефект-трэкер поддерживает multiple release. Получается, как бы 2 разных дефекта с одним и тем же описанием и разными стэйтами. Никаких проблем нету, хоть 22 релиза параллельно разрабатывай.

Это так багзилла так позволяет или пришлось дописать часть кода самостоятельно?

Нет не багзила. Багзила была раньше, на другой работе, где я был QA-лидом и посему составлял полиси работы с дефект-трэкингом. Сейчас я в Сане, а там свой супер-мощный дефект-трэкинг тул. Он не паблик. Просто привел пример, как разработчики дефект-трэкера разрулили ситуацию с несколькими релизами. Кстати, ситуация частая, а в большинстве дефект-трэкеров которые я видел о ней никто не думал - всегда приходилось с бубном плясать.

Кстати, а не бывает такого, что 2.0 выходит раньше 1.1?

Обычно 1.х версии - это небольшие багфикс релизы, а У.0 - релизы с новыми фичами.
За исключением редких ситуаций, не вижу смысла выпускать 1.1 после 2.0. Хотя у нас так иногда бывает, но на то есть своя специфика. Это бывает для библиотек, когда более старшая версия не имеет backward compatibility.

Возможна ситуация, когда после версии 1.0 стали делать 2.0, а потом решили быстренько сделать 1.1. В этом случае придется взять все баги заверифицированные на версии 2.0 до появления 1.1 и решить какие из них должны быть повторно проверены на 1.1.

ЗЫ: Как альтернативный вариант - в большинстве дефект трэкеров есть keywords - можно с помощью этого механизма разрулить несколько релизов.

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

Т.е. нечто 1.Х и нечто 2.Х - это 2 независимых продукта с точки зрения баг-трекера (что не мешает связывать баги через ссылки).

Баги 1.Х закрываются в конце ЖЦ 1.Х.

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

Багов больше, но трэкать их проще.
Хотя может это издержки наших процессов :-)

Кто может объянить, чем такой подход хуже создения нескольких инстансов одного бага?

Пару недостатков я вижу:
1. Атрибуты бага (под ними я понимаю все, что обычно вынесено в отдельные поля - номер билда, модуль, северити, приоритет, дату создания и т.п.) могут отличаться.
2. Если к багу прикладываются логи или скриншоты, то они могут в разных версиях отличаться. Я уже не говорю про дебажный вывод.