Блог седого тестировщика

говориМ о тестировании
простым языком

Когда баг можно считать исправленным?

Время на прочтение: 2 мин.
Что происходит после того, как баг-репорт попал в систему баг-трекинга? Значит ли это, что баг будет точно исправлен? Или все же это надо как-то дополнительно проверить? Давайте разбираться.

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

Баг-репорт вернули/отклонили

Баг-репорт может вернуться обратно или его могут отклонить. На это есть несколько причин.

Основные причины возврата баг-репорта:

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

После отклонения бага тестировщик должен либо исправить баг-репорт и отправить его заново, либо ничего не делать, так как бага нет или такие баги не исправляются.

Баг пофикшен

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

________________________________
И тут вспоминает золотое правило тестирования: никому не верь на слово.
________________________________

Если разработчик пофиксил баг, то это не значит, что его нет. Нам необходимо проверить, воспроизводится ли он по тем же самым шагам, которые описаны в баг-репорте. Иными словами, мы проводим подтверждающее тестирование.

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

Регрессионное тестирование очень полезно, но не всегда необходимо. Специалист по тестированию должен понимать, как какая-либо правка могла повлиять на функционал приложения. Чтобы это определить нужно, как минимум, посмотреть на тип бага и его сложность. Если это графический баг, то в большинстве (именно большинстве, но не всегда) случаев достаточно просто проверить его исправление. Если баг глубоко связан с логикой приложения (например, происходит ошибка при добавлении друзей в ВК), то следует более плотно проверить исправление, в том числе и просмотреть взаимодействие друзей в целом. Если у вас есть доступ к коду, то вы сможете посмотреть (опять же, если умеете разбираться в этом) в чем заключалось исправление. Либо можно уточнить у того разработчика, который делал правку.

Иными словами, регрессионное тестирование — это необязательный этап, но знать о нем нужно.

Следить за статусом баг-репорта?

Это зависит от множества факторов. Наша подписчица Алена Кругликова рассказала о нескольких из них.

Следить за статусом бага имеет смысл, если:
— вы считаете, что он критикал, а его все не исправляют, не ставят в версию,
— исправление этого бага влияет на проверку другой задачи,
— по багу предвидятся килотонны работы, и лучше сделать их «как только, так сразу», чем за 15 минут до лонча (выпуска продукта),
— вы лид и/или следить вообще ваша задача.

***

Итак, чтобы наш баг не появился в программе после его нахождения необходимо:

  1. Оформить баг-репорт (тут можно почитать про то, как эффективно это сделать https://sedtest-school.ru/testovaya-dokumentacziya/otchety-o-defektah-5-priznakov-plohogo-otcheta/).
  2. Дождаться его исправления.
  3. Проверить воспроизведение бага (подтверждающее тестирование).
  4. При необходимости проверить, пострадал ли функционал рядом (регрессионное тестирование.)
  5. Если баг не воспроизводится и не повлиял на взаимосвязанный функционал, то мы закрываем баг-репорт.

Выполнение этих шагов позволит нам с уверенностью говорить, что найденный нами баг исправлен.

Vkontakte
Facebook
LinkedIn
Twitter

Автор статьи:

Подписаться
Уведомить о
guest
0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии

Ближайшие события

Ближайшие события