Это может быть одно поле, может быть несколько:
Проявилось в версии
Вы каждые N недель выпускаете новую версию продукта: версия 1, 2, 3, 4, 5... Каждая версия чем-то отличается от прошлой (а иначе зачем она нужна?). Добавлен новый функционал, исправлены ошибки...
Соответственно, в каждой версии изменяет код. Поэтому очень важно знать, в какой версии баг проявился. А то, может, вы пытаетесь воспроизвести, а у вас не получается. И оказывается, что вы смотрите вчерашнюю сборку, в которой его еще нет. Сравнили версию приложения с указанной в баге, и обновились.
Или, наоборот, вы смотрите новую версию, а баг уже исправлен! В рамках какой-то другой задачи или рефакторинга. А что, такое тоже бывает, случайное исправление багов =)
Поэтому очень полезно указать в баге версию, на которой баг воспроизводится.
Исправить в версии
Баги не всегда исправляются сразу, как их нашли. Если баг некритичный, его могут отложить на релиз-другой. Нашли в версии 3, исправили в версии 5 — нормальная схема.
По полю «исправить в версии» задачи набираются в релиз. Мы делаем фильтр по версии и сразу видим, сколько всего туда понапихали. Смотрим, не перегружены ли разработчики и тестировщики. Что-то нужно выкинуть, потому что не успеем сделать. А что-то нужно добавить, потому что у разработчика Васи есть еще 3 свободных дня. Так версия «когда задача будет сделана» помогает в планировании.
А еще она полезна, когда у вас коробочный продукт. Это значит, что вы отдаете одну версию десяткам заказчиков. А у каждого заказчика свой процесс обновления. Кто-то обновляет версию сразу как вышла, а кто-то тестирует по полгода.
И если к вам приходят:
— Так и так, вот такая проблема есть.
Вы сначала смотрите по баг-трекеру. Вдруг ее уже находили и даже исправляли? Ага, вот она, похожая задача. Появилась в версии 2, найдена и исправлена в версии 5.
— А какая у вас версия сейчас?
— 4, вот хотим на 5 обновиться.
— Отлично, тогда этой проблемы уже не будет!
Бывает и другой вариант развития событий:
— А какая у вас версия сейчас?
— 3.
— Ошибка уже исправлена в версии 5, нужно просто обновиться.
— Нет, она блокирует нам продажи, а обновляться будем только через полгода, исправляйте сейчас.
В таком случае делается hotfix к версии 2. Разработчик прокидывает исправление ошибки из версии 5 в версию 2. Тестировщик проверяет на старой версии и отдает ее заказчику. Все довольны!
Но в любом случае знать, когда проблема исправлена, очень важно! Если в баг-трекере настроено только одно поле, то его заполняют именно как «когда будем исправлять», чтобы фильтры корректно работали. А «когда появился баг» в таком случае пишет разработчик в комментарии:
— Да этот баг уже 3 релиза живет, он с версии 2 тянется!
См также:
Как заводить задачи в баг-трекер — ведь нам не только версию надо заполнить!
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
- Проявилось в версии;
- Исправить в версии;
Проявилось в версии
Вы каждые N недель выпускаете новую версию продукта: версия 1, 2, 3, 4, 5... Каждая версия чем-то отличается от прошлой (а иначе зачем она нужна?). Добавлен новый функционал, исправлены ошибки...
Соответственно, в каждой версии изменяет код. Поэтому очень важно знать, в какой версии баг проявился. А то, может, вы пытаетесь воспроизвести, а у вас не получается. И оказывается, что вы смотрите вчерашнюю сборку, в которой его еще нет. Сравнили версию приложения с указанной в баге, и обновились.
Или, наоборот, вы смотрите новую версию, а баг уже исправлен! В рамках какой-то другой задачи или рефакторинга. А что, такое тоже бывает, случайное исправление багов =)
Поэтому очень полезно указать в баге версию, на которой баг воспроизводится.
Исправить в версии
Баги не всегда исправляются сразу, как их нашли. Если баг некритичный, его могут отложить на релиз-другой. Нашли в версии 3, исправили в версии 5 — нормальная схема.
По полю «исправить в версии» задачи набираются в релиз. Мы делаем фильтр по версии и сразу видим, сколько всего туда понапихали. Смотрим, не перегружены ли разработчики и тестировщики. Что-то нужно выкинуть, потому что не успеем сделать. А что-то нужно добавить, потому что у разработчика Васи есть еще 3 свободных дня. Так версия «когда задача будет сделана» помогает в планировании.
А еще она полезна, когда у вас коробочный продукт. Это значит, что вы отдаете одну версию десяткам заказчиков. А у каждого заказчика свой процесс обновления. Кто-то обновляет версию сразу как вышла, а кто-то тестирует по полгода.
И если к вам приходят:
— Так и так, вот такая проблема есть.
Вы сначала смотрите по баг-трекеру. Вдруг ее уже находили и даже исправляли? Ага, вот она, похожая задача. Появилась в версии 2, найдена и исправлена в версии 5.
— А какая у вас версия сейчас?
— 4, вот хотим на 5 обновиться.
— Отлично, тогда этой проблемы уже не будет!
Бывает и другой вариант развития событий:
— А какая у вас версия сейчас?
— 3.
— Ошибка уже исправлена в версии 5, нужно просто обновиться.
— Нет, она блокирует нам продажи, а обновляться будем только через полгода, исправляйте сейчас.
В таком случае делается hotfix к версии 2. Разработчик прокидывает исправление ошибки из версии 5 в версию 2. Тестировщик проверяет на старой версии и отдает ее заказчику. Все довольны!
Но в любом случае знать, когда проблема исправлена, очень важно! Если в баг-трекере настроено только одно поле, то его заполняют именно как «когда будем исправлять», чтобы фильтры корректно работали. А «когда появился баг» в таком случае пишет разработчик в комментарии:
— Да этот баг уже 3 релиза живет, он с версии 2 тянется!
См также:
Как заводить задачи в баг-трекер — ведь нам не только версию надо заполнить!
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
Комментариев нет:
Отправить комментарий