Ошибка 404, 500 и другие: зачем тестировщику понимать бэкенд

Каждый тестировщик видел 404, 500 или 403 десятки раз. Эти ошибки приходят не из браузера — их возвращает сервер. А значит, за каждым таким числом стоит конкретный ответ бэкенда на ситуацию. Тестировщику нужно понимать, как работает серверная часть и какую информацию она пытается сообщить.

✨ Читай внимательно, в статье спрятано слово! Если соберёшь фразу, сможешь принять участие в розыгрыше сертификата Ozon! Подробнее о розыгрыше мы писали здесь.

Видимая проблема: пользователь переходит по ссылке и не находит страницу.

Суть проблемы: сервер получил запрос, но не нашёл этот маршрут или ресурс. Это может указывать на неверный URL, неправильные параметры, отсутствие объекта в базе или обращение к устаревшему URL/endpoint.

Что делает тестировщик

• Проверяет корректность URL/endpoint по документации и требованиям;
• Смотрит параметры запроса: ID, query-параметры, обязательные части пути;
• Проверяет наличие ресурса в системе или базе — существует ли вообще объект, который пытаются получить;
• Сопоставляет со спецификацией, должен ли в этой ситуации возвращаться именно 404;
• Формирует технический баг-репорт: какой запрос делался, что получили, что ожидали.

Видимая проблема: приложение перестало реагировать или выдало ошибку.

Суть проблемы: сервер получил запрос, но не смог его обработать корректно. Это может быть вызвано необработанными исключениями, ошибками в логике приложения, проблемами с базой данных, таймаутами при обращении к внешним сервисам или некорректными входными данными.

Что делает тестировщик

• Проверяет, при каких данных и каком запросе возникает ошибка;
• Сверяет поведение со спецификацией — что сервер должен возвращать при таких условиях;
• Смотрит тело HTTP-ответа (если сервер его отдаёт) — есть ли подсказка о причине;
• Проверяет корректность входных данных: формат, типы, длины, обязательные поля;
• Формирует баг-репорт, указав конкретный запрос, условия возникновения и гипотезу (например, проблема в валидации или в обработке ответа внешнего сервиса).

Видимая проблема: пользователь видит сообщение о запрете доступа.

Суть проблемы: сервер понял запрос, но отказывается его выполнять — у пользователя нет прав, роль или токен не дают доступ к ресурсу, либо действует бизнес-ограничение.

Что делает тестировщик

• Проверяет права пользователя, роль, состояние токена;
• Сравнивает поведение с требованиями: должен ли пользователь с такими правами иметь доступ;
• Проверяет запрос с другими учётными данными, чтобы понять границы доступа;
• Уточняет, корректно ли реализована логика RBAC/ABAC;
• Формирует баг-репорт с указанием конкретных условий, при которых доступ должен быть разрешён или запрещён.

Видимая проблема: пользователь не может выполнить действие из-за отсутствия авторизации.

Суть проблемы: отсутствует или просрочен токен, неверные данные авторизации, либо фронтенд отправляет запрос без необходимого заголовка. Ошибки 403 и 401 кажутся похожими, но их суть разная: 401 означает отсутствие или некорректность авторизации, а 403 — отсутствие прав при корректной авторизации.

Что делает тестировщик

• Проверяет, есть ли токен в запросе, его корректность и срок действия;
• Смотрит, правильно ли фронтенд прикладывает заголовок Authorization;
• Тестирует запрос с новым токеном, чтобы исключить проблему на стороне клиента;
• Проверяет логику обновления (refresh) токена;
• Формирует баг-репорт с указанием, какой токен использовался, какой ответ ожидался.

Видимая проблема: при отправке формы сервер возвращает ошибку и шепчет, что данные некорректны.

Суть проблемы: сервер получил запрос, но данные не прошли валидацию — неверный формат, отсутствуют обязательные поля, нарушены бизнес-правила.

Что делает тестировщик

• Проверяет, какие поля и значения отправляются — совпадают ли они со спецификацией;
• Смотрит тело HTTP-ответа — какие именно поля сервер считает некорректными;
• Проверяет валидацию на фронтенде: есть ли расхождения между UI и серверными требованиями;
• Пробует отправить корректные данные, чтобы понять границы валидности;
• Формирует баг-репорт, указав конкретное поле/условие, которое вызывает ошибку.

Выше мы разобрали наиболее популярные ошибки и действия тестировщика. Этим инструкциям обычно следуют тестировщики уровня middle и senior. Начинающие специалисты уточняют необходимую информацию у разработчика или старшего тестировщика. Это нормально, но для дальнейшего роста нужно изучать, как устроен бэкенд. Это поможет тебе:

- снизить количество ложных багов,
- быстрее находить первопричину ошибки (root cause),
- повысить качество баг-репортов,
- вырасти до middle/senior.

• 400 — Bad Request: сервер не понял запрос из-за неверного формата или некорректных параметров.
• 405 — Method Not Allowed: метод запроса (GET, POST и другие) не разрешён для данного ресурса.
• 408 — Request Timeout: сервер не получил полный запрос вовремя.
• 409 — Conflict: конфликт данных, например, попытка создать объект с уже существующим уникальным значением.
• 429 — Too Many Requests: клиент отправляет слишком много запросов за короткое время.
• 502 — Bad Gateway: сервер получил некорректный ответ от другого сервиса или шлюза.
• 503 — Service Unavailable: сервис временно недоступен (например, на обслуживании или перегружен).
• 504 — Gateway Timeout: сервер не получил ответ от внешнего сервиса вовремя.

Начинающим тестировщикам не нужно с первого дня разбираться во всех нюансах. А самый первый шаг для карьеры QA-инженера: обучение. Приглашаем тебя на курс с гарантией трудоустройства. Все подробности на нашем сайте.