Когда продукт работает неправильно, причина далеко не всегда в UI или API. Очень часто проблема сидит в данных: запись создалась не полностью, обновление не сохранилось, статусы разъехались, связь нарушилась, миграция прошла криво, дубликаты появились там, где их быть не должно. Именно поэтому database testing для QA - это не "что-то для DBA", а отдельный слой проверки качества продукта.
Хороший тестировщик не обязан быть администратором базы, но он должен понимать, что данные живут по своим правилам и могут ломаться независимо от того, насколько аккуратно выглядит интерфейс.
Что такое database testing
Database testing - это проверки, которые помогают понять, правильно ли система записывает, хранит, читает, обновляет и удаляет данные.
Речь не только про ручные SQL-запросы. Это шире:
- →что реально записалось после действия пользователя
- →соответствует ли состояние данных ожиданию
- →не появились ли дубли
- →не потерялись ли связи
- →не нарушена ли целостность
- →корректно ли отрабатывают транзакции
- →не ломают ли миграции существующие данные
Если API ответил 200, это ещё не значит, что в базе всё хорошо. Иногда UI и API выглядят "нормально", а внутри уже накопилось плохое состояние, которое вылезет позже.
Почему это важно QA
Потому что данные - это фундамент продукта. На них опираются:
- →интерфейс
- →отчёты
- →интеграции
- →уведомления
- →аналитика
- →биллинг
- →права доступа
- →фоновые процессы
Если база хранит неконсистентное состояние, дальше начинает ломаться всё вокруг.
Для QA database testing особенно полезен в сценариях, где есть:
- →сложные бизнес-переходы
- →цепочки статусов
- →фоновые джобы
- →интеграции
- →финансовые операции
- →массовые изменения
- →миграции и релизы схемы
- →подозрение на race condition или потерю обновлений
Что обычно проверяют
- →запись данных после create/update/delete операций
- →соответствие данных тому, что обещает UI и API
- →корректность связей между сущностями
- →отсутствие лишних или осиротевших записей
- →соблюдение ограничений уникальности
- →корректность значений по умолчанию
- →корректность soft delete или hard delete
- →целостность после ошибок и rollback
- →состояние данных после фоновых процессов
- →корректность миграций схемы и данных
Для QA это не значит, что нужно каждый раз лезть в базу руками. Но в сложных сценариях доступ к данным даёт очень сильную диагностическую опору.
Где чаще всего ломается
- →заказ в UI создан, но часть связанных записей отсутствует
- →пользователь удалён, но зависимые сущности остались сиротами
- →статус в API один, а в базе другой
- →после retry операция создала дубликаты
- →отчёт показывает неправильные числа из-за битых данных
- →миграция добавила колонку, но старые записи остались в несовместимом состоянии
- →транзакция завершилась с ошибкой, но часть изменений всё равно сохранилась
- →concurrent update затёр изменения другого пользователя
Такие дефекты плохо видны, если смотреть только на один экран. Но они становятся гораздо понятнее, когда QA умеет проверить фактическое состояние данных.
Что важно QA
- →проверять не только результат на экране, но и источник этого результата
- →смотреть на связи
- →думать о транзакционности
- →помнить про фоновую обработку
Если сценарий критичен, полезно убедиться, что данные реально созданы и находятся в правильном состоянии.
Ограничения и целостность
Одна из самых полезных тем в database testing - это ограничения.
- →primary key
- →foreign key
- →unique constraint
- →not null
- →check constraint
- →transaction isolation
- →каскадные правила обновления и удаления
Для QA важно не уходить глубоко в администрирование, а понимать смысл этих защит. Если в базе нет реальных ограничений там, где они нужны, продукт легче приходит в неконсистентное состояние. Если ограничения есть, полезно понимать, как они проявляются на уровне API и бизнес-сценариев.
Например, если email должен быть уникальным, важно проверить не только красивую ошибку на форме, но и то, что в базе реально нельзя получить два активных пользователя с одним и тем же ключом.
Практический пример
Представь создание заказа.
После успешного действия пользователь видит заказ в интерфейсе. Но для QA этого мало. В базе может ожидаться сразу несколько вещей:
- →создана основная запись заказа
- →созданы order items
- →сохранён статус
- →зафиксирован владелец
- →записаны суммы
- →созданы или обновлены связанные сущности
- →не осталось временных черновиков
- →аудит или история событий записались корректно
Теперь представь, что на одном из шагов случилась ошибка. Что должно произойти?
- →заказ не должен появиться вообще
- →или заказ может сохраниться как draft/failed
- →или часть данных допускается сохранить для последующего восстановления
Вот здесь database testing становится особенно важным. Он позволяет проверить не просто "есть объект или нет", а соответствует ли итоговое состояние бизнес-правилам системы.
Что должен вынести QA из этой темы
- →Database testing - это проверка качества состояния данных, а не только SQL-запросы.
- →UI и API могут выглядеть корректно даже при сломанных данных под капотом.
- →Особенно важно проверять связи, ограничения, транзакционность и последствия ошибок.
- →Критичные сценарии полезно проверять на уровне фактического состояния данных, а не только через экран.
- →QA не обязан быть DBA, но обязан видеть данные как отдельный слой риска и качества.
Что ещё почитать
- →Внутри базы: Negative API testing
- →Внутри базы: Pagination, Filtering, Sorting
- →Внешний материал: PostgreSQL constraints