твиттерэда

Локализация бага — это как спорить с 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, ищем элемент поп-апа, возможно, он просто скрыт или наложен другим элементом. Это не всегда работает, и многое зависит от технологий которые используют на проекте. Я лишь описываю шаги для рассуждения:)

продолжение в комментариях⬇️

🔥50❤16⚡6👍2

7.67K viewsedited 06:16