Локализация бага — это как спорить с GPS: сначала ты думаешь, что всё дело в карте, потом проверяешь дорогу, а в итоге осознаёшь, что просто ехал не туда
На собеседованиях бывает вопрос (вопрос выдуман и является просто примером): представьте, у нас есть простая страница. На ней есть поле ввода имени и кнопка "Продолжить". Когда пользователь вводит валидное имя и нажимает на кнопку, должен появляться поп-ап с сообщением "Имя сохранено успешно", и имя сохраняется в базе данных. Однако, при тестировании выясняется: вводим валидные данные, нажимаем "Продолжить" — и ничего не происходит. Поп-ап не отображается, и пользователю непонятно, сохранилось ли имя или произошла ошибка.
Для чего задают такой вопрос?
Вопрос о локализации багов задают, чтобы понять, насколько ты умеешь не просто находить проблему, но и разбираться в её причинах. Здесь важно показать, что ты знаешь, как подойти к анализу: от проверки шагов воспроизведения и инструментов разработчика до работы с логами и базой данных. Такой вопрос помогает оценить твои технические знания, логическое мышление и способность эффективно работать с командой.
Например, ты можешь рассказать, что проверяешь не только статус-коды, но и тело запросов (не смешно! Часто слышал ответ: "смотрю код-ответа" и все), изучаешь логи сервера и базы данных, чтобы понять, где именно произошёл сбой. Или как минимизируешь шаги воспроизведения, чтобы передать разработчику максимально точное описание. Главное — дать понять, что ты не просто репортишь баги, но умеешь докопаться до их сути.
Что делать и как докопаться до сути?
Первое, что нужно сделать, — проверить, воспроизводится ли проблема стабильно. Для этого повторяем действия на разных браузерах, устройствах, пробуем другие валидные имена. Если проблема воспроизводится всегда, переходим к анализу.
Открываем инструменты разработчика в браузере (DevTools). Вкладка Console может показать, не возникает ли ошибок JavaScript. Например, бывает ошибка типа
Uncaught TypeError: Cannot read property 'clickHandler' of undefined
Это указывает на неправильную настройку обработчика кнопки. Если ошибок в консоли нет, переключаемся на вкладку Network. Нажимаем кнопку "Продолжить" и ищем запрос, который должен был отправиться на сервер. Если запрос отсутствует, проблема, скорее всего, в том, что кнопка не инициирует нужное действие.
Если запрос отправляется, проверяем его содержимое. В Network есть две ключевые вкладки: Payload и Response.
- Payload показывает, что отправил фронт. Например, это может быть запрос с параметрами вроде:
{
"name": "Анна Авось Прорвемся"
}
- Response — это то, как на этот запрос отреагировал бэкенд. Если в Response вернулись адекватные данные (например, статус 200 и все нужные поля заполнены корректно), то, скорее всего, проблема не на сервере. В таком случае даже нет смысла тратить время на проверку базы — сервер обработал всё правильно.
Чтобы ускорить процесс, можно сделать следующее:
1. Триггернуть запрос с фронта через интерфейс приложения.
2. Повторить этот же запрос в Postman.
Если ответ в обоих случаях одинаковый, то вероятность, что баг на стороне фронтенда, минимальна. Это сразу поможет сузить круг поиска.Если статус 500, причина скорее всего на стороне бэкенда, и нужно проверять логи сервера.
Следующий шаг — анализ базы данных. Проверяем, записалось ли имя в базу. Выполняем SQL-запрос, например:
SELECT * FROM users WHERE name = 'Анна Авось Прорвемся';
Если имя отсутствует, ищем ошибку: возможно, ограничения на данные (например, уникальность) или проблема с соединением базы и сервера.
Если данные в базе есть, но поп-ап не отображается, проблема, скорее всего, в фронтенде. Проверяем, запускается ли скрипт отображения поп-апа. Открываем вкладку Elements в DevTools, ищем элемент поп-апа, возможно, он просто скрыт или наложен другим элементом. Это не всегда работает, и многое зависит от технологий которые используют на проекте. Я лишь описываю шаги для рассуждения:)
продолжение в комментариях⬇️
На собеседованиях бывает вопрос (вопрос выдуман и является просто примером): представьте, у нас есть простая страница. На ней есть поле ввода имени и кнопка "Продолжить". Когда пользователь вводит валидное имя и нажимает на кнопку, должен появляться поп-ап с сообщением "Имя сохранено успешно", и имя сохраняется в базе данных. Однако, при тестировании выясняется: вводим валидные данные, нажимаем "Продолжить" — и ничего не происходит. Поп-ап не отображается, и пользователю непонятно, сохранилось ли имя или произошла ошибка.
Для чего задают такой вопрос?
Вопрос о локализации багов задают, чтобы понять, насколько ты умеешь не просто находить проблему, но и разбираться в её причинах. Здесь важно показать, что ты знаешь, как подойти к анализу: от проверки шагов воспроизведения и инструментов разработчика до работы с логами и базой данных. Такой вопрос помогает оценить твои технические знания, логическое мышление и способность эффективно работать с командой.
Например, ты можешь рассказать, что проверяешь не только статус-коды, но и тело запросов (не смешно! Часто слышал ответ: "смотрю код-ответа" и все), изучаешь логи сервера и базы данных, чтобы понять, где именно произошёл сбой. Или как минимизируешь шаги воспроизведения, чтобы передать разработчику максимально точное описание. Главное — дать понять, что ты не просто репортишь баги, но умеешь докопаться до их сути.
Что делать и как докопаться до сути?
Первое, что нужно сделать, — проверить, воспроизводится ли проблема стабильно. Для этого повторяем действия на разных браузерах, устройствах, пробуем другие валидные имена. Если проблема воспроизводится всегда, переходим к анализу.
Открываем инструменты разработчика в браузере (DevTools). Вкладка Console может показать, не возникает ли ошибок JavaScript. Например, бывает ошибка типа
Uncaught TypeError: Cannot read property 'clickHandler' of undefined
Это указывает на неправильную настройку обработчика кнопки. Если ошибок в консоли нет, переключаемся на вкладку Network. Нажимаем кнопку "Продолжить" и ищем запрос, который должен был отправиться на сервер. Если запрос отсутствует, проблема, скорее всего, в том, что кнопка не инициирует нужное действие.
Если запрос отправляется, проверяем его содержимое. В Network есть две ключевые вкладки: Payload и Response.
- Payload показывает, что отправил фронт. Например, это может быть запрос с параметрами вроде:
{
"name": "Анна Авось Прорвемся"
}
- Response — это то, как на этот запрос отреагировал бэкенд. Если в Response вернулись адекватные данные (например, статус 200 и все нужные поля заполнены корректно), то, скорее всего, проблема не на сервере. В таком случае даже нет смысла тратить время на проверку базы — сервер обработал всё правильно.
Чтобы ускорить процесс, можно сделать следующее:
1. Триггернуть запрос с фронта через интерфейс приложения.
2. Повторить этот же запрос в Postman.
Если ответ в обоих случаях одинаковый, то вероятность, что баг на стороне фронтенда, минимальна. Это сразу поможет сузить круг поиска.Если статус 500, причина скорее всего на стороне бэкенда, и нужно проверять логи сервера.
Следующий шаг — анализ базы данных. Проверяем, записалось ли имя в базу. Выполняем SQL-запрос, например:
SELECT * FROM users WHERE name = 'Анна Авось Прорвемся';
Если имя отсутствует, ищем ошибку: возможно, ограничения на данные (например, уникальность) или проблема с соединением базы и сервера.
Если данные в базе есть, но поп-ап не отображается, проблема, скорее всего, в фронтенде. Проверяем, запускается ли скрипт отображения поп-апа. Открываем вкладку Elements в DevTools, ищем элемент поп-апа, возможно, он просто скрыт или наложен другим элементом. Это не всегда работает, и многое зависит от технологий которые используют на проекте. Я лишь описываю шаги для рассуждения:)
продолжение в комментариях⬇️