Что изменилось в базе данных и что нужно было проверить?
Что проверяют
Вопрос почти всегда уточняющий: вы упомянули изменение в базе, и теперь смотрят, умеете ли вы переводить правку схемы в список проверок. Проверяется системность мышления и то, видите ли вы за колонкой в таблице риск для работающего приложения.
Как отвечать
Сначала назовите изменение точно, иначе ответ расплывётся: новая таблица, новая колонка, смена типа, ограничение, индекс, перенос данных, удаление поля. Дальше проверки, привязанные к типу изменения.
- Сама миграция: прогон на копии боевых данных, сколько идёт, какие берёт блокировки, есть ли обратный сценарий. Добавление колонки со значением по умолчанию на большой таблице может встать надолго.
- Совместимость версий: переживает ли новую схему ещё не обновлённое приложение. Безопасный порядок это сначала расширить схему, потом выкатить код, потом убрать лишнее.
- Данные: количество строк до и после, корректность заполнения на краевых записях, где было пусто, дубли, разный регистр, нестандартные значения.
- Ограничения: уникальность, внешние ключи, поведение при удалении связанной записи.
- Приложение: чтение и запись через интерфейс и через API, фильтры, сортировки, выгрузки, кэши, права доступа.
- Производительность: план запроса до и после, действительно ли используется новый индекс.
Отдельно упомяните отчётность и интеграции: они читают ту же таблицу, но про изменение узнают последними.
Где спотыкаются
Проверяют только новый функционал. Правка схемы задевает старый код, который тоже читает эту таблицу, поэтому регрессия обязательна, а не по остаточному принципу.
Смотрят только в интерфейс. Если запись видна на экране, это ещё не значит, что она корректна в базе: тип, длина, кодировка, часовой пояс и NULL против пустой строки видны только в самой таблице.
Проверяют на десятке строк тестовой базы. Время выполнения, блокировки и план запроса проявляются на боевом объёме, и обратный сценарий тоже надо прогнать заранее, а не в момент инцидента.