Тестирование миграции данных в Microsoft Dynamics 365: практический подход и типичные ошибки
Миграция данных — это процесс переноса информации из одного источника в другой. На первый взгляд может показаться, что достаточно перенести записи и убедиться, что они присутствуют в новой системе. Однако на практике этого недостаточно.
Данные могут быть перенесены не полностью, значения полей могут измениться, связи между записями могут быть потеряны, а бизнес-логика после миграции может работать некорректно.
Поэтому задача QA-специалиста — проверить не только факт переноса данных, но и их целостность, соответствие требованиям и корректную работу системы после миграции.
В этой статье рассмотрим, как организовать тестирование миграции данных в Microsoft Dynamics 365, какие проверки выполнять и как выявлять потенциальные проблемы до запуска системы в продуктивную среду.
А узнать больше можно в нашем видео:
Подготовка к тестированию миграции
Перед началом тестирования необходимо определить, какие данные переносятся, по каким правилам выполняется миграция и какой результат считается правильным.
1. Документ сопоставления полей
Один из ключевых документов при миграции — mapping document, или документ сопоставления полей. Он определяет, как поля исходной сущности соответствуют полям целевой.
Документ может содержать:
названия полей исходной и целевой сущностей;
правила преобразования значений;
значения по умолчанию и правила обработки пустых значений;
правила переноса lookup- и choice-полей;
правила переноса статусов;
перечень полей, которые не переносятся.
Этот документ служит основой для проверки корректности миграции. Если значение в целевой записи отличается от исходного, с его помощью можно определить, является ли это ошибкой или ожидаемым результатом преобразования.
2. Scope и сопоставление записей
Необходимо определить, какие записи должны быть перенесены, какие исключаются из миграции и как обрабатываются записи, которые не удалось перенести.
Также важно определить ключ для сопоставления исходных и целевых записей. Для этого можно использовать уникальный идентификатор или другое согласованное поле. Полагаться только на название записи не рекомендуется, поскольку оно может повторяться или изменяться.
В рассматриваемом примере идентификаторы не менялись, поэтому кейсы из стандартной таблицы можно было напрямую сопоставлять с записями в кастомной таблице.
3. Исходные данные и инструменты
До миграции следует зафиксировать базовые показатели:
общее количество записей в согласованном scope;
количество записей с различными статусами;
значения критических полей;
связи с другими сущностями.
Для проверки данных в Dynamics 365 можно использовать Advanced Find и Views, FetchXML, экспорт в Excel или CSV, а также CRM Toolbox и другие доступные средства автоматизированного сравнения данных.
Выбор инструментов зависит от объема данных и технических возможностей проекта. При этом следует учитывать, что стандартные представления могут показывать только активные записи, поэтому закрытые кейсы необходимо проверять отдельно.
Также важно заранее определить порядок пробных запусков, правила повторной или дельта-миграции и необходимость заморозки изменений в исходной сущности. Пробные запуски помогают выявить проблемы до финального переноса.
Проверка полноты переноса и значений полей
Первый этап после миграции — убедиться, что все записи из согласованного scope присутствуют в целевой сущности.
Для этого необходимо сравнить количество записей с учетом согласованных исключений. Однако одинаковое количество не гарантирует успешную миграцию: одна запись могла быть пропущена, а другая — продублирована.
Поэтому важно сопоставлять конкретные записи по определенному ключу и проверять отсутствие неожиданных дубликатов и лишних записей.
Следующий шаг — проверка значений полей. Для каждой перенесенной записи необходимо сравнить исходные и целевые значения в соответствии с mapping document.
Особое внимание следует уделить:
текстовым и числовым полям;
датам и времени;
boolean- и choice-полям;
lookup-полям;
пустым значениям;
системным полям.
Не все значения должны переноситься буквально. Например, choice-поле в целевой сущности может использовать другие числовые коды. В таком случае необходимо проверять соответствие правилам сопоставления, а не просто равенство кодов.
Для дат важно учитывать формат, часовой пояс и точность значений. Также следует заранее определить, какие системные данные должны сохраняться, например дата создания записи и пользователь, который ее создал. В зависимости от способа миграции целевая запись может отражать момент переноса, а не исторические данные исходного кейса.
Проверка связей и связанных данных
В Dynamics 365 записи часто связаны через lookup-поля и relationships. Например, кейс может быть связан с контактом, аккаунтом, владельцем или другими объектами системы.
Недостаточно убедиться, что lookup-поле заполнено. Необходимо проверить, что оно ссылается на правильную запись, все обязательные связи сохранены, а связанные записи доступны для открытия.
Проверка должна охватывать и обратные зависимости. Например, отчеты, дашборды и интеграции, которые ранее использовали стандартную сущность Incident, могут потребовать изменений для работы с новой таблицей.
Отдельно необходимо проверить связанные данные кейса:
активности, звонки и задачи;
заметки и вложения;
SLA;
элементы очередей и connections.
Для каждого типа данных следует убедиться, что информация перенесена в соответствии с требованиями и привязана к правильной целевой записи.
Проверка статусов, владельцев и прав доступа
В Dynamics 365 статус записи влияет на ее доступность и возможность выполнения определенных действий. Поэтому необходимо проверить перенос статуса и Status Reason с учетом их взаимосвязи и настроек целевой сущности.
Например, статусы закрытого кейса в стандартной сущности Incident могут отличаться от статусов в кастомной сущности DNL Case. Важно убедиться, что сопоставление выполнено правильно и недопустимые комбинации статуса и Status Reason отсутствуют.
Также необходимо проверить, что открытые кейсы доступны для дальнейшей работы, закрытые остаются закрытыми в соответствии с требованиями, а разрешенные переходы между статусами работают корректно.
Отдельного внимания требуют владельцы и права доступа. Даже правильно перенесенная запись может оказаться недоступной нужному пользователю или иметь неправильного владельца.
Следует проверить наличие соответствующего пользователя или команды в целевой среде, состояние учетной записи владельца и его принадлежность к бизнес-подразделению.
Проверять доступ необходимо не только под системным администратором, но и под пользователями с типичными ролями безопасности. Административные права могут скрывать проблемы, с которыми столкнутся обычные пользователи.
Проверка автоматизаций и пользовательского интерфейса
После миграции важно убедиться, что система работает корректно не только на уровне данных, но и на уровне бизнес-логики.
На поведение записей могут влиять:
плагины и workflows;
Power Automate flows;
Business Rules и JavaScript;
Business Process Flows;
интеграции с другими системами.
Если автоматизации были отключены во время миграции, необходимо проверить их работу после восстановления. Если они оставались включенными, следует убедиться, что не возникли нежелательные последствия: повторные письма клиентам, лишние активности или дубликаты.
Завершающий этап — проверка через пользовательский интерфейс. Необходимо убедиться, что записи открываются, значения полей отображаются корректно, формы и связанные списки работают, необходимые команды доступны, а представления и фильтры показывают ожидаемые данные.
Также следует проверить, что при редактировании и сохранении записей не возникают ошибки.
Три уровня тестирования миграции
Чтобы сделать процесс тестирования системным, его можно разделить на три уровня.
Уровень 1. Проверка общей картины.
Сравниваются количество записей в исходной и целевой сущностях, распределение по статусам и доступные сведения об ошибках миграции. Это помогает быстро выявить значительные расхождения, но не гарантирует корректность каждой записи.
Уровень 2. Сравнение конкретных записей.
Записи сопоставляются по определенному ключу, а значения полей проверяются по mapping document. По возможности рекомендуется автоматизировать сравнение всех записей.
Если используется выборка, она должна включать открытые и закрытые кейсы, различные статусы, записи с пустыми и заполненными lookup-полями, разных владельцев и нестандартные значения.
Уровень 3. Проверка работы системы.
Проверяется, как перенесенные данные работают в Dynamics 365: открываются ли кейсы, доступны ли связанные записи, корректно ли работают статусы и разрешенные бизнес-операции.
Сочетание всех трех уровней позволяет оценить качество миграции как с точки зрения данных, так и с точки зрения реального пользователя.
Типичные дефекты и критерии успешной миграции
При тестировании миграции данных могут возникать следующие проблемы:
Пропущенные или дублированные записи.
Некорректные значения полей.
Потерянные связи или ссылки на неправильные записи.
Ошибки переноса статусов и Status Reason.
Потеря заметок, вложений или активностей.
Проблемы с владельцами и правами доступа.
Нежелательные действия автоматизаций, включая повторную отправку писем и создание дубликатов.
Миграцию можно считать успешно протестированной, если выполнены согласованные критерии приемки:
все записи в согласованном scope перенесены либо имеют задокументированное объяснение исключения;
критические поля соответствуют mapping document;
связи и связанные данные сохранены;
статусы и владельцы перенесены корректно;
права доступа и основные бизнес-процессы работают правильно;
формы, представления и команды функционируют без критических ошибок;
выявленные дефекты исправлены или согласованы с ответственными лицами;
отсутствуют открытые дефекты с критическим или высоким приоритетом;
результаты проверок и оставшиеся риски задокументированы;
повторный запуск не приводит к созданию дубликатов.
Эти критерии необходимо согласовать до начала миграции, чтобы команда понимала, при каких условиях результат можно принять.
Заключение
Тестирование миграции данных в Microsoft Dynamics 365 — это комплексная проверка полноты переноса, корректности значений, связей между записями, статусов, владельцев, прав доступа, бизнес-логики и пользовательского интерфейса.
Главное, что следует помнить: количество записей — это только начало проверки.
Чтобы убедиться в качестве миграции, необходимо сопоставлять записи по ключам и правилам mapping document, проверять связанные данные и тестировать систему от имени обычного пользователя, а не только администратора.
Пробные запуски, согласованные критерии приемки и системный подход к проверкам помогают обнаружить проблемы до перехода в продуктивную среду.
Успешная миграция — это не просто перенос данных, а уверенность в том, что данным можно доверять и что система продолжает работать корректно после переноса.
Comments