魅力度テスト

Pega Express^™テスト戦略は開発フェーズで設計され、実行されます。 テストは、Pegaプラットフォームソリューションが単に機能的であるだけでなく、お客様に愛されるものであることを検証するために重要です。 

テスト戦略では、以下の内容を通してこれを実行します。

• シフトレフト：プロジェクトの早い段階でテストを開始し、各スプリントのコンポーネントにします
• ユーザーテスト：プロジェクトの初期段階で専門のテスト担当者だけでなくビジネスユーザーを含めてフィードバックを提示するもので、ユーザーテストはUAT（ユーザー承認テスト）とは異なります
• 計画：テスト計画を作成し、アプリケーションが機能要件だけでなく、ビジネス成果を満たすことを確認します
• 一貫性：完了の定義（DoD）に合意し、準拠します
• ツール：アプリケーション品質ダッシュボードやPega Predictive Diagnostic Cloudなどの組み込みの検証ツールを使用します
• 自動化：Pegaプラットフォームまたはサードパーティ製のツールを使用して、自動化されたテストスイートをビルドします

Pega Expressテストの概要については、短い動画でご覧ください。

シフトレフトとは、プロジェクトのライフサイクルの早い段階でテストアクティビティを開始することを意味します。 DevOpsでは、この演習をソフトウェア開発で使用し、チームが品質に集中し、問題の検出ではなく予防に取り組み、プロジェクトのタイムラインの早い段階でテストを開始するサポートを行います。 初日からアプリケーション品質を計画し、検証します。

次の画像に示すように、Pega Expressの導入手法では、さまざまなテストや検証アクティビティを使用してプロジェクトを前倒しします。 このテストのコンセプトである、早期、頻度、および継続はPega Expressの中心であり、各スプリント内およびプロジェクトライフサイクル全体を通した品質チェックを促進する正式なプロセスと組み込みツールのセットによってサポートされています。

Pega Expressを使用すると、シフトレフトは簡単で、次のようにして実現します（このアプローチにより、問題の特定はスプリントテスト中に最大となり、リリーステストに移行するにつれて大幅に減少することに注意してください）。

不具合は早期に発見されるほど、簡単に安価で修正することができます。 問題を修正するのに最も安価な場所は、発見フェーズまたは準備フェーズです。 不具合を発見して修正するのに最もコストがかかるのは、従来ウォーターフォール型プロジェクトで行われてきた、ビルド後のQAフェーズや承認テスト時です。 そのため、Pega Expressでは、できるだけ早い段階でソリューションの検証とテストを行うことを推奨しています。

テスト戦略は、準備フェーズで具体化し始めます。 コードを書く前に、ビジネスアーキテクト（BA）とテスト担当者は、お客様と一緒にビジネス成果、スコープ、デザインを検証します。 ビジネスアーキテクトがユーザーストーリーを作成すると、テスト担当者は、各ユーザーストーリーが明確で、簡潔で、実行可能で、かつ合格基準を含んでいるかどうかを検証します。

すべてのユーザーストーリーには合格基準が必要です

合格基準は、ユーザーストーリーの説明を補完するものです。 ストーリーが完成するまでに満たす必要がある条件が記述されています。 合格基準は、ストーリーを豊かにし、テスト可能にし、ユーザーや他の利害関係者に対してストーリーを検証し、実証し、またはリリースできるようにします。

説得力のある合格基準には、次のような特徴があります。

• 期待される結果が明確に定義されており、テスト可能
• あいまいではなく、明確で簡潔

ユーザーストーリーごとに個別の合格基準を作成することに加えて、スクラムチームは、すべてのユーザーストーリーを通して必要な一貫した合格基準を特定する、正式な完了の定義（DoD）を作成します。 完了の定義は、ワークの品質を確保します。 これは、ユーザーストーリー開発ワークが完了したとみなされるために、実行する必要がある内容を示すチェックリストです。

完了の定義は、チームの全員が、チームがデリバリーするすべてのコンポーネントに期待される内容を正確に把握することを確実にします。 完了の定義では、製品や組織の目的に合った透明性と品質を確保します。

完了の定義には通常、以下のようなアイテムが含まれます。

• 開発済み、単体テスト実施済みで、かつ合格基準を満たす機能
• PegaUnitアプリケーションで作成され、将来の回帰テストに利用可能な単体テストスクリプト
• 承認テストの準備ができたアイテム
• コードレビューを通過した任意のコード
• リリース可能なアイテム
• 増加しない技術的負債

完了の定義テンプレートはPega Express Delivery Resources（デリバリーリソース）ページでダウンロードできます。

いつも浮かぶ質問は、「テストを効果的で効率的なものにし、お客様に愛していただける製品でビジネス成果を実現することを検証するためには、どのようにテストを整理すればよいか」ということです。

Pegaは、Microjourney™を中心としたアプローチを行いながら、これらの目標を達成するシンプルなテスト計画を設計しました。 この計画では、包括的なテスト対象範囲であることを確認するとともに、まったく異なる機能要素や汎用的なテスト対象範囲の統計ではなく、ビジネス成果という観点でテストのステータスをレポートできます。

テスト計画は、お客様が望むMicrojourneyが意図したとおりに機能し、結果としてできあがった製品が魅力的であり、かつお客様のビジネス成果を満たすものであることを確実にします。

Pega Expressのテスト計画を作成するのは、とても簡単です。 次のように開始します。

1. すべてのMicrojourneyを簡単に特定して完全にテストできるように、6列の表を作成します。
2. 1列目には、「住宅ローンの借り入れ」などのMicrojourneyをリストアップします。
3. 2列目に、基本的なPegaの構成要素である各Microjourneyのサブケースをリストアップします。
4. 次に、その後続の列で、それをさらに各Microjourneyのステージ、ペルソナ、チャネル、インターフェイス別に分解します。

これが完了したら、次の例に示すような各Microjourneyの表ができるはずです。 表の各行は、そのMicrojourneyのすべての成果がテストされていることを確実にする、Microjourneyのテストパスを表しています。

オートメーションの目的は、品質と再現性を高めることです。 システムアーキテクトのワークは、自分のワークの単体テストを行い、PegaUnitテストスクリプトを作成するまで完了しません。

組み込みの検証ツール

Pega プラットフォームには、アプリケーションの健全性に焦点を当てたアプリケーション品質ダッシュボード、クラウドサービスの健全性に関するビューを備えたPega Predictive Diagnostic Cloud (PDC)などの、アプリケーションの健全性を総合的に把握するための組み込みの検証ツールやダッシュボードがあります。

Pegaの組み込みツールまたはサードパーティ製のツールを使用して自動テストピラミッドを開発する

Pegaプラットフォームのネイティブなツールは、テストピラミッドの構成要素をサポートしています。 業界標準のツールも使用できます。 ただし、Pega Platformアプリケーションをテストする場合、通常はPegaのツールが最適なオプションです。

次の画像で「+」アイコンをクリックすると、テストピラミッドの詳細が表示されます。

• プロジェクトの最初からシフトレフトしてテストリソースを含める
• すべてのユーザーストーリーに合格基準が備わっていることを確認する
• 完了の定義の作成および準拠
• Microjourneyとビジネス成果に焦点を当てたテスト計画の作成
• 組み込みの検証ツールの使用
• テストの自動化

単体テストとPegaUnitの使用方法に関する詳細については、Pega Academyモジュールルールの単体テストを参照してください。

次の問題に答えて、理解度をチェックしましょう。