понедельник, 27 января 2020 г.

Заполняем версию в баге

Это может быть одно поле, может быть несколько:

  • Проявилось в версии;
  • Исправить в версии;




Проявилось в версии

Вы каждые N недель выпускаете новую версию продукта: версия 1, 2, 3, 4, 5... Каждая версия чем-то отличается от прошлой (а иначе зачем она нужна?). Добавлен новый функционал, исправлены ошибки...

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


Или, наоборот, вы смотрите новую версию, а баг уже исправлен! В рамках какой-то другой задачи или рефакторинга. А что, такое тоже бывает, случайное исправление багов =)

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


Исправить в версии

Баги не всегда исправляются сразу, как их нашли. Если баг некритичный, его могут отложить на релиз-другой. Нашли в версии 3, исправили в версии 5 — нормальная схема.

По полю «исправить в версии» задачи набираются в релиз. Мы делаем фильтр по версии и сразу видим, сколько всего туда понапихали. Смотрим, не перегружены ли разработчики и тестировщики. Что-то нужно выкинуть, потому что не успеем сделать. А что-то нужно добавить, потому что у разработчика Васи есть еще 3 свободных дня. Так версия «когда задача будет сделана» помогает в планировании.

А еще она полезна, когда у вас коробочный продукт. Это значит, что вы отдаете одну версию десяткам заказчиков. А у каждого заказчика свой процесс обновления. Кто-то обновляет версию сразу как вышла, а кто-то тестирует по полгода.

И если к вам приходят:

— Так и так, вот такая проблема есть.

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

— А какая у вас версия сейчас?
— 4, вот хотим на 5 обновиться.
— Отлично, тогда этой проблемы уже не будет!

Бывает и другой вариант развития событий:

— А какая у вас версия сейчас?
— 3.
— Ошибка уже исправлена в версии 5, нужно просто обновиться.
— Нет, она блокирует нам продажи, а обновляться будем только через полгода, исправляйте сейчас.

В таком случае делается hotfix к версии 2. Разработчик прокидывает исправление ошибки из версии 5 в версию 2. Тестировщик проверяет на старой версии и отдает ее заказчику. Все довольны!

Но в любом случае знать, когда проблема исправлена, очень важно! Если в баг-трекере настроено только одно поле, то его заполняют именно как «когда будем исправлять», чтобы фильтры корректно работали. А «когда появился баг» в таком случае пишет разработчик в комментарии:

— Да этот баг уже 3 релиза живет, он с версии 2 тянется!

См также:
Как заводить задачи в баг-трекер — ведь нам не только версию надо заполнить!


PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков

Комментариев нет:

Отправить комментарий