Профилактика багов
Как исправить баг
Управление багами
Профилактика багов
Как исправить баг
Управление багами
Любой баг сначала стоит повторить: найти последовательность действий, состояние или окружение, при котором баг повторяется. Повторение проблемы — это тест, которым изолируют баг и проверяют, что он исчез после исправления. Без этого шага вместо исправления получится слепая догадка, которая вряд ли исправит проблему, но точно что‑то сломает.
Чаще всего повторить баг — не проблема: достаточно открыть страницу с ошибкой или пройти по описанному сценарию. В этом случае остаётся лишь убедиться, что проблема гарантированно повторяется, и минимизировать время на проверку.
В Издательстве бюро
Если в книге проблема стабильно повторяется на отдельном развороте, стоит оставить в локальной версии книги только его. Браузеру не придётся загружать все развороты, книга станет открываться за 600 миллисекунд, а не за 6 секунд.
Чем быстрее разработчик сможет проверять изменения, тем быстрее поймёт и исправит проблему.
Если проверку можно автоматизировать тестами — ещё лучше: не надо проверять вручную; легко проверять проблемы с многопоточностью; тесты убедятся, что проблема не повторится в будущем.
В Издательстве бюро
В билинге издательства были проблемы с продлением подписок, оформленных в конце месяца. Чтобы повторить их и исправить, написали автотесты, проверяющие подписки, оформленные в проблемных случаях: 28 февраля, 29 февраля, 31 декабря, 31 января, 31 июля.
Если проблема «плавает», повторяется случайным образом, можно увеличить частоту проверок:
В тестах
Если интеграционный тест время от времени не работает, чтобы повторить проблему, я запускаю его несколько сотен раз:
while true; do bin/rspec spec/acceptance/flaky_spec.rb; doneСм. также советы
Если информации для повторения бага не хватает, стоит проверить в логах или уточнить её у клиента. Если даже с этой информацией проблема не повторяется, значит, не совпадает окружение, данные или последовательность действий. В таких случаях я стараюсь исправить несовпадение, проверяя по списку:
Приложение. Совпадает ли версия приложения у меня и клиента? Может, мы это уже исправили?
Браузер. Какой браузер у клиента? Может, это старый Сафари? Или Сафари в приватном режиме?
Плагины. Какие плагины установлены в браузере клиента? Может, это Эдблок или стили плагина влияют на страницу?
Интернет. Какой интернет у клиента? Может, проблема с загрузкой на медленных соединениях?
Мониторинг. Что в этот момент происходило в системе? Не было ли других ошибок, например, с БД или сетью?
Данные. Может, проблема в данных? Какие данные клиента используются? Что пользователь вводил в инпуты? Повторится ли проблема с ними? Нет ли чего‑то опасного в LocalStorage?
Логи. Что, судя по логам, на самом деле делал пользователь?
Последовательность действий. В правильной ли я последовательности повторяю действия? Что, если имеет значение, с какой стороны я начал перетаскивать виджет?
См. также советы
В случае с последовательностью действий важен не только их порядок и содержание, но и то, что происходило до бага:
Гугль‑почта и Эксплорер
Однажды задержали релиз на две недели из‑за того, что файлы не загружались в браузере менеджера. У тестировщиков, разработчиков, дизайнеров и остальных менеджеров всё было в порядке. Последовательность действий — та же, окружение — идеально совпадает: у менеджера и тестировщиков были идентичные корпоративные компьютеры.
Когда решили проверить, что менеджер делал до ошибки, заметили, что ссылку на страницу он открывал из личного почтового ящика в Гугль‑почте, а не из корпоративного.
Оказалось, что в Эксплорере переставала работать загрузка файлов через ифрейм, когда страница открывалась из Гугль‑почты.
Если проблема всё равно не повторяется, значит, не хватает информации. В этом случае можно попробовать отследить ошибку в обратную сторону, обратиться за помощью и добыть ещё информации.
Отследить в обратную сторону. Проводим мысленный эксперимент: мы знаем, как выглядит проблема, что могло привести к ней?
На новом сайте бюро
На новом сайте иногда не загружались картинки. Сервер принимал их, сохранял, но браузер отдавал 404. Проблему повторить не удавалось.
Чтобы повторить баг, мы начали отслеживать его в обратную сторону.
— Почему сервер отдает 404?
— Потому что картинки на самом деле нет, она не лежит в директории, где веб‑сервер ищет картинки.
— Почему её там нет?
— Потому что бэкенд не скопировал её туда.
— Почему бэкенд не скопировал её?
— Бэкенд копирует изменившиеся картинки пачкой, значит, он не заметил её.
— Почему он её не заметил?
— Возможно, она появилась, когда происходило копирование.
— Как проверить теорию?
— Запустить продолжительное копирование одновременно с загрузкой картинки.
Обратиться за помощью. Может оказаться так, что вы что‑то упускаете. В этом случае часто помогает попросить кого‑нибудь о помощи: другого разработчика, арт‑директора или менеджера.
В Издательстве бюро
Самые сложные баги в книгах мы чиним вдвоём с Рустом Кулматовым. Мы созваниваемся по Скайпу, расшариваем экран и в режиме парного программирования разбираемся с багом.
Чаще всего удаётся разобраться ещё на этапе объяснения проблемы: когда что‑то объясняешь и показываешь другому человеку, легче найти значимые условия и факты.
Добыть ещё информации. Для этого подойдут логи и автоматическое отслеживание проблем.
В Издательстве бюро
Читатели жаловались, что книги застревают и перестают листаться. Проблему повторить не удавалось.
Чтобы увидеть баг, в книги добавили автоматическое отслеживание проблемной ситуации: когда книга застревала, движок автоматически собирал информацию о браузере, размерах окна, текущем положении и отправлял разработчикам.
Только тогда заметили, что проблема повторяется на определённом размере окна с особым соотношением ширины и высоты.
Что запомнить
Сначала баг надо повторить. Если непонятно как — уточнить последовательность действий. Если не повторяется, значит, проблема связана с окружением (браузеры, плагины, интернет), данными (БД, ввод, локальное хранилище) или последовательностью действий.
Когда удалось повторить, стоит ускорить и стабилизировать процесс проверки: минимизировать тестовый сценарий или написать автоматический тест.
Если ничего не помогает, баг не повторяется, можно попробовать отследить ошибку в обратную сторону, попросить о помощи или добавить ещё логов.
Ещё по теме
P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.