Ответ.

Тестирование миграции данных необходимо при переходе на новые версии приложений, когда изменяется структура базы данных, объекты хранения или логика преобразования данных.

История вопроса

Эволюция приложений требует регулярных обновлений, переезда с устаревших систем и внесения архитектурных изменений. Обычно миграция данных считается технической задачей, однако без должного контроля к тестировщикам регулярно поступают инциденты — от утерянных до некорректно преобразованных данных.

Проблема

Основные сложности:

потеря или искажение данных в процессе миграции;
несовместимость новых данных/структуры с бизнес-логикой нового релиза;
отсутствие чётких критериев успешной миграции.

Решение

Правильный процесс ручного тестирования включает:

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

Ключевые особенности:

Cross-check разных вариантов данных: от простых до агрегированных и исторических;
Проверка целостности и связи: важна не только точная миграция, но и сохранность связей между таблицами, полями, сущностями;
Протоколирование процесса миграции: все этапы должны быть задокументированы для воспроизводимости и возможного отката.

Вопросы с подвохом.

Можно ли использовать полностью синтетические данные для тестирования миграции?

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

Достаточно ли сравнения общего количества записей до и после миграции для подтверждения корректности?

Нет. Количество записей может совпадать при ошибках преобразования или потере полноты данных. Важно анализировать содержимое и корректность полей.

Нужно ли проверять миграцию на пустой базе?

Обязательно. Такая проверка выявляет граничные сценарии ошибок (например, пустые справочники, отсутствие ключевых записей).

Типовые ошибки и анти-паттерны

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

Пример из жизни

Негативный кейс

В процессе миграции проверили только "свежие" пользоватеские данные. Ошибки логики выявились позднее, когда потребовались редко используемые исторические данные (например, старые заказы).

Плюсы:

Быстрая валидация на этапе тестирования

Минусы:

Потеря исторических данных, вмешательство команды поддержки
Долгое выявление цепочки ошибок

Позитивный кейс

Были созданы выборки с реальными и архивными (анонимизированными) данными, а миграция тестировалась как на них, так и на пустой и сильно фрагментированной базе.