Это золотой стандарт QA выше среднего. Когда вы перестаёте верить UI и лезете «под капот» — вы становитесь настоящим инженером. UI может врать, а логи, БД и API показывают правду.
Давайте разберём каждый слой детально.
---
1. Анализ API (Backend без интерфейса)
Что проверяете:
· Статус-коды (200 OK, 400 Bad Request, 500 Internal Error, 401 Unauthorized).
· Тело ответа (JSON/XML) — структура, типы данных, значения.
· Заголовки (Content-Type, Authorization, CORS).
· Время ответа (если > 2 сек — уже повод задуматься).
Главные инструменты:
· Postman / Insomnia — ручные запросы + коллекции автотестов.
· cURL — для быстрых проверок из консоли.
· Swagger / OpenAPI — документация, по которой вы сверяетесь.
· Charles / Fiddler — перехват трафика между фронтом и бэком (видите, что реально уходит).
Ваши действия:
1. Открываете DevTools (F12) → вкладка Network.
2. Смотрите запрос: какие параметры ушли? (Тело, заголовки, куки).
3. Смотрите ответ: соответствует ли ТЗ? (Ключ user_id вернулся?).
4. Шлёте тот же запрос напрямую в Postman — отдельно от UI, чтобы понять: баг во фронте или в бэке.
---
2. Анализ БД (База данных)
Что проверяете:
· Корректность сохранения данных после действия пользователя.
· Целостность связей (внешние ключи, каскадное удаление).
· Типы данных (не записалось ли "123" как строка в числовое поле).
· Триггеры и хранимые процедуры (логика на стороне БД).
Инструменты:
· SQL-клиенты: DBeaver, DataGrip, pgAdmin (PostgreSQL), MySQL Workbench.
· Базовые запросы: SELECT, INSERT, UPDATE, DELETE, JOIN, WHERE.
Пример на практике:
· Вы создали заказ в UI → идёте в БД:
```sql
SELECT * FROM orders WHERE user_id = 123 ORDER BY created_at DESC LIMIT 1;
```
· Проверяете: total_price совпадает с суммой товаров? status = 'NEW'? Поле created_at заполнилось?
Продвинутый уровень:
· Знаете схему БД наизусть для своего продукта.
· Можете написать запрос с несколькими JOIN, чтобы проверить сложную логику.
· Умеете читать EXPLAIN (план выполнения запроса) — если запрос тормозит.
---
3. Анализ логов (Logs)
Что это: текстовые файлы (или вывод в консоль/Kibana), куда приложение пишет все события: ошибки, предупреждения, информационные сообщения, стектрейсы.
Что ищете:
· ERROR / FATAL — явные падения.
· WARN — потенциальные проблемы (например, таймаут или повторная попытка).
· Стек вызовов (Stack Trace) — чтобы показать разработчику точное место в коде.
· Логи на уровне DEBUG — включаете, чтобы увидеть входные параметры и промежуточные вычисления.
Инструменты:
· Вручную: терминал (tail -f logs/app.log), файлы на сервере.
· Визуализация: Kibana / Grafana (централизованный сбор, поиск по времени).
· Консоль браузера (F12 → Console) — логи фронтенда.
Как читать стектрейс:
```
java.lang.NullPointerException at com.payment.PaymentService.process(PaymentService.java:42)
```
— значит, ошибка на 42-й строке в классе PaymentService. Эту информацию вы копируете в баг-репорт.
Главное правило:
· Логируйте время инцидента (чтобы найти его в общем потоке).
· Запрашивайте уровень логирования — по умолчанию часто стоит INFO, а для отладки включайте DEBUG.
---
4. Как это работает в связке (реальный сценарий)
Ситуация: Пользователь оплачивает заказ, но получает ошибку «Недостаточно средств» (хотя деньги есть).
Ваш путь как QA:
1. API: Шлёте запрос на оплату через Postman → получаете 500 Internal Error.
2. БД: Проверяете баланс пользователя (SQL) — видите, что сумма корректна.
3. Логи: Идёте в Kibana, фильтруете по времени, находите стектрейс:
SQLException: Connection timed out — проблема с сетью до БД.
4. Вывод: Баг не в логике, а в инфраструктуре. Создаёте баг-репорт, прикрепляя стектрейс и ответ API, но назначаете не разработчику, а DevOps.
---
5. Инструменты-шпаргалки
Что делаете Инструменты
Смотрите трафик DevTools (Network), Charles, Fiddler
Шлёте API-запросы Postman, Insomnia, cURL
Проверяете БД DBeaver, DataGrip, pgAdmin, MySQL Workbench
Ищете ошибки в логах Kibana, Grafana, grep, tail -f