> For the complete documentation index, see [llms.txt](https://vladislaveremeev.gitbook.io/qa_bible/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://vladislaveremeev.gitbook.io/qa_bible/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-migracii-dannykh-etl.md).

# Тестирование миграции данных (ETL)

**ETL** (Extract, Transform, Load) - это процесс, объединяющий три этапа: извлечение, преобразование и загрузка данных из одного источника в другой, т.е. процесс перемещения данных из одного места в другое, из одного формата в другой или из одного приложения в другое. Как правило, это результат внедрения новой системы или места хранения данных. Бизнес-драйвером обычно является миграция или консолидация приложений, при которых устаревшие системы заменяются или дополняются новыми приложениями, использующими тот же набор данных.

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

**ETL-тестирование** - это вид тестирования, выполняемый для гарантии того, что данные, перенесенные из исходной в целевую базу данных, являются точными и соответствуют действующим правилам преобразования.

Пример:

Давайте рассмотрим пример слияния двух компаний - компании A и компании B. После слияния их операции будут объединены, а их клиенты, сотрудники и другие данные будут храниться в единой централизованной базе данных. Предположим, что компания A использует базу данных Oracle для хранения всей информации, а компания B использует MySQL. Теперь для объединения своей информации обе компании могут использовать процесс ETL для переноса данных из своих отдельных баз данных в одну согласованную базу данных. В процессе ETL, поскольку две базы данных различны, данные обеих компаний будут в разном формате, будут использоваться разные соглашения об именах, будут использоваться разные структуры таблиц и так далее. Из-за этих различий компаниям необходимо удостовериться, что перед загрузкой данных в целевую базу данных она была должным образом очищена и может сформировать нужный формат. При тестировании ETL тестировщики должны убедиться, что:

* данные обеих баз данных были преобразованы в формат целевой базы данных;
* необходимые функции преобразования были выполнены;
* в процессе не было потеряно никаких данных, и данные являются точными.

**Миграция состоит из 7 этапов:**

* Premigration planning: Оценить перемещаемые данные на предмет стабильности;
* Project initiation: Определить и проинструктировать ключевых лиц, принимающих решения;
* Landscape analysis: Создайте надежный процесс управления правилами качества данных и проинформируйте бизнес о целях проекта, включая отключение устаревших систем;
* Solution design: Определите, какие данные необходимо переместить, а также качество этих данных до и после перемещения.
* Build & test: Закодируйте логику миграции и протестируйте миграцию с копией рабочей среды.
* Execute & validate: Продемонстрируйте, что миграция соответствует требованиям и что перемещенные данные пригодны для использования в бизнесе.
* Decommission & monitor: Выключите и утилизируйте старые системы.

Это может показаться огромным объемом работы, но не все эти шаги необходимы для каждой миграции. Каждая ситуация уникальна, и каждая компания подходит к решению задачи по-своему.

**Как разработать стратегию тестирования переноса данных?**

Учитывая эту сложность, точное тестирование должно начинаться задолго до фактического переноса данных, чтобы обеспечить необходимый уровень осведомленности и ресурсов. Чтобы гарантировать, что проект получит необходимое ему внимание, сосредоточьтесь на самом провокационном элементе миграции - на том факте, что устаревшая система будет отключена. Надежная стратегия тестирования обязательна!

Следовательно, этапы стратегии тестирования теста миграции, которые будут проводиться , могут быть классифицированы как Pre-Migration Testing; Migration Testing; Post Migration Testing.

**Тестирование перед миграцией (Pre-Migration testing)**

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

* Установите четкий объем данных - какие данные должны быть включены, какие данные должны быть исключены, какие данные требуют преобразования/конвертации и т. д.;
* Выполнение сопоставление данных (data mapping) между устаревшим и новым приложением - для каждого типа данных в устаревшем приложении сравните соответствующий тип в новом приложении, а затем сопоставьте их - Сопоставление более высокого уровня (Higher level mapping);
* Изучите схему данных нового приложения - имена полей, типы, минимальные и максимальные значения, длину, обязательные поля, проверки на уровне полей и т. д.;
* Изучите интерфейсы в новом приложении и их подключения. Данные, проходящие через интерфейс, должны быть надежно защищены и настроены;
* Подготовьте тестовые случаи, тестовые сценарии и используйте их для новых условий в новых приложениях;
* Выполните набор тестовых случаев с набором пользователей и сохраните результаты, журналы. То же самое необходимо проверить после того, как произошла миграция, чтобы убедиться, что устаревшие данные и функциональность не повреждены;
* Количество данных и записей должно быть четко записано, его необходимо проверить после миграции, чтобы доказать, что никакие данные не были потеряны.

**Миграционное тестирование (Migration testing)**

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

Запись фактического времени, затраченного на миграцию с момента начала миграции до успешного восстановления системы, является одним из тестовых случаев, которые необходимо выполнить, и, следовательно, «Время, необходимое для миграции системы», должно быть записано в final test report, который будет предоставлен как часть результатов миграционного тестирования, и эта информация будет полезна во время запуска в прод. Время простоя, записанное в тестовой среде, экстраполируется для расчета приблизительного времени простоя в работающей системе. Именно в устаревшей системе будет выполняться миграция.

Во время этого тестирования все компоненты среды обычно отключаются и удаляются из сети для выполнения действий по миграции. Следовательно, необходимо отметить «Время простоя», необходимое для теста миграции. В идеале оно будет таким же, как и время миграции. Как правило, действия по миграции, определенные в документе «Руководство по миграции» (Migration Guide), включают:

* Фактическая миграция приложения;
* Брандмауэры, порты, хосты, аппаратные и программные конфигурации - все они изменяются в соответствии с новой системой, на которую переносится старая версия;
* Утечки данных, проверки безопасности;
* Проверяется связность между всеми компонентами приложения;

Тестировщикам рекомендуется проверить вышеизложенное в бэкенде системы или путем проведения тестирования белого ящика. После завершения миграции все серверы будут запущены, и будут выполнены базовые тесты, связанные с проверкой успешной миграции, что гарантирует, что все сквозные системы правильно подключены и все компоненты взаимодействуют друг с другом, БД запущен и работает, фронт успешно взаимодействует с бэком. Эти тесты должны быть идентифицированы заранее и записаны в документе «Спецификация тестов миграции» (Migration Test Specification document). Есть вероятность, что программное обеспечение поддерживает несколько разных платформ. В таком случае Миграцию необходимо проверять на каждой из этих платформ отдельно. Проверка сценариев миграции будет частью теста миграции.

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

**Тестирование после миграции (Post-Migration testing)**

После успешной миграции приложения вступает в действие тестирование после миграции. Здесь сквозное тестирование системы выполняется в тестовой среде. Тестировщики выполняют определенные тестовые наборы, тестовые сценарии, варианты использования с устаревшими данными, а также с новым набором данных. В дополнение к этому, есть определенные элементы, которые необходимо проверить в перенесенных средах:

* Все устаревшие данные перенесены в новое приложение в течение запланированного времени простоя. Чтобы убедиться в этом, сравните количество записей между устаревшим и новым приложением для каждой таблицы и представлений в базе данных;
* Все изменения схемы (поля и таблицы добавлены или удалены) в соответствии с новой системой обновлены;
* Данные, перенесенные из устаревшего приложения в новое, должны сохранять свое значение и формат, если только это не указано отдельно. Чтобы убедиться в этом, сравните значения данных между устаревшей и новой базами данных приложения;
* Перенесенные данные в новом приложении. Охватите здесь максимальное количество возможных причин. Для обеспечения 100% охвата проверки переноса данных используйте инструмент автоматизированного тестирования ;
* Безопасность базы данных;
* Целостность данных для всех возможных записей выборки;
* Ранее поддерживаемые функции в устаревшей системе работают должным образом в новой системе;
* Поток данных в приложении, который охватывает большинство компонентов;
* Интерфейс между компонентами должен быть тщательно протестирован, поскольку данные не должны изменяться, теряться и искажаться при прохождении через компоненты. Для проверки этого можно использовать интеграционные тестовые случаи;
* Избыточность устаревших данных. Никакие устаревшие данные не должны дублироваться во время миграции;
* Случаи несоответствия данных, такие как изменение типа данных, изменение формата хранения и т. д.;
* Все проверки на уровне поля в устаревшем приложении также должны выполняться в новом приложении;
* Любое добавление данных в новое приложение не должно отражаться на устаревшем;
* Обновление данных устаревшего приложения через новое приложение должно поддерживаться. После обновления в новом приложении оно не должно отражаться на устаревшем;
* Удаление данных устаревшего приложения в новом приложении должно поддерживаться. После удаления в новом приложении оно также не должно удалять данные в устаревшем;
* Убедитесь, что изменения, внесенные в устаревшую систему, поддерживают новые функции, предоставляемые как часть новой системы;
* Убедитесь, что пользователи устаревшей системы могут продолжать использовать как старые, так и новые функциональные возможности, особенно те, которые связаны с изменениями. Выполнение тестовых случаев и результатов тестирования, сохраненных во время тестирования перед миграцией;
* Создайте новых пользователей в системе и проведите тесты, чтобы убедиться, что функциональность как старого, так и нового приложения поддерживает вновь созданных пользователей и работает нормально;
* Проведите тесты функциональности на различных выборках данных (разные возрастные группы, пользователи из разных регионов и т.д.);
* Также необходимо проверить, включены ли «Флаги функций» для новых функций, а их включение/выключение позволяет включать и выключать функции;
* Тестирование производительности важно для того, чтобы убедиться, что переход на новые системы/программное обеспечение не ухудшил производительность системы;
* Также требуется проведение нагрузочных и стресс-тестов для обеспечения стабильности системы;
* Убедитесь, что обновление программного обеспечения не открыло никаких уязвимостей в системе безопасности, и, следовательно, проведите тестирование безопасности, особенно в той области, где в систему были внесены изменения во время миграции;
* Удобство использования - это еще один аспект, который необходимо проверить, в котором, если макет графического интерфейса пользователя / интерфейсная система изменились или изменилась какая-либо функциональность, какова простота использования, которую конечный пользователь чувствует по сравнению с устаревшей системой;

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

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

Источники:

* [What is Data Migration Testing](https://blog.qatestlab.com/2021/08/11/what-is-data-migration-testing/)

Доп. материал:

* Как QA в управлении хранилища данных эволюционировал: [часть 1](https://habr.com/ru/company/tinkoff/blog/543416/), [часть 2](https://habr.com/ru/company/tinkoff/blog/547990/)
* [Top 20 ETL Testing Interview Questions & Answers](https://www.softwaretestingmaterial.com/etl-testing-interview-questions/)
* [ETL Testing or Data Warehouse Testing Tutorial: What is ETL?](https://www.guru99.com/utlimate-guide-etl-datawarehouse-testing.html)