Всё, что помнит приложение — пользователи, заказы, товары, — хранится в базе данных. Интерфейс показывает лишь часть этого и может показать неправильно. Чтобы проверить, что данные реально сохранились и именно такими, какими нужно, тестировщик заглядывает прямо в базу. Язык, на котором с базой разговаривают, — SQL.

Не пугайтесь: чтобы проверять данные, не нужно уметь всё. Достаточно нескольких простых запросов на чтение. Разберём необходимый минимум на примере интернет-магазина.

Что такое база и таблицы

База данных чаще всего устроена как набор таблиц — как листы в Excel. У каждой таблицы есть колонки (столбцы) и строки. Например, таблица users (пользователи) с колонками id, name, email, а таблица orders (заказы) — с колонками id, user_id, amount, status.

Тестировщик обычно только читает данные (смотрит, что в таблицах), а не меняет их. Читающий запрос начинается со слова SELECT.

SELECT: показать данные

Базовый запрос — «покажи такие-то колонки из такой-то таблицы»:

SELECT id, name, email FROM users;

Это значит: «покажи колонки id, name, email из таблицы users». Звёздочка * означает «все колонки»:

SELECT * FROM orders;

Пока это просто «вывалить таблицу на экран». Дальше — как выбрать только нужное.

WHERE: отобрать нужные строки

WHERE — это фильтр, «покажи только те строки, где условие выполняется». Самое частое, что делает тестировщик: найти в базе конкретную запись, которую он только что создал через интерфейс.

SELECT * FROM users WHERE email = 'anna@example.com';

«Покажи пользователя с таким e-mail». Зарегистрировались на сайте — выполнили этот запрос — убедились, что пользователь реально появился в базе с верным именем.

Условия комбинируют:

SELECT * FROM orders WHERE user_id = 42 AND status = 'paid';

«Оплаченные заказы пользователя 42». Так проверяют, что после оплаты статус заказа в базе действительно стал paid, а не остался new.

Ещё пара полезных вещей

  • Подсчёт строк: SELECT COUNT(*) FROM orders WHERE user_id = 42; — «сколько заказов у пользователя 42». Удобно проверить, что создался ровно один заказ, а не два (частый баг двойного нажатия).
  • Сортировка: ORDER BY created_at DESC в конце — «сначала самые новые». Помогает быстро найти только что созданную запись.
  • JOIN (связка таблиц). Данные разложены по разным таблицам: заказ хранит user_id, а имя пользователя — в таблице users. JOIN соединяет их, чтобы увидеть вместе: «заказы вместе с именами покупателей». Это чуть сложнее, и на старте достаточно знать, что такое возможно, а синтаксис подсмотреть.

Запоминать команды наизусть не нужно — их легко нагуглить. Важно понимать идею: данные лежат в таблицах, SELECT ... WHERE достаёт нужное.

Осторожно с боевой базой

Три правила безопасности:

  • По возможности работайте с тестовой базой, а не с боевой (где реальные пользователи).
  • Тестировщик почти всегда только читает (SELECT). Команды, которые меняют данные (UPDATE, DELETE), трогать без явной необходимости и понимания нельзя — можно испортить данные.
  • Если доступ к базе только на боевой — будьте особенно аккуратны и не выполняйте ничего, в чём не уверены.

Где это применяется

SQL превращает проверку из «на экране вроде правильно» в «в базе точно правильно». Создали заказ — проверили, что он в базе один и с верной суммой. Оплатили — убедились, что статус сменился. Удалили — проверили, что запись исчезла (или помечена удалённой). Это серый ящик в действии и навык, который заметно повышает вашу ценность как тестировщика.

Где спотыкаются начинающие:

  • Верят только интерфейсу. На экране «заказ создан», а в базе он не сохранился или сохранился дважды — видно только запросом.
  • Боятся SQL как «программирования». На деле для проверок хватает SELECT ... WHERE — это читается почти как обычная фраза.
  • Меняют данные на боевой базе случайной командой. Читайте (SELECT), не меняйте без явной необходимости.

Что учить дальше. Осталось разобраться, почему один и тот же продукт по-разному ведёт себя в разных браузерах и на телефонах, — кроссбраузерное и мобильное тестирование.