Применялись ли скрипты для изменения структуры базы данных

Что проверяют

Считаете ли вы миграции частью релиза, которую надо тестировать, а не только делом разработчиков. Смотрят, что проверяете до применения, как ловите проблемы на объёме и помните ли, что во время выкатки одновременно живут две версии кода.

Как отвечать

Да, изменения схемы едут скриптами: нумерованные файлы или инструмент вроде Liquibase, Flyway, Alembic, с журналом применённых версий. Что проверяю как тестировщик:

• миграция прогоняется на копии боевой схемы с реальным объёмом, а не на пустой базе: там же вылезает блокировка таблицы и долгое создание индекса, в PostgreSQL спасает create index concurrently;
• данные проходят новое ограничение: до not null нужен бэкофилл, до уникального индекса поиск дублей;
• совместимость версий: сначала добавляем колонку, потом пишем в обе, и только следующим релизом убираем старую. Старый код обязан пережить новую схему;
• откат: есть ли обратный скрипт и проверен ли он, а если откат невозможен, это решение принято осознанно;
• повторный запуск не ломает базу: скрипт идемпотентен или защищён журналом версий.

После применения: сверка структуры (колонки, типы, индексы, ограничения), сравнение выборок до и после на тестовом наборе, дымовые проверки API поверх изменённых таблиц.

Где спотыкаются

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

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

Считают базу чужой зоной и не заглядывают в скрипты. Без доступа хотя бы на чтение проверять нечего, и дефект находится после релиза. Просить такой доступ и участвовать в ревью миграций входит в работу тестировщика.