次の方法で共有

Power BI 実装計画: コンテンツを検証する

  • [アーティクル]

Note

この記事は、Power BI 実装計画 シリーズの記事の一部です。 このシリーズでは、主に Microsoft Fabric 内での Power BI のエクスペリエンスに焦点を当てます。 シリーズの概要については、「Power BI 実装計画」を参照してください。

この記事は、コンテンツ ライフサイクルの管理の一部としてコンテンツを検証するのに役立ちます。 主な対象者は次のとおりです。

  • センター オブ エクセレンス (COE)、BI チーム: 組織内で Power BI の監視を担当するチーム。 これらのチームには、Power BI コンテンツのライフサイクルを管理する方法を決定する意思決定者が含まれています。 また、これらのチームには、コンテンツ リリースのライフサイクルを処理するリリース マネージャーや、ライフサイクル管理を効果的に使用およびサポートするために必要なコンポーネントを作成して管理するエンジニアを含めることもできます。
  • コンテンツ作成者とコンテンツ所有者: 他のユーザーと共有するために Fabric ポータルに公開するコンテンツを作成するユーザー。 これらの個人は、自分が作成する Power BI コンテンツのライフサイクル管理を担当します。

ライフサイクル管理は、コンテンツの作成から最終的な廃止までの処理に使用するプロセスと作業手順で構成されます。 ライフサイクル管理の第 2 ステージでは、コンテンツを開発し、変更を管理します。これには、コンテンツの開発と、ワークスペースおよびバージョン管理のセットアップの方法に関する重要な決定が含まれます。 第 3 ステージでは、コンテンツを検証して、デプロイの準備ができているかどうかをテストします。

Note

通常は、連続する開発と検証のサイクルで、第 2 ステージと第 3 ステージを反復処理します。

コンテンツの検証は、ソリューションの品質と信頼性を確保するために非常に重要です。 このため、運用環境にデプロイする前にコンテンツの変更をテストすることが不可欠です。

次の図は、Power BI コンテンツのライフサイクルを示し、コンテンツを検証する第 3 ステージを強調表示しています。

Power BI コンテンツのライフサイクルを示す図。コンテンツの検証に関する第 3 ステージが強調表示されています。

Note

コンテンツ ライフサイクル管理の概要については、このシリーズの最初の記事を参照してください。

この記事は、ライフサイクルを通してコンテンツを検証するための主な考慮事項と意思決定に重点を置いています。 コンテンツの検証方法に関するその他のガイダンスについては、次を参照してください。

コンテンツの検証には、コンテンツが期待どおりに動作するようにするための特定の決定やアクションの実施が含まれます。

コンテンツを検証するときは、ソリューションのさまざまな側面を評価します。

  • 機能: ソリューションを構成する項目と機能が機能しているかどうか。 機能をテストする例として、セマンティック モデルがスケジュールされている更新を遂行できるかどうかが挙げられます。
  • データの精度: 表示される数値と結果が完全で、ビジネスの期待と一致しているかどうか。 データの精度をテストする例として、レポート内の値が既知のベースラインと一致しているかどうかが挙げられます。
  • パフォーマンス: 使用可能なユーザー リソースやユーザーの待機時間に対してクエリが発生させる影響が最小限に抑えられるかどうか。 パフォーマンスをテストする例として、データフローがタイムアウトに到達したり、長い更新時間を発生させたりせずに確実に更新されるかどうかが挙げられます。
  • セキュリティ: 承認されていない個人に対して、情報やソリューション全体の表示やアクセスが制限されているかどうか。 セキュリティをテストする例として、行レベルのセキュリティ (RLS) を検証するときのユーザーまたはロールの権限借用が挙げられます。
  • 有効性: ソリューションが関連するビジネス上の問題またはプロセスに対処し、意図したとおりにビジネス目標を十分にサポートするかどうか。 有効性をテストする例として、ユーザー受け入れテスト (UAT) を実施するときのユーザー フィードバックの収集が挙げられます。
  • アクセシビリティ: できるだけ多くのユーザーが使用できるように、ソリューションが既知のアクセシビリティ標準を満たしているかどうか。 アクセシビリティをテストする例として、レポートが Microsoft のレポートのアクセシビリティ チェックリストを満たしていることの確認が挙げられます。

さまざまな種類のテストを実施することで、コンテンツを検証します。 次のセクションでは、コンテンツ作成者とコンテンツ コンシューマーがテストを実行する方法を決定するための主要な考慮事項について説明します。

Note

多くのチームは、単体テスト、統合テスト、スモーク テストなどの、ソフトウェア開発に由来するテスト手法を使用します。 コンテンツの検査と検証に同じように有効な方法は、多数あります。 最も重要なのは、ニーズとチームの作業方法に最適なアプローチを使用してコンテンツをテストすることです。

作成者がコンテンツを検証する方法を決定する

コンテンツ作成者は、変更の品質と機能を確保するために、コンテンツに対する自分自身の変更を検証する必要があります。 テストは通常、ソリューションの最新の動作バージョンを含む開発ワークスペースで行われます。 コンテンツ作成者は、ユーザー検証のためにコンテンツがテスト ワークスペースにデプロイされる前に、自分自身の変更をテストします。

Note

ユーザーが利用できるようにする前に、コンテンツ作成者が、自分自身のコンテンツを検証することが不可欠です。 明らかな問題を持つソリューションがテスト ユーザーに対して提供されると、ソリューションの信頼性が損なわれます。 テスト時でも、ユーザーは最終製品にそこそこ近いものを期待します。 さらに、機能するソリューションを使用すると、ユーザーはビジネス領域に関連する問題を特定することに集中できます。

コンテンツ作成者がコンテンツを検証するには、2 つの方法があります。

  • 手動テスト: 手動テストには、主観的な評価を通じて、またはいくつかの客観的なテスト基準と比較して、人間がコンテンツを手動で検証する作業が含まれます。 手動テストは簡単に実行できますが、人為的なエラーや偏りが発生します。 さらに、コンテンツが特定の規模に達すると、手動テストを適切に実行するのが困難になる可能性があります。 手動テストは 2 つの方法で実施できます。
    • 独立したレビュー。これにはセマンティック モデルやレポートなどの、自分自身のコンテンツのテストが含まれます。
    • ピア レビュー。これには、コンテンツの主観的な評価が含まれ、ソリューションを批判的に査定し、それを改善するための提案を提供します。
  • 自動テスト: 自動テストには、人間の介入なしに自動的に評価される、事前に準備されたテストが含まれます。 自動テストは通常、ソリューション コードの一部を特定のベンチマークまたはベースラインと照合して検査します。 自動テストは実行が難しく、セットアップに時間と労力がかかります。 ただし、大規模な実装およびビジネス クリティカルなソリューションの品質と信頼性を確保するエンタープライズ シナリオでは、自動テストが不可欠です。

以降のセクションでは、コンテンツ作成者が手動テスト、自動テスト、ピア レビューを実行できるさまざまな方法について説明します。

手動テストを実施する

作成するコンテンツに対して自分自身の手動テストを実行する必要があります。 このテストでは、変更が期待どおりに動作し、目的の品質基準を達成することを確認する必要があります。 手動テストには通常、コンテンツまたは特定のコンテンツ変更の使用と主観的な評価、結果の記述と文書化が含まれます。

自分自身のコンテンツをテストするときの考慮事項をいくつか次に示します。

  • テスト条件と成功基準を事前に決定して文書化します。
  • テストと、テスト結果の文書化を徹底的に実施します。 ただし、テスト手法によって開発速度が低下しないように、余分なテストは避けるようにしてください。
  • 項目の種類ごとにテストの標準セットを作成して、再現性を向上させます。
  • テスト結果と結論を文書化します。
  • 複数回テストして、テスト結果がランダムな確率ではなく現実を最もよく反映していることを確認します。
  • 運用環境を代表するテスト条件を使用します。

以降のセクションでは、手動テストに関するその他の主要な考慮事項について説明します。

セマンティック モデルを手動でテストする

セマンティック モデルは、レポート、ダッシュボード、その他のクライアント ツール、Fabric ワークロードのアップストリーム ソースであるため、Fabric と Power BI のソリューションの重要な部分です。 そのため、デプロイの前にセマンティック モデルを検証することが重要です。

次のような質問への回答を考えると、セマンティック モデルの検証に有益です。

  • テーブルに予期しない欠損値、重複値、または正しくない値が含まれますか?
  • DAX メジャーが、長いクエリ時間をかけずに期待した結果を返しますか?
  • スケジュールされた更新が、長い更新時間をかけずに正常に完了しますか?
  • 視覚エフェクト、フィルター、またはクエリ結果に、参照整合性違反によって引き起こされた "(空白)" 結果が観測されますか?
  • RLS やオブジェクト レベル セキュリティ (OLS) などのデータ セキュリティが、承認されていない個人によるモデルやそのデータへのアクセスを十分に阻止しますか?
  • モデル オブジェクト (DAX メジャーやテーブル列など) が表示フォルダーに編成されていますか?

セマンティック モデルの検証に役立つさまざまなツールとアプローチを使用できます。

  • Power BI Desktop: Power BI Desktop を使用すると、さまざまな機能を使用してセマンティック モデルのさまざまな側面を検証できます。 セマンティック モデルのテストを支援する Power BI Desktop 機能の例には次のようなものがあります。
    • 視覚エフェクト キャンバス: ドラッグ アンド ドロップによる視覚エフェクトを使用してモデルの機能と精度をテストします。
    • DAX クエリ ビュー: モデルの精度と、後で保存して再利用できる DAX クエリ付き DAX コードをテストします。
    • クエリ診断: Power Query でのクエリの評価方法に関する診断情報を取得して、更新のパフォーマンスをテストします。
  • Fabric: Fabric ポータルの機能と項目を使用すると、ワークスペースにデプロイされたセマンティック モデルの側面を検証できます。
  • サード パーティのツール: サード パーティのツールを使用すると、より詳細な情報や、検証を支援するその他の機能を提供することで、セマンティック モデルの他の側面を検証できます。 セマンティック モデルのテストを支援するサード パーティのツールの例には次のようなものがあります。
    • DAX Studio: DAX クエリのタイミングとクエリ プランの詳細な内訳を受け取って、DAX コードのパフォーマンスをテストおよび最適化します。
    • Tabular Editor: DAX クエリの評価方法とアクティブな評価コンテキストの詳細な内訳を受け取って、DAX コードの精度をテストおよびデバッグします。

ヒント

クエリ診断を使用して、データフローなどの、Power Query を使用する他の項目から、そのパフォーマンスを手動で検証および最適化できます。

さらに、DAX クエリ ビューと、DAX Studio などのサード パーティのツールを使用して、改ページ対応レポートやスコアカードに対する DAX クエリを検証および最適化できます。

レポートを手動でテストする

レポートは、ユーザーがデータを操作するための一般的な方法です。 多くのユーザーは、意思決定と、ビジネス目標に向けて前進するためのアクションの実行についてレポートに依存しています。 そのため、デプロイの前にレポートを検証することが重要です。

次のような質問への回答を考えると、レポートの検証に有益です。

  • レポートが文書化されたビジネス要件を満たしていますか?
  • 適切な質問に対処するために適切な視覚化タイプが使用されますか?
  • レポート ページは明確かつ簡潔で、色や視覚エフェクトが多すぎていませんか?
  • データのごく一部のサブセットにフィルターを適用しても、レポートが期待どおりに機能しますか?
  • レポートが Excel へのエクスポートを許可していますか? その場合、集計データや基になるデータの取得を許可しますか?
  • レポートを使用して、レポート間のドリルスルーや視覚エフェクトの個人用設定を行うことができますか?

レポートの検証に役立つさまざまなツールとアプローチを使用できます。

  • Power BI Desktop: Power BI Desktop を使用すると、さまざまな機能を使用してレポートのさまざまな側面を検証できます。 レポートのテストを支援する Power BI Desktop 機能の例には次のようなものがあります。
  • Fabric: Fabric ポータルの機能と項目を使用すると、ワークスペースにデプロイされたレポートの側面を検証できます。
    • 更新アプリ: Power BI アプリでレポートを配布し、どのコンテンツをどのユーザーが表示できるかを決定するためにさまざまなアプリの対象ユーザーを設定するときの、レポート機能とセキュリティをテストします。 アプリの対象ユーザーを使用すると、自分自身でそれらのユーザーがアクセスできるレポートをプレビューし、アプリ環境をテストできます。
    • ワークスペースまたはアプリの読み取りビュー: ユーザーと同じ環境でレポートの機能と精度をテストします。

Note

ダッシュボードの開発と検証を行うことができるのは、Fabric ポータルのみです。

重要

Power BI Desktop と、デプロイ後の Fabric ポータルの両方でレポートをテストすることが不可欠です。 ローカル マシン上の視覚エフェクトのレンダリングは、Fabric ワークスペース内のレポートと比較して、動作が異なる場合があります。 さらに、ワークスペースまたはアプリからレポートを使用するユーザー環境は、Power BI Desktop でのレポートの使用とは大きく異なることに注意してください。

ピア レビューを実行して手動でテストする

コンテンツを手動で検証するもう 1 つの方法は、ピア レビューを実行することです。 ピア レビューでは、コンテンツ作成者が、評価するソリューションまたはソリューションの一部を同僚に提供します。 ピア レビューの目的は、複数のコンテンツ作成者の集合的な経験と専門知識を使用してソリューションを改善することです。 ピア レビューは、手動テストと自動テストの最中と終了後の両方で実行できます。

Note

ピア レビューは、多くの業界で使用される標準的なアプローチです。 このアプローチは、コンテンツ、製品、プロセスの品質を向上させるために一般的に知られています。

ヒント

自分がソリューションの唯一のコンテンツ作成者である場合は、ソリューションをレビューしてもらうコンテンツ作成者を別のチームで見つけて、自分からも同じ作業を提供することを検討してください。

ピア レビューは、さまざまな方法で実施できます。

  • 機能レビュー: 機能レビューは、ソリューションが満たす必要がある機能、処理、またはビジネス要件に重点を置きます。 機能レビューでは、レビュー担当者はエンド ユーザーであるかのようにソリューションを使用します。 見つけた欠陥や問題を、実装を改善するための主観的な批判とともに文書化します。
  • 技術レビュー: 技術レビューは、データ モデリング、コード、設計などのソリューションの技術的な側面に重点を置きます。 技術レビューでは、レビュー担当者は特定の機能や変更がどのように実装されたかを評価し、代替アプローチを提案したり、現在のアプローチの潜在的な欠陥やリスクを明示したりします。
  • pull request: ソース管理を実行するときに、pull request (PR) を作成して、変更をソリューションの最新バージョンにマージします。 技術所有者が提案された変更をレビューし、ソース コードを評価します。 この種のレビューは、DAX または M コードの書式設定などの標準規則にコードが準拠していることを確認したり、アンチパターンや潜在的に問題のあるコードを識別したりするのに役立ちます。

ヒント

コンテンツの変更をユーザー受け入れテストに進めるには、何らかの正式なピア レビューと承認を実行することをお勧めします。 これは、テスト中であっても、品質の低いコンテンツがデータ ソリューションの信頼性を損なう可能性があるためです。 さらに、ピア レビューは、チーム メンバー間のコラボレーションと知識共有の点でもメリットを生み出します。

ピア レビュー サイクルを完了したら、推奨される変更を文書化して組み込む必要があります。 必要に応じて、ユーザー テストに進む前に、承認のために変更を再送信する必要があります。 通常、ピア レビューを複数回繰り返す必要があるのは、テスト対象の変更が多いか、複雑な変更がいくつかある場合のみです。

テストを自動化する

コンテンツ作成者はテストを自動化して、デプロイ前にテストが自動的に実行されるようにできます。 自動テストには通常、コンテンツの保存や pull request (PR) の送信などの、特定のアクションに応じてプログラムによって実行および編成される事前準備済みのテスト条件が含まれます。 自動テストの結果は、後で参照および文書化するために自動的に保存されます。

自動テストの目的は、テストの一貫性と結果の信頼性を向上させながら、コンテンツの変更を検証する時間と労力を削減することです。 コンテンツは通常、自動テストに失敗すると、コンテンツ作成者が問題を解決するまでデプロイできません。

効果的な自動テストは、DataOps の実装の主要な部分です。 DataOps を使うと、データと分析の配信を改善および高速化する手法をチームが採用することで、プロセスを自動化し、スケーリングできます。

重要

テストを効果的に自動化するには、適切に設計されたテストを作成する必要があります。 そのようなテストを作成するには、かなりの時間と労力がかかることがあります。 テスト条件と期待値の定義が適切ではない場合、自動テストではコンテンツの適切な側面を検証できないため、そのようなテストを自動化するメリットはほとんどありません。

ヒント

自動テストは、エンタープライズ コンテンツの公開シナリオでソリューションのデプロイと統合するときにメリットが最も大きくなります。 たとえば、コンテンツをデプロイする準備が整っていることを確認する検証パイプラインの一部として Azure Pipelines を使用して、テストを自動化できます。 詳細については、第 4 ステージのコンテンツのデプロイに関する記事を参照してください。

以降のセクションでは、Power BI セマンティック モデルとレポートを自動的にテストするための主要な考慮事項について説明します。

セマンティック モデルのテストを自動化する

セマンティック モデルの自動テストは可能ですが、通常はサード パーティのツールとフレームワークを使用したカスタム セットアップが必要になります。

さまざまなツールとアプローチを使用して、セマンティック モデルのテストを自動化できます。

  • ベスト プラクティス アナライザー (BPA): ベスト プラクティス アナライザーを使用すると、セマンティック モデルの評価に使用できるルールを指定できます。 セマンティック モデル内の規則違反を特定する Tabular Editor を使用して、BPA を実行できます。 Azure DevOps とともに、または別のスケジュールされたプロセスの一部として Tabular Editor のコマンド ライン インターフェイス (CLI) を使用することで、BPA 規則違反の検査を自動化できます。
  • Fabric ノートブックとセマンティック リンク: Fabric のノートブックを使用すると、セマンティック リンクを使用して、セマンティック モデルとプログラムで対話できます。 ノートブックを使用して、データを検証するために Great Expectations (GX) などのフレームワークを実行できます。 さらに、メジャーと DAX クエリを評価し、次に既知のベースラインと照合して結果をテストできます。
  • Power Automate: Power Automate を使用すると、Power BI REST API を使用して、セマンティック モデルに対してクエリを実行し、レポートをエクスポートできます。 既知のベースラインと照合してクエリ結果を検査し、次にコンテンツ所有者にアラートをトリガーするなどのダウンストリーム アクションを実行できます。

ヒント

自動テストとセマンティック モデルの編成を組み合わせることを検討してください。 たとえば、ノートブックや Power Automate を使用して更新する前に、データ ソースとセマンティック モデルに対して自動テストを実施できます。 テストが失敗した場合は、更新を阻止できます。これにより、更新エラーや不適切なデータのビジネス レポートへの到着も阻止できます。

レポートのテストを自動化する

レポートのテストを自動化するために使用できるオプションは限られています。 このようなオプションは、外部ツールまたはコミュニティ ソリューションに依存して、レポート メタデータの検証やユーザーのレポートとの対話のシミュレートなどの、視覚エフェクトやレポートのプロパティの自動検証を行います。

レポートのテストを自動化するために、さまざまなツールとアプローチを使用できます。

  • レポートのベスト プラクティス アナライザー: レポート定義を調べることでレポート内の問題の検出を自動化するための、ベスト プラクティス アナライザーに類似の機能をサポートするさまざまなサード パーティのツールがあります。 この機能をサポートするツールの 2 つに、PBI Explorer と PBI Inspector があります。
  • Power Automate デスクトップ: Selenium with Python や Power Automate デスクトップなどの UI オートメーション ツールを使用すると、ユーザーのマウスによるレポートとの対話をシミュレートできます。 ユーザー フローを定義することで、ナビゲーションと対話をテストできます。 これらのテストは、フローを完了できたときに合格になり、画面上の特定の単語や画像 (エラー メッセージや空の視覚エフェクトなど) を検出したときに不合格になります。

ユーザーがコンテンツを検証する方法を決定する

コンテンツは、手動テスト、自動テスト、ピア レビューに合格すると、ユーザー テストに進むことができます。 ユーザーは、コンテンツをテストするとき、そのコンテンツがビジネス要件を満たし、期待どおりに実行される (正確な結果を返すなど) かどうかについて、主観的なフィードバックを提供します。

通常、ユーザー検証はテスト ワークスペースで行われます。 テスト ワークスペースをセットアップするときは、次の事項を考慮に入れてください。

  • テスト アプリの作成: Power BI アプリを使用してコンテンツを配布する予定の場合は、テスト ユーザーがコンテンツを検証するためのテスト アプリをセットアップします。 そのテスト アプリは、運用環境でセットアップするアプリと同じである必要があります。 テスト アプリのナビゲーションには、文書化、トレーニング、フィードバック フォームへのリンクを含めることを検討してください。
  • アクセス権の規定: ソリューションを検証するコミュニティのユーザーのサブセットを特定します。 これらのユーザーに連絡し、このコンテンツを検証する必要がある時期と理由について契約を結びます。 次に、ユーザーについて、コンテンツへのアクセス権の付与と、適切なセキュリティ ロールへの追加を確実に行います。 それらのユーザーがテストを開始できるように、コンテンツまたはテスト アプリへのリンクを共有します。
  • スケジュールされた更新のセットアップ: ユーザー検証は通常、比較的長い期間にわたって行われます。 ユーザーがテストに最新のデータを使用するように、テスト ワークスペース内のデータ項目のスケジュールされた更新をセットアップすることをお勧めします。

重要

テスト ワークスペースにコンテンツをデプロイするときは、レポートとダッシュボードへの変更をユーザーに表示する前に、アプリを手動で更新する必要があります。

Note

ワークスペース間でのアプリのデプロイやコピーはできません。 アプリに対する変更は、そのワークスペースの構成で手動で行う必要があります。

ユーザー検証を開始する前に、必要な準備を行う必要があります。

  • ユーザー検証を行う時期を計画します。
  • ユーザー検証を特定の期間に限定するか、反復プロセスの一部にするかを指定します。
  • Microsoft Forms の使用などのフィードバック収集手段を作成します。
  • 検証に関係するユーザーに、計画と期待内容を連絡します。
  • ユーザーをガイドし、期待内容を管理するために、ユーザー検証のキックオフを編成します。
  • 検証とフィードバックのプロセスを示すユーザー向けのトレーニングを実施します。

コンテンツのユーザー検証を支援する他の方法をいくつか次に示します。

  • 観測テスト: 観測テストは、1 人以上のユーザーがガイダンスや指示なしにコンテンツを使用するのをコンテンツ作成者が観察する短いセッションです。 これらのセッションで、コンテンツ作成者は観測により、ソリューションの潜在的な欠陥、問題、または改善点を特定します。 これらのテストは、編成に必要な時間と労力が少なく、ソリューションの特定の機能や部分に限定できるため、有益になる可能性があります。 観測テストは、概念実証 (POC) などの、設計やアプローチに関する早期のフィードバックを得る点で最も有益です。
  • フォーカス グループ テスト: フォーカス グループ テストは、コンテンツを一緒に体験する少数のユーザー グループで編成される、制限されたセッションです。 これらのフォーカス グループは、特定の機能に関する最適なフィードバックを提供できる主要な利害関係者と領域の専門家が選択されるように厳選されます。 フォーカス グループ テストは、複数の対話型セッションで行うことができます。 フォーカス グループ テストは、観測テストよりも多くの時間と労力が必要ですが、ソリューションに関するより詳細なフィードバックを提供できます。
  • ユーザー受け入れテスト: ユーザー受け入れテスト (UAT) は、ユーザー コミュニティのうちの大規模な個人グループがソリューションを検証して、それに関する非同期フィードバックを提供する正式なプロセスです。 UAT は、編成に最も多くの時間と労力が必要ですが、ユーザー テストを実施する最も徹底的な方法です。 テスト ユーザーがソリューションを受け入れ、フィードバックの問題が解決されたら、コンテンツを運用ワークスペースにデプロイできます。

コンテンツを検証する方法を決定したら、ワークスペースに対して、およびワークスペース間で、コンテンツをデプロイする方法を計画できます。

チェックリスト - コンテンツの公開を計画するときに、主要な決定事項とアクションは次のとおりです。

  • テスト条件の設計と文書化: 実施するテスト、テスト内容、実行方法について説明します。
  • ピア レビュー プロセスの決定: 自分以外に他の誰がコンテンツを検証するかを説明します。
  • 手動テストのアプローチの決定: 作成するコンテンツの検証に使用するツールと機能を決定します。
  • 自動テストを使用するかどうかの決定: コンテンツの規模と範囲が、自動テストのセットアップの正当な理由になるかどうかを識別します。 なる場合は、これらのテストが期待内容を検証するように、設計と実装に必要な時間とリソースを計画してください。
  • 開発ワークスペースからテスト ワークスペースへのコンテンツのデプロイ: 開発ワークスペースからテスト ワークスペースに変更をデプロイして、ユーザーに変更が表示されるようにします。 テスト アプリの設定や更新などの必要なデプロイ後アクティビティを、テスト ワークスペースで完了したことを確認します。
  • ユーザー テストのアプローチの決定: ユーザーがコンテンツを検証する方法を決定します。
  • テスト ユーザーの特定: ユーザー コミュニティの誰がコンテンツを検証するかを特定します。 その関与と期待内容について、それらの個人と合意に達します。
  • ユーザー フィードバックの収集: フィードバックを自動的に収集するためのツールとプロセスをセットアップします。 たとえば、Microsoft Teams や Microsoft Forms でタスクと Planner を使用できます。
  • テスト結果の文書化: すべてのコンテンツ検証の結果と、テスト結果を受けて行われたすべての変更を文書化します。 この文書は、簡単に見つけられるようにします。
  • 運用環境へのデプロイの計画: ユーザー テストが終了したら、テスト ワークスペースから運用ワークスペースへのコンテンツのデプロイを準備します。

関連するコンテンツ

このシリーズの次の記事では、コンテンツ ライフサイクル管理の一部としてコンテンツをデプロイする方法について説明します。