Планирование реализации Power BI: проверка содержимого

Примечание.

Эта статья входит в серию статей по планированию реализации Power BI. В этой серии основное внимание уделяется интерфейсу Power BI в Microsoft Fabric. Общие сведения о серии см. в статье о планировании реализации Power BI.

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

• Центр превосходства (COE) и группы бизнес-аналитики: команды, ответственные за надзор за Power BI в организации. К этим командам относятся лица, принимающие решения, которые решают, как управлять жизненным циклом содержимого Power BI. Эти команды также могут включать руководителей выпусков, которые обрабатывают жизненный цикл выпусков содержимого и инженеров, которые создают и управляют компонентами, необходимыми для эффективного использования и поддержки управления жизненным циклом.
• Создатели контента и владельцы контента: пользователи, которые создают содержимое, которое они хотят опубликовать на портале Fabric, чтобы поделиться с другими пользователями. Эти лица отвечают за управление жизненным циклом создаваемого содержимого Power BI.

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

Примечание.

Обычно выполняется итерация на двух и трех этапах в последующих циклах разработки и проверки.

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

На следующем рисунке показан жизненный цикл содержимого Power BI, выделение этапа 3, где выполняется проверка содержимого.

Примечание.

Общие сведения об управлении жизненным циклом контента см . в первой статье этой серии.

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

• Миграция в Power BI: проверка содержимого. В этой статье описываются ключевые аспекты и решения по проверке при переходе на Power BI из других технологий.
• Планирование решения бизнес-аналитики: проверка содержимого. В этой статье описывается планирование итеративных циклов разработки и проверки при планировании решения Power BI или Fabric.

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

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

• Функциональные возможности: являются ли элементы и компоненты, составляющие решение, функциональными. Примером функциональности тестирования является то, может ли семантическая модель завершить запланированное обновление.
• Точность данных: завершены ли цифры и результаты в соответствии с бизнес-ожиданиями. Пример проверки точности данных заключается в том, соответствует ли значение в отчете известному базовому плану.
• Производительность: создает ли запросы минимальное влияние на доступные ресурсы пользователей или время ожидания пользователя. Примером производительности тестирования является надежное обновление потока данных без достижения времени ожидания или длительности обновления.
• Безопасность: неавторизованные лица ограничены просмотром или доступом к информации или всему решению. Примером проверки безопасности является олицетворение пользователя или роли при проверке безопасности на уровне строк (RLS).
• Эффективность: решает ли решение соответствующую бизнес-проблему или процесс, и достаточно поддерживает бизнес-цели в зависимости от предполагаемого. Примером эффективности тестирования является сбор отзывов пользователей при проведении проверки принятия пользователей (UAT).
• Специальные возможности: соответствует ли решение известным стандартам специальных возможностей, чтобы оно было возможно для использования как можно большим количеством людей. Пример тестирования специальных возможностей — проверка, что отчет соответствует проверка списку специальных возможностей отчета Майкрософт.

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

Примечание.

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

Решите, как создатели должны проверять содержимое

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

Примечание.

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

Существует два способа проверки содержимого создателями контента.

• Ручное тестирование. Тесты вручную включают в себя проверку содержимого вручную, через субъективную оценку или по сравнению с некоторыми целевыми критериями тестирования. Ручные тесты легко выполнять, но они подвержены человеческой ошибке или предвзятости. Кроме того, когда содержимое достигает определенного масштаба, ручные тесты могут стать трудоемкими для правильного выполнения. Вы можете проводить ручное тестирование двумя способами.
  • Независимая проверка, которая включает в себя тестирование собственного содержимого, например семантических моделей и отчетов.
  • Одноранговая проверка, которая включает в себя субъективную оценку содержимого, чтобы критически оценить решение и предоставить предложения по улучшению его.
• Автоматическое тестирование: автоматизированные тесты включают предварительно подготовленный тест, который оценивается автоматически без вмешательства человека. Как правило, автоматизированные тесты проверка части кода решения для конкретных тестов или базовых показателей. Автоматическое тестирование сложнее выполнять и занимает много времени и усилий для настройки. Однако автоматизированное тестирование является важным в корпоративных сценариях , чтобы обеспечить качество и надежность крупных реализаций и критически важных для бизнеса решений.

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

Проведение ручного тестирования

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

Ниже приведены некоторые рекомендации по тестированию собственного содержимого.

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

В следующих разделах описаны другие ключевые аспекты для ручного тестирования.

Тестирование семантических моделей вручную

Семантические модели являются важной частью решения в Fabric и Power BI, так как они являются источником вышестоящий для отчетов, панелей мониторинга и других клиентских инструментов и рабочих нагрузок Fabric. Таким образом, перед развертыванием важно проверить семантические модели.

Ответы на такие вопросы, как приведенные ниже, чтобы помочь вам проверить семантику модели.

• Содержат ли таблицы непредвиденные отсутствующие, повторяющиеся или неправильные значения?
• Возвращают ли меры DAX ожидаемые результаты без длительного времени запроса?
• Выполняется ли запланированное обновление успешно без длительного времени обновления?
• Вы наблюдаете (пусто) приводит к визуальным элементам, фильтрам или результатам запросов, вызванным нарушениями целостности ссылок?
• Может ли безопасность данных, например RLS или безопасность на уровне объектов (OLS), достаточно предотвратить доступ несанкционированных лиц к модели или ее данным?
• Упорядочены ли объекты модели (например, меры DAX или столбцы таблицы) в папки отображения?

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

• Power BI Desktop: Power BI Desktop позволяет проверять различные аспекты семантических моделей с помощью различных функций. Примеры функций Power BI Desktop, которые упрощают тестирование семантических моделей, включают:
  • Визуальный холст: функциональность и точность модели тестирования с помощью визуальных элементов перетаскивания.
  • Представление запроса DAX: точность модели тестирования и код DAX с запросами DAX, которые можно сохранить и повторно использовать позже.
  • Запрос диагностика. Проверка производительности обновления путем получения диагностических сведений о том, как запросы оцениваются в Power Query.
• Структура: функции и элементы на портале Fabric позволяют проверять аспекты семантической модели после развертывания в рабочей области.
  • Безопасность: проверка безопасности модели путем олицетворения ролей безопасности или пользователей.
  • Записные книжки: функции и точность модели тестирования с помощью семантической связи.
  • Центр мониторинга: тестирование и мониторинг обновления данных семантических моделей и других элементов данных Fabric.
• Сторонние инструменты: сторонние средства позволяют проверять другие аспекты семантической модели, предоставляя более подробные сведения или другие функции, которые упрощают проверку. Примеры сторонних средств, которые упрощают тестирование семантических моделей, включают:
  • DAX Studio: протестируйте и оптимизируйте производительность кода DAX, получая подробные разбивки времени выполнения запросов DAX и планы запросов.
  • Табличный редактор: проверка и отладка кода DAX путем получения подробных сведений о том, как вычисляются запросы DAX и какой контекст оценки активен.

Совет

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

Кроме того, можно использовать представление запросов DAX и сторонние средства, такие как DAX Studio, для проверки и оптимизации запросов DAX для отчетов и оценки с разбивкой на страницы карта.

Тестирование отчетов вручную

Отчеты — это распространенный способ взаимодействия пользователей с данными. Многие пользователи зависят от отчетов, чтобы принимать решения и принимать меры для достижения прогресса в достижении своих бизнес-целей. Таким образом, важно проверить отчеты перед развертыванием.

Ответы на такие вопросы, как приведенные ниже, чтобы помочь вам проверить отчеты.

• Выполняют ли отчеты документированные бизнес-требования?
• Используются ли правильные типы визуальных элементов для решения правильного вопроса?
• Очищаются ли страницы отчетов без чрезмерного количества цветов или слишком много визуальных элементов?
• Работает ли отчет должным образом при фильтрации до узкого подмножества данных?
• Разрешает ли отчет экспорт в Excel, а если да, то позволяет ли он получать суммированные данные или базовые данные?
• Можно ли использовать отчет для перекрестной детализации или персонализации визуальных элементов?

Вы можете использовать различные инструменты и подходы для проверки отчетов.

• Power BI Desktop: Power BI Desktop позволяет проверять различные аспекты отчетов с помощью различных функций. Ниже приведены примеры функций Power BI Desktop, которые упрощают тестирование отчетов:
  • Визуальный холст: тестирование функциональных возможностей отчета с помощью срезов, фильтров и других интерактивных элементов.
  • Анализатор производительности: тестирование производительности отчета путем измерения времени обработки визуальных элементов и запросов DAX. Вы можете скопировать визуальные запросы DAX из анализатора производительности для использования в других средствах и сохранить результаты производительности для документации.
  • Моделирование ограничений запросов: тестирование производительности отчета путем имитации ограничений памяти в емкости, в которой она будет развернута.
• Структура: функции и элементы на портале Fabric позволяют проверять аспекты отчета после его развертывания в рабочей области.
  • Обновление приложения: проверка функциональных возможностей отчетов и безопасности при распространении отчетов в приложениях Power BI и настройке разных аудиторий приложений, чтобы определить, кто может просматривать содержимое. При использовании аудиторий приложений вы можете предварительно просмотреть отчеты, к которым они будут иметь доступ, и проверить взаимодействие с приложением самостоятельно.
  • Режим чтения в рабочей области или приложении: проверка функциональности отчета и точности с помощью его в той же среде, что и пользователь.

Примечание.

Вы можете разрабатывать и проверять панели мониторинга только на портале Fabric.

Внимание

Важно протестировать отчеты как в Power BI Desktop, так и после развертывания на портале Fabric. Визуальная отрисовка может вести себя по-разному на локальном компьютере по сравнению с отчетами в рабочей области Fabric. Кроме того, помните, что пользовательский интерфейс использования отчета из рабочей области или приложения значительно отличается от использования отчета в Power BI Desktop.

Тестирование вручную путем выполнения одноранговой проверки

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

Примечание.

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

Совет

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

Существуют различные способы проведения одноранговой проверки.

• Функциональный обзор: функциональный обзор фокусируется на функциях, процессах или бизнес-требованиях, которые должно соответствовать решению. В функциональной проверке рецензенты используют решение, как если бы они были конечным пользователем. Они документируют любые дефекты или проблемы, которые они находят, вместе с любой субъективной критикой для улучшения реализации.
• Технический обзор: технический обзор фокусируется на технических аспектах решения, таких как моделирование данных, код или проектирование. В техническом обзоре рецензенты оценивают, как были реализованы определенные функции или изменения, а также предлагают альтернативные подходы или выделяют потенциальные недостатки или риски для текущего подхода.
• Запрос на вытягивание. При выполнении управления версиями создается запрос на вытягивание (PR), чтобы объединить изменения в последнюю версию решения. Технический владелец проверяет предлагаемые изменения и оценивает исходный код. Этот вид проверки полезен для обеспечения соблюдения стандартных соглашений, таких как форматирование кода DAX или M, определение антишаблоны или потенциально проблемный код.

Совет

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

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

Автоматизация тестирования

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

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

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

Внимание

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

Совет

Автоматическое тестирование наиболее полезно при интеграции с развертыванием решения в сценариях публикации содержимого предприятия. Например, можно автоматизировать тестирование с помощью Azure Pipelines в рамках конвейера проверки, что гарантирует готовность к развертыванию содержимого. Дополнительные сведения см . на этапе 4. Развертывание содержимого.

В следующих разделах описываются основные рекомендации по автоматическому тестированию семантических моделей и отчетов Power BI.

Автоматизация тестирования семантических моделей

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

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

• Анализатор рекомендаций (BPA): Анализатор рекомендаций позволяет указать правила, которые можно использовать для оценки семантической модели. Вы можете запустить BPA с помощью табличного редактора, который определит нарушения правил в семантической модели. Вы можете автоматизировать проверка для нарушений правил BPA с помощью интерфейса командной строки редактора табличных таблиц (CLI) вместе с Azure DevOps или в рамках другого запланированного процесса.
• Записные книжки Fabric и семантическая ссылка:Записные книжки в Fabric позволяют использовать семантические ссылки для программного взаимодействия с семантических моделей. Записные книжки можно использовать для запуска платформ, таких как большие ожидания (GX), для проверки данных. Кроме того, можно оценить меры и запросы DAX, а затем протестировать результаты на основе известных базовых показателей.
• Power Automate:Power Automate позволяет выполнять запросы к семантической модели и экспортировать отчеты с помощью REST API Power BI. Вы можете проверка результаты запроса к известным базовым планам, а затем выполнить нижестоящие действия, такие как активация оповещений владельцам содержимого.

Совет

Рассмотрите возможность объединения автоматизированного тестирования и оркестрации семантических моделей. Например, вы можете выполнять автоматизированные тесты в источнике данных и семантической модели перед обновлением с помощью записных книжек или Power Automate. Если тесты завершаются ошибкой, можно запретить обновление, что также может предотвратить ошибки обновления или неверные данные, поступающие в бизнес-отчеты.

Автоматизация тестирования отчетов

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

Вы можете использовать различные средства и подходы для автоматизации тестирования отчетов.

• Анализаторы рекомендаций отчета: существуют различные сторонние средства, поддерживающие функциональность анализатора рекомендаций для автоматизации обнаружения проблем в отчетах путем изучения определения отчета. Двумя средствами, поддерживающими эту функцию, являются PBI Обозреватель и инспектор PBI.
• Power Automate Desktop: средства автоматизации пользовательского интерфейса, такие как Selenium для Python или Power Automate Desktop , позволяют имитировать взаимодействие пользователей с отчетами. Определив поток пользователя, вы можете протестировать навигацию и взаимодействие. Эти тесты проходят, когда они могут завершить поток, и завершаются сбоем, когда они обнаруживают определенные слова или изображения на экране (например, сообщение об ошибке или пустой визуальный элемент).

Определите, как пользователи должны проверять содержимое

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

Проверка пользователей обычно выполняется в тестовой рабочей области. При настройке тестовой рабочей области учитывайте следующие аспекты.

• Создание тестового приложения: если вы планируете распространять содержимое с помощью приложения Power BI, настройте тестовое приложение для тестовых пользователей для проверки содержимого. Тестовое приложение должно совпадать с приложением, которое вы настроили в рабочей среде. В навигации тестового приложения рассмотрите возможность включения ссылок на документацию, обучение и формы обратной связи.
• Доступ к подготовке: определите подмножество пользователей из сообщества, которые будут проверять решение. Обратитесь к этим пользователям и сформируйте соглашение о том, когда и почему они должны проверить это содержимое. Затем убедитесь, что вы предоставляете им доступ к содержимому и добавляете их в соответствующие роли безопасности. Поделитесь ссылками на содержимое или тестовое приложение пользователями, чтобы они могли приступить к тестированию.
• Настройка запланированного обновления: проверка пользователей обычно охватывает более длительный период. Рекомендуется настроить запланированное обновление элементов данных в тестовой рабочей области, чтобы пользователи тестировали последние данные.

Внимание

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

Примечание.

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

Перед началом проверки пользователей необходимо провести необходимые подготовки.

• Планирование при выполнении проверки пользователей.
• Укажите, ограничивается ли проверка пользователем определенным периодом или частью итеративного процесса.
• Создайте метод для сбора отзывов, например с помощью Microsoft Forms.
• Обмен данными с пользователями, участвующими в проверке планирования и ожиданий.
• Упорядочение старта проверки для пользователей, чтобы управлять ожиданиями пользователей и управлять ими.
• Провести обучение для пользователей, чтобы продемонстрировать процесс проверки и обратной связи.

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

• Тестирование обсерватории: тесты обсерватории являются короткими сеансами, где создатели содержимого смотрят один или несколько пользователей использовать содержимое без инструкций или инструкций. В этих сеансах создатели содержимого используют свои наблюдения для выявления потенциальных недостатков, проблем или улучшений решения. Эти тесты могут быть ценными, так как они требуют мало времени и усилий для организации, и могут быть ограничены определенными функциями или частями решения. Тесты обсерватории наиболее полезны для получения ранних отзывов о проектировании или подходе, например с подтверждением концепции (POC).
• Тестирование фокус-группы: тесты группы фокусировок являются ограниченными сеансами, организованными с небольшой группой пользователей, которые проходят содержимое вместе. Эти фокус-группы курируются для выбора ключевых заинтересованных лиц и экспертов по темам, которые могут предоставлять лучшие отзывы о некоторых функциях или функциях. Тесты группы фокусировок могут выполняться по нескольким интерактивным сеансам. Тестирование фокус-группы требует больше времени и усилий, чем тестирование обсерватории, но может предоставить более подробные отзывы о решении.
• Тестирование принятия пользователей:Проверка принятия пользователей (UAT) — это формальный процесс, в котором большая группа лиц из сообщества пользователей проверяет и предоставляет асинхронную обратную связь о решении. UAT требует больше всего времени и усилий для организации, но это самый тщательный способ проведения тестирования пользователей. Когда тестовые пользователи принимают решение и проблемы обратной связи, содержимое можно развернуть в рабочей рабочей области.

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

Контрольный список . При планировании проверки содержимого, ключевых решений и действий включаются:

• Условия проектирования и тестирования документов: описание тестов, которые вы будете проводить, что они тестируют, и как они будут выполняться.
• Определите процесс одноранговой проверки: опишите, кто еще проверит содержимое в стороне от себя.
• Определите подход к ручному тестированию: определите, какие инструменты и функции будут использоваться для проверки создаваемого содержимого.
• Определите, будет ли вы использовать автоматическое тестирование: определите, следует ли масштабировать и область содержимого оправдывать настройку автоматических тестов. Если это так, убедитесь, что вы планируете необходимое время и ресурсы для разработки и реализации этих тестов, чтобы они проверяли, что вы ожидаете.
• Разверните содержимое из рабочей области разработки в тестовую рабочую область: разверните изменения из рабочей области разработки в тестовую рабочую область, чтобы изменения видны пользователям. Убедитесь, что вы выполнили необходимые действия после развертывания в тестовой рабочей области, например настройку и обновление тестового приложения.
• Определите подход к тестированию пользователей: решите, как пользователи будут проверять содержимое.
• Определите тестовых пользователей: определите, кто из сообщества пользователей проверит содержимое. Достичь соглашения с этими лицами по степени их участия и ожиданий.
• Сбор отзывов пользователей: настройка средств и процессов для автоматического сбора отзывов. Например, можно использовать задачи и планировщик в Microsoft Teams или Microsoft Forms.
• Результаты теста документа: документируйте результаты проверки содержимого и любые изменения, внесенные в результате результатов теста. Убедитесь, что эта документация легко найти.
• Планирование развертывания в рабочей среде: после завершения тестирования пользователей подготовьтесь к развертыванию содержимого из тестовой рабочей области в рабочей области.

Связанный контент

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