Почему использовал SQL?

Почему использовал SQL?

Как QA Engineer, я использовал и использую SQL (Structured Query Language) на протяжении всей своей карьеры, потому что это не просто инструмент, а фундаментальный навык для эффективного тестирования, особенно при работе с приложениями, управляемыми данными. Его применение напрямую влияет на глубину, качество и скорость проверок.

Ключевые причины использования SQL в тестировании:

1. Верификация данных на уровне источника (Source of Truth)

    Интерфейс приложения (UI) — это лишь представление данных. Чтобы убедиться, что бизнес-логика работает корректно, необходимо проверить сами данные в базе. SQL позволяет напрямую запросить БД и сравнить фактическое состояние с ожидаемым.
    *   **Пример:** После оформления заказа через UI нужно убедиться, что в таблице `Orders` появилась запись с правильными `status_id`, `total_amount` и `user_id`.

```sql
-- Проверка создания заказа после UI-действия
SELECT order_id, status, total_amount, customer_id
FROM orders
WHERE customer_id = 12345
ORDER BY created_at DESC
LIMIT 1;
```

2. Подготовка и очистка тестовых данных (Test Data Management)

    Ручное создание сложных тестовых сценариев через UI может занимать часы. SQL делает это за секунды. Можно напрямую вставлять, обновлять или удалять данные, необходимые для теста.
    *   **Пример:** Для тестирования функционала "Заблокированный пользователь" нужно изменить статус учётной записи.

```sql
-- Подготовка данных: блокировка пользователя
UPDATE users
SET account_status = 'BLOCKED'
WHERE email = 'test.user@example.com';

-- Очистка после теста: разблокировка
UPDATE users
SET account_status = 'ACTIVE'
WHERE email = 'test.user@example.com';
```

3. Проведение углублённых проверок, недоступных через UI

    Многие бизнес-правила, связи между сущностями (отношения в БД) и вычисляемые поля сложно или невозможно полноценно проверить через интерфейс. SQL-запросы с соединениями таблиц (`JOIN`) и агрегатными функциями незаменимы для таких проверок.
    *   **Пример:** Проверка, что итоговая сумма заказа (`order.total`) корректно совпадает с суммой всех его позиций (`order_items.subtotal`).

```sql
-- Проверка целостности данных заказа
SELECT
    o.order_id,
    o.total_amount as order_total,
    SUM(oi.quantity * oi.unit_price) as calculated_total
FROM orders o
JOIN order_items oi ON o.order_id = oi.order_id
WHERE o.order_id = 1001
GROUP BY o.order_id, o.total_amount
HAVING o.total_amount != SUM(oi.quantity * oi.unit_price);
-- Если запрос вернёт строку — есть расхождение, это дефект.
```

4. Расследование дефектов (Defect Investigation) и логирование

    Когда в логах приложения или в ошибке на UI виден ID сущности (например, `transaction_id=7890`), самый быстрый способ понять контекст и состояние связанных данных — написать целевой запрос. Это позволяет локализовать проблему: в самих данных, в логике их обработки или в API/UI слое.

1. Регрессионное и миграционное тестирование

    При обновлении схемы БД (миграции), переносе или массовом обновлении данных SQL-скрипты используются для сравнения "до" и "после". Навык чтения и написания сложных `SELECT`-запросов критически важен для валидации результатов таких операций.

Практический контекст использования:

• Автоматизация тестов: SQL-запросы интегрируются в UI или API автотесты (на Python с pymysql, Java с JDBC, etc.) для шагов подготовки данных (setUp) и ассертов.
• Тестирование ETL/BI процессов: Здесь SQL — основной инструмент. Сравниваются огромные массивы данных между источником и приёмником, проверяется качество и трансформация данных.
• Взаимодействие с командой: Общий язык SQL улучшает коммуникацию с разработчиками и аналитиками данных. Можно совместно анализировать запрос, обсуждать план выполнения (EXPLAIN) или потенциальные проблемы с производительностью, которые тоже могут быть предметом тестирования.

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