После попадания баг-репорта в систему баг-трекинга, он перенаправляется ответственному разработчику. И уже на этом этапе может что-то пойти не по плану.
Баг-репорт вернули/отклонили
Баг-репорт может вернуться обратно или его могут отклонить. На это есть несколько причин.
Основные причины возврата баг-репорта:
- некачественное или непонятное описание. Баг может быть описан так, что разработчик просто не поймет, как его воспроизводить.
- такой дефект уже существует в системе. Дубляж возможен, если сразу несколько тестировщиков тестируют одну и туже фичу, например, с помощью разных туров.
- дефект не воспроизводится. Причиной тому может быть как некорректное описание шагов, так и изменения в коде, которые были сделаны после нахождения бага.
- это не баг, а фича.
- исправление таких ошибок невыгодно или неактуально для заказчика.
После отклонения бага тестировщик должен либо исправить баг-репорт и отправить его заново, либо ничего не делать, так как бага нет или такие баги не исправляются.
Баг пофикшен
После принятия баг-репорта и исправления бага его статус в системе баг-трекинга должен смениться на «решен» (fixed). Это означает, что данный баг пофикшен программистом.
________________________________
И тут вспоминает золотое правило тестирования: никому не верь на слово.
________________________________
Если разработчик пофиксил баг, то это не значит, что его нет. Нам необходимо проверить, воспроизводится ли он по тем же самым шагам, которые описаны в баг-репорте. Иными словами, мы проводим подтверждающее тестирование.
Если мы убедились, что баг не воспроизводится, то пора ли утверждать, что он исправлен? Как мы знаем, код взаимосвязан. И исправление его на одном участке может привести к изменению его работы на другом. Поэтому необходимо также провести регрессионное тестирование. Это тестирование, в рамках которого проверяется работа смежных и взаимозависимых участков кода.
Регрессионное тестирование очень полезно, но не всегда необходимо. Специалист по тестированию должен понимать, как какая-либо правка могла повлиять на функционал приложения. Чтобы это определить нужно, как минимум, посмотреть на тип бага и его сложность. Если это графический баг, то в большинстве (именно большинстве, но не всегда) случаев достаточно просто проверить его исправление. Если баг глубоко связан с логикой приложения (например, происходит ошибка при добавлении друзей в ВК), то следует более плотно проверить исправление, в том числе и просмотреть взаимодействие друзей в целом. Если у вас есть доступ к коду, то вы сможете посмотреть (опять же, если умеете разбираться в этом) в чем заключалось исправление. Либо можно уточнить у того разработчика, который делал правку.
Иными словами, регрессионное тестирование — это необязательный этап, но знать о нем нужно.
Следить за статусом баг-репорта?
Это зависит от множества факторов. Наша подписчица Алена Кругликова рассказала о нескольких из них.
Следить за статусом бага имеет смысл, если:
— вы считаете, что он критикал, а его все не исправляют, не ставят в версию,
— исправление этого бага влияет на проверку другой задачи,
— по багу предвидятся килотонны работы, и лучше сделать их «как только, так сразу», чем за 15 минут до лонча (выпуска продукта),
— вы лид и/или следить вообще ваша задача.
***
Итак, чтобы наш баг не появился в программе после его нахождения необходимо:
- Оформить баг-репорт (тут можно почитать про то, как эффективно это сделать https://sedtest-school.ru/testovaya-dokumentacziya/otchety-o-defektah-5-priznakov-plohogo-otcheta/).
- Дождаться его исправления.
- Проверить воспроизведение бага (подтверждающее тестирование).
- При необходимости проверить, пострадал ли функционал рядом (регрессионное тестирование.)
- Если баг не воспроизводится и не повлиял на взаимосвязанный функционал, то мы закрываем баг-репорт.
Выполнение этих шагов позволит нам с уверенностью говорить, что найденный нами баг исправлен.
