Что проверял техническим запросом

Анализ технических запросов в QA: что, зачем и как проверять

Технический запрос — это не просто проверка «работает/не работает», а комплексная экспертиза, направленная на анализ внутренней логики системы, её состояния и поведения. Он выходит за рамки функционального тестирования UI и затрагивает бэкенд-логику, интеграции, данные и инфраструктуру.

Что именно проверяют техническим запросом?

1. Валидация бизнес-логики и состояния данных

Проверяется соответствие фактического состояния системы ожидаемому после выполнения операций. Пример: После создания заказа через API проверяется, что статус в БД изменился на PENDING, сумма списалась с баланса пользователя, а в связанной таблице order_items появились записи о товарах.

-- Пример запроса для проверки состояния данных
SELECT order_status, total_amount FROM orders WHERE order_id = 12345;
SELECT balance FROM users WHERE user_id = 100;

• Цель: Убедиться, что бизнес-правила выполняются корректно на уровне данных, а не только интерфейса.

2. Диагностика и воспроизведение дефектов

Когда баг сложно или невозможно воспроизвести через UI (например, проблема с таймингами или race condition), технический запрос помогает найти «следы» в логах или БД. Пример: Пользователь жалуется на пропавшее уведомление. QA анализирует таблицу notifications и логи message-брокера (Kafka/RabbitMQ), чтобы понять, на каком этапе цепочки произошёл сбой.

3. Проверка интеграций и взаимодействия микросервисов

В современной распределённой архитектуре критически важно проверить, что сервисы общаются корректно. Пример: После действия в Сервисе A проверяется, что Сервис B получил событие (через очередь или прямой вызов) и обработал его.

# Пример проверки логов конкретного микросервиса
kubectl logs deployment/payment-service --tail=50 | grep "Order 12345"

4. Тестирование API на уровне HTTP/протокола

Это проверка:

• Корректности HTTP-статус кодов (200, 400, 401, 500).
• Структуры и валидности JSON/XML ответов (соответствие схеме).
• Работы заголовков (headers), авторизации (токены), пагинации.
• Граничных и ошибочных сценариев (невалидные входные данные, превышение лимитов).

# Пример кода для проверки API с помощью pytest/requests
import requests
import json

def test_create_order():
    headers = {'Authorization': 'Bearer token123'}
    payload = {'items': [{'id': 1, 'qty': 2}]}
    response = requests.post('https://api.shop.com/v1/orders', json=payload, headers=headers)
    
    assert response.status_code == 201, f"Expected 201, got {response.status_code}"
    response_data = response.json()
    assert 'orderId' in response_data
    assert response_data['status'] == 'PENDING'

5. Нагрузочное и стресс-тестирование (подготовка и анализ)

Технический запрос здесь — это проверка метрик до, во время и после нагрузки: потребление CPU/памяти, рост очередей, время ответа БД, появление ошибок 5xx. Пример: Запускается нагрузка на эндпоинт /checkout. Параллельно мониторятся логи базы данных на предмет медленных запросов (slow query log).

6. Проверка конфигураций и feature flags

Убедиться, что новый функционал, включённый через feature toggle, действительно активен для определённой группы пользователей или в конкретном окружении. Пример: Запрос к конфигурационному сервису или БД, чтобы проверить значение флага new_payment_gateway_enabled для user_id=500.

Почему это важно?

• Глубокая диагностика: Позволяет найти корневую причину (root cause) дефекта, а не только его внешнее проявление.
• Раннее обнаружение дефектов: Многие критические ошибки (например, в расчётах или целостности данных) можно выявить ещё до тестирования UI.
• Автоматизация: Технические проверки (API, БД) легко автоматизируются и включаются в CI/CD пайплайн.
• Взаимопонимание с разработкой: Общий технический контекст и язык (логи, SQL, метрики) улучшают коммуникацию в команде.

Таким образом, технический запрос — это мощный инструмент в арсенале QA-инженера, позволяющий проводить белое и серое тестирование системы, обеспечивая её качество на всех уровнях: от сетевого протокола до бизнес-логики в базе данных.