БЛОК 11. Базы данных и API — 28. SQL и API для тестировщика

🧭 Введение: зачем QA нужны SQL и API вместе

Если проверять только экран, можно пропустить половину дефектов.
Пользователь видит одно, API возвращает другое, а в базе лежит третье.
Поэтому для QA связка SQL + API — это базовый инструмент доказательного тестирования.

💡 Совет:

Смотри на SQL и API как на два окна в одну систему: API показывает контракт с клиентом, SQL показывает фактические данные.

✅ Вывод:

Чем лучше QA умеет работать с SQL и API, тем быстрее команда находит причину дефекта, а не только его симптом.

⚠️ Проблема -> решение

Проблема: junior QA часто ограничивается UI-проверкой, а при расхождении данных не может быстро понять, где именно ошибка.

Решение: строить проверку в три слоя:

UI: что видит пользователь;
API: что отдает сервер по контракту;
DB (SQL): что реально сохранено в базе.

🟢 Если совсем просто:

Баг нужно проверять не только глазами, но и через данные.

🎯 Как понять, что этап прошел успешно:

Ты можешь доказать, где именно расхождение: в интерфейсе, в API-ответе или в БД.

🛠️ Чем помогает и как работает

Связка SQL и API делает QA-проверки воспроизводимыми и технически точными.

Как это работает:

Шаг 1: QA выполняет пользовательский сценарий в UI.
Шаг 2: Через API (Postman/DevTools) фиксирует request/response и статус.
Шаг 3: SQL-запросом проверяет, в каком виде данные реально сохранились в таблицах.
Шаг 4: Сравнивает expected поведение с API и DB фактом.
Шаг 5: Формирует баг-репорт с конкретными доказательствами.

✅ Вывод:

UI + API + SQL — это практический стандарт проверки, когда важна точность и скорость диагностики.

📚 Ключевые термины (простыми словами)

SQL — язык запросов к базе данных.
SELECT — получить данные из таблицы.
WHERE — отфильтровать нужные строки.
JOIN — связать данные из нескольких таблиц.
GROUP BY — сгруппировать записи для подсчетов.
ORDER BY — отсортировать результат.
API — интерфейс обмена данными между клиентом и сервером.
Request — запрос, который клиент отправляет на сервер.
Response — ответ, который сервер возвращает клиенту.
HTTP method — тип действия (GET/POST/PUT/DELETE).
HTTP status code — код результата запроса (200, 201, 400, 401, 404, 500).
Payload — тело запроса или ответа.

1. SQL для QA: читать факты из БД

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

🟢 Если совсем просто:

SQL отвечает на вопрос: «что реально лежит в базе».

🎯 Как понять, что этап прошел успешно:

После действия в UI ты можешь SQL-запросом подтвердить, что данные записались корректно.

Назначение:

Проверять факт сохранения, изменения и связности данных.

Простыми словами:

SQL позволяет не гадать, а смотреть точное состояние системы.

Для новичка:

Если пользователь «создал заказ», SQL покажет, есть ли этот заказ в таблице и с каким статусом.

Аналогия:

Как проверка чека и остатков на складе после покупки, а не только надписи «Успешно» на кассе.

Пример:

SELECT id, user_id, status, total_amountFROM ordersWHERE id = 84721;

🔎 Как это происходит на практике:

QA выполняет действие в UI, берет order_id из ответа API и сразу проверяет ту же запись в БД.

Характеристики:

точная проверка данных;
удобен для ретеста дефектов;
помогает видеть скрытые проблемы данных.

Когда использовать:

Когда проверяешь CRUD-операции, статусы, связи между сущностями и корректность данных после API-вызова.

✅ Вывод:

SQL для QA — это про проверку фактов, а не предположений.

2. SQL-минимум для тестировщика: SELECT, WHERE, JOIN, GROUP BY, ORDER BY

Не нужно быть DBA, чтобы уверенно тестировать через базу.
Для junior QA достаточно рабочего минимума SQL-операторов.

🟢 Если совсем просто:

Пять операторов покрывают большинство ежедневных QA-проверок в БД.

🎯 Как понять, что этап прошел успешно:

Ты можешь сам собрать запрос: найти запись, отфильтровать, связать таблицы и посчитать метрику.

Назначение:

Построить базовые запросы для проверки бизнес-сценариев.

Простыми словами:

Это минимальный набор, чтобы не зависеть от «кто-нибудь из разработчиков посмотрит базу».

Для новичка:

Начни с маленьких запросов на 1 таблицу, потом добавляй JOIN и агрегаты.

Аналогия:

Сначала учишься читать карту района, потом уже строишь сложный маршрут по городу.

Пример:

SELECT u.email, o.id AS order_id, o.statusFROM users uJOIN orders o ON o.user_id = u.idWHERE o.status = 'paid'ORDER BY o.created_at DESC;

🔎 Как это происходит на практике:

QA проверяет endpoint «История заказов»: через JOIN убеждается, что список действительно относится к нужному пользователю.

Характеристики:

быстро проверяет данные в разрезе сценария;
помогает подтверждать корректность связей;
позволяет находить расхождения между UI и БД.

Когда использовать:

В API/интеграционных проверках, при валидации отчетов и при расследовании дефектов данных.

✅ Вывод:

Для junior QA уверенный SQL-минимум дает сильный прирост в качестве и скорости диагностики.

3. API для QA: request, response, методы и статусы

API-проверка показывает, как система ведет себя на уровне контракта, а не только интерфейса.

🟢 Если совсем просто:

API-тестирование — это проверка «что отправили» и «что получили».

🎯 Как понять, что этап прошел успешно:

Ты можешь для каждого метода назвать ожидаемый статус и структуру ответа.

Назначение:

Проверять корректность обмена данными между клиентом и сервером.

Простыми словами:

API — это «разговор» между приложением и сервером, и QA проверяет, что разговор проходит по правилам.

Для новичка:

Не запоминай все коды подряд. Начни с базовых: 200, 201, 400, 401, 404, 500.

Аналогия:

Как отправить заявку в сервис: важно, что ты отправил и какой официальный ответ получил.

Пример:

POST /api/orders{  "userId": 101,  "items": [{"sku":"A-1","qty":2}]}

Ожидаемо:

201 Created при успешном создании;
400 Bad Request при невалидном payload.

🔎 Как это происходит на практике:

QA прогоняет positive и negative запросы в Postman и сверяет фактические ответы с API-контрактом.

Характеристики:

проверяет бизнес-логику на уровне сервера;
быстрее выявляет интеграционные проблемы;
снижает зависимость от UI.

Когда использовать:

При тестировании backend-фич, интеграций и ретесте дефектов, которые трудно стабильно ловить через UI.

✅ Вывод:

API-проверки помогают QA ловить дефекты раньше, чем они попадут в интерфейс.

4. Связка SQL и API: главный рабочий паттерн QA

Самая сильная QA-практика — проверять не только ответ API, но и фактическое состояние БД после него.

🟢 Если совсем просто:

API говорит «что должно случиться», SQL подтверждает «что реально случилось».

🎯 Как понять, что этап прошел успешно:

После API-запроса ты доказываешь SQL-запросом, что данные в БД соответствуют контракту.

Назначение:

Исключить ложные выводы и точно локализовать источник проблемы.

Простыми словами:

Это проверка «ответ сервера = реальное состояние базы».

Для новичка:

После POST или PUT всегда делай короткий SQL-check ключевых полей.

Аналогия:

Как не только услышать «посылка отправлена», но и увидеть её в системе логистики.

Пример:

API ответил 201 и вернул order_id=84721;
SQL подтвердил, что в orders есть запись 84721 со статусом new.

🔎 Как это происходит на практике:

QA фиксирует ID сущности из API-ответа и использует его как ключ в SQL-проверке.

Характеристики:

быстро выявляет несогласованность слоев;
упрощает root-cause анализ;
усиливает доказательность баг-репорта.

Когда использовать:

Для критичных сценариев: регистрация, оплата, заказы, статусы, доступы.

✅ Вывод:

Связка SQL + API — это ключевой навык QA, который резко повышает качество расследования дефектов.

5. Что QA проверяет в SQL и API каждый день

Практика важнее теории: у тестировщика должен быть короткий рабочий чек-лист.

🟢 Если совсем просто:

Проверяй запрос, ответ, статус, запись в БД и соответствие бизнес-правилу.

🎯 Как понять, что этап прошел успешно:

По каждому дефекту есть цепочка доказательств: шаг -> API-факт -> SQL-факт.

Назначение:

Сделать QA-проверки предсказуемыми и воспроизводимыми.

Простыми словами:

Один и тот же понятный алгоритм на каждый релизный сценарий.

Для новичка:

Если не знаешь, с чего начать расследование, начни с «какой endpoint вызвали» и «какая запись должна была измениться в БД».

Аналогия:

Как чек-лист пилота перед взлётом: коротко, но обязательно.

Пример:

UI: нажали Create Order;
API: POST /api/orders -> 201;
SQL: в orders появилась запись с правильным user_id и status.

🔎 Как это происходит на практике:

QA делает targeted проверку по критичным потокам и сохраняет готовые SQL/API шаблоны для ретеста.

Характеристики:

высокая воспроизводимость;
меньше спорных дефектов;
быстрее triage и фиксы.

Когда использовать:

На smoke/sanity, ретесте и регрессе критичных бизнес-потоков.

✅ Вывод:

Системный SQL/API чек-лист делает junior QA заметно сильнее уже в первые месяцы.

🆚 Сравнение: что проверяет SQL и что проверяет API

Уровень проверки	SQL	API
Что смотрим	Данные в таблицах	Контракт request/response
Основной вопрос	Что реально сохранено?	Что сервер вернул клиенту?
Хорошо выявляет	Ошибки данных и связей	Ошибки валидации и бизнес-логики
Частый инструмент	DB client, SQL console	Postman, DevTools Network
Лучший результат	В связке с API	В связке с SQL

✅ Вывод:

SQL и API не заменяют друг друга, а закрывают разные части одной проверки.

✅ Must-know факты

SELECT + WHERE + JOIN — минимальный SQL-набор для большинства QA-задач.
Проверка только UI без API/SQL часто дает ложные выводы.
Для каждого API-метода должен быть понятен ожидаемый статус и базовый expected payload.
POST обычно создает сущность (201), GET читает (200), PUT обновляет (200/204), DELETE удаляет (200/204).
При расхождении «UI vs API vs DB» баг нужно описывать фактами из всех трех слоев.
Даже junior QA может писать полезные SQL-запросы без сложной оптимизации.

Частые мифы

❌ Миф: SQL тестировщику не нужен, это зона разработчиков.

✅ Как правильно: SQL нужен QA для проверки фактов в БД и качественного расследования дефектов.

📎 Почему это важно: Без SQL QA часто не может доказать источник проблемы.

❌ Миф: Если API вернул 200, значит всё корректно.

✅ Как правильно: Нужно проверить структуру ответа и факт записи/изменения данных в БД.

📎 Почему это важно: Статус 200 не гарантирует корректность бизнес-результата.

❌ Миф: Для API-тестирования нужно быть backend-разработчиком.

✅ Как правильно: Для junior достаточно понимать методы, базовые статусы, payload и проверку expected/actual.

📎 Почему это важно: Это даёт сильный практический эффект уже на старте карьеры.

❌ Миф: JOIN и GROUP BY слишком сложно для QA.

✅ Как правильно: Нужен не весь SQL, а рабочий минимум под реальные сценарии.

📎 Почему это важно: Этого минимума достаточно, чтобы проверять отчеты, связи и агрегаты.

Часто спрашивают на собеседованиях

❓ Вопрос: Зачем QA знать SQL, если есть UI и API? ✅ Ответ: SQL подтверждает фактические данные в БД и помогает доказать источник дефекта, когда UI и API дают разную картину.

❓ Вопрос: Какие SQL-операторы обязательны для junior QA? ✅ Ответ: Минимум: SELECT, WHERE, JOIN, GROUP BY, ORDER BY.

❓ Вопрос: Чем API-тестирование отличается от UI-тестирования? ✅ Ответ: UI проверяет пользовательский слой, API проверяет контракт и серверную логику без интерфейсных искажений.

❓ Вопрос: Что проверять после POST-запроса создания сущности? ✅ Ответ: Статус и payload ответа API, затем факт и корректность записи в БД по ключевым полям.

❓ Вопрос: Что делать, если UI показывает одно, а SQL другое? ✅ Ответ: Зафиксировать API-ответ между ними и построить цепочку доказательств по шагам сценария.

🚨 Типичные ошибки

проверять только happy path без negative API-сценариев;
путать «запрос выполнился» и «данные корректны по бизнес-правилу»;
писать SQL без фильтра и смотреть «всю таблицу»;
делать JOIN по неправильному полю и получать ложные выводы;
не фиксировать в баге environment/build/request body;
не связывать API-факт с SQL-подтверждением.

🌟 Best Practices

держи набор шаблонных QA-запросов SQL под ключевые сущности проекта;
на каждый критичный API endpoint имей positive и negative кейсы;
после create/update операций проверяй 2-3 ключевых поля в БД;
в баг-репорте указывай: шаг, endpoint, статус, payload, SQL-check;
начинай с простых SQL-запросов и усложняй только при необходимости;
всегда проверяй смысл данных, а не только наличие строки.

🧾 Заключение

Тема SQL и API для тестировщика — это про переход от «проверил глазами» к «доказал фактами».
Когда QA умеет читать API-контракт и проверять данные SQL-запросами, он быстрее локализует баги и делает релизные выводы увереннее.

✅ Вывод:

Для junior QA базовый SQL + API — это один из самых практичных навыков, который сразу повышает качество ежедневной работы.

БЛОК 11. Базы данных и API — 28. SQL и API для тестировщика

БЛОК 11. Базы данных и API — 28. SQL и API для тестировщика

🧭 Введение: зачем QA нужны SQL и API вместе

⚠️ Проблема -> решение

🛠️ Чем помогает и как работает

📚 Ключевые термины (простыми словами)

1. SQL для QA: читать факты из БД

2. SQL-минимум для тестировщика: SELECT, WHERE, JOIN, GROUP BY, ORDER BY

3. API для QA: request, response, методы и статусы

4. Связка SQL и API: главный рабочий паттерн QA

5. Что QA проверяет в SQL и API каждый день

🆚 Сравнение: что проверяет SQL и что проверяет API

✅ Must-know факты

Частые мифы

Часто спрашивают на собеседованиях

🚨 Типичные ошибки

🌟 Best Practices

🧾 Заключение

Проверьте знания