Как определить, что баг создан на Backend?

Определение принадлежности бага к Backend

Определение, что баг или проблема связана с Backend (серверной частью приложения), является ключевым навыком для QA Engineer. Это позволяет правильно классифицировать дефект, назначить его соответствующей команде разработчиков и сократить время на его устранение. Моя практика показывает, что для точной диагностики необходимо проводить системный анализ, основанный на симптомах, данных и технической проверке.

Основные признаки и методы анализа

Определить backend-баг можно по совокупности следующих признаков и используя конкретные методы:

1. Анализ симптомов на Frontend (клиентской стороне)

• Некорректные или отсутствующие данные: Если на странице или в интерфейсе отображаются неверные цифры, текст, список элементов пуст или содержит "битые" записи (например, null, undefined), это первичный признак проблемы с данными, которые приходят с сервера.
• Ошибки при отправке данных: Если форма не отправляется, а в консоли браузера или логах приложения видна ошибка типа 500 Internal Server Error, 502 Bad Gateway, 404 Not Found (для API endpoint), это явный сигнал о сбое на стороне сервера.
• Несоответствие бизнес-логики: Если система выполняет действия, противоречащие заявленным правилам (например, списывает неверную сумму, применяет неправильную скидку), ошибка чаще всего кроется в алгоритмах, реализованных на backend.

2. Проверка сетевых запросов и ответов (API)

Это наиболее прямой и объективный метод. Используя инструменты разработчика в браузере (F12, Network tab) или специализированные инструменты (Postman, Charles Proxy), необходимо:

• Проверить HTTP статус-коды ответа. Коды 5xx (500, 502, 503) указывают на ошибку сервера. Коды 4xx (400, 403, 404) могут указывать на проблемы как на backend (неверная логика валидации), так и на frontend (некорректно составленный запрос).
• Анализировать тело ответа (Response Body). Ошибка может быть явно описана в JSON или XML ответе от сервера.

{
  "status": "error",
  "message": "Database connection failed",
  "code": 500
}

• Сравнить ожидаемый и фактический ответ. Если API-контракт (Swagger/OpenAPI спецификация) определяет определенную структуру данных, а сервер возвращает что-то иное — это backend-баг.

3. Проверка независимо от Frontend

Чтобы исключить влияние клиентского кода, нужно:

• Выполнить запрос напрямую к API, минуя пользовательский интерфейс, используя Postman или cURL.

curl -X POST https://api.example.com/v1/order \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <token>" \
  -d '{"productId": 123, "quantity": 2}'

• Если при прямом запросе проблема сохраняется (возвращается ошибка или некорректные данные), это подтверждает backend-природу бага.

4. Анализ логов сервера и мониторинга

Это требует взаимодействия с DevOps или backend-разработчиками:

• Логи приложения (application logs): Сообщения об ошибках выполнения, исключениях (Exceptions), проблемах с подключением к базе данных или сторонним службам.
• Системные логи и метрики: Высокая нагрузка на CPU/память, ошибки на уровне веб-сервера (Nginx, Apache) или контейнеров (Docker/K8s).

5. Взаимодействие с данными и состоянием системы

• Проблемы, зависящие от времени или состояния: Баг, который проявляется только после выполнения определенной последовательности действий (когда в базе данных достигается некоторое состояние), или проблемы с конкуренцией (race conditions) обычно относятся к backend.
• Проблемы с производительностью: Длительная обработка запросов (высокий response time) при нормальной работе frontend — симптом проблем с оптимизацией запросов, алгоритмов или ресурсов сервера.

Практический алгоритм для QA Engineer

В своей работе я обычно следую такому алгоритму:

1. Локализовать симптом: Точно описать, что происходит на UI (например, "После нажатия 'Сохранить' появляется красное сообщение 'Internal Server Error', данные не сохраняются").
2. Открыть Network tab в браузере: Найти запрос, соответствующий действию, и проверить его статус и тело ответа.
3. Реплицировать проблему напрямую через API: Используя Postman, воспроизвести баг, чтобы исключить влияние фронтенда.
4. Собрать доказательства: Сохранить или скопировать:

    *   URL endpoint и метод запроса.
    *   Заголовки (Headers) и тело запроса (Request Payload).
    *   Статус-код и полное тело ответа (Response) с ошибкой.
    *   Время возникновения бага (для поиска в логах).

1. Сформулировать отчет: Создать bug report, который включает все вышеперечисленные технические детали, и назначить его команде backend-разработки.

Ключевое отличие: Если проблема исчезает при изменении поведения только на frontend (например, при исправлении JS-кода) — это frontend-баг. Если проблема остается при любых корректных действиях на frontend и подтверждается при прямом запросе к API — это backend-баг.

Таким образом, определение основывается не на предположении, а на технической проверке сетевого взаимодействия между клиентом и сервером и анализе ответов сервера.