Skip to main content

魅力度テスト

魅力度テストの説明

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

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

  • シフトレフト:プロジェクトの早い段階でテストを開始し、各スプリントのコンポーネントにします
  • ユーザーテスト:プロジェクトの初期段階で専門のテスト担当者だけでなくビジネスユーザーを含めてフィードバックを提示するもので、ユーザーテストはUAT(ユーザー承認テスト)とは異なります
  • 計画:テスト計画を作成し、アプリケーションが機能要件だけでなく、ビジネス成果を満たすことを確認します
  • 一貫性:完了の定義(DoD)に合意し、準拠します
  • ツール:アプリケーション品質ダッシュボードやPega Predictive Diagnostic Cloudなどの組み込みの検証ツールを使用します
  • 自動化:Pegaプラットフォームまたはサードパーティ製のツールを使用して、自動化されたテストスイートをビルドします
補足: テストはプロジェクトの成功に不可欠であり、Pegaソリューションが魅力的であり、かつ高品質であることを確認します。 テストを最後にしか行わない従来のITプロジェクトとは異なり、Pega Express戦略では、準備(または発見)フェーズでテストアクティビティを開始し、プロジェクトの期間中それを継続します。

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

シフトレフト

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

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

Shift Left

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

 

テストフォーカス

テストタイプ

シフトレフトのベストプラクティス

スプリントテスト

単体テスト

  • Pega Diagnostic Cloudを使用して問題を解決する
  • ガードレールの使用
  • 準備フェーズ中のXDプロトタイプでのリーンユーザビリティテスト
  • Pegaのツールによって、確実にMLPのみに焦点が当てられるようになります
  • 変更内容のみに集中する
  • 完了の定義への準拠の義務
  • Pegaユニットを使用したテストの自動化

スプリントテスト

スクラムテスト

  • 早期に実際のインターフェイスに対してテストを実施し、問題を洗い出す
  • 早期の検証を可能にするためのビジネスへの関与
  • Pega APIとPegaシナリオを使用した自動化

機能テスト

エンドツーエンド

  • DevOpsを使用したデプロイと自動化された回帰テストの使用
  • Pega Expressテスト計画で努力と集中を推進する

機能テスト

ユーザー承認テスト(UAT)

  • DevOpsを使用したデプロイと自動化されたスモークテストの使用

リリーステスト

パフォーマンスとセキュリティ

  • 開発マネージャーの活用

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

準備フェーズでのテストアクティビティ

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

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

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

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

  • 期待される結果が明確に定義されており、テスト可能
  • あいまいではなく、明確で簡潔
ヒント: Pega Expressのベストプラクティスは、詳細なストーリーに対して3つから5つの合格基準を作成することです。

完了の定義(DoD)の作成および準拠

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

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

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

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

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

Microjourneyとビジネス成果に焦点を当てる

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

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

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

テスト計画の作成

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

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

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

Pega Express Test Plan
補足: このアプローチの利点の一つは、ビジネスの利害関係者が理解できる用語で、アプリケーションの健全性を示すことができることです。 この計画では、機能をレポートするのではなく、特定のお客様のMicrojourneyとビジネス成果をレポートします。 どれだけのジャーニーがテストを実施しているか、どのパスがテストに合格したのか、どの領域に問題があるのかが示されます。 業務部門の利害関係者は、レポートが自分の理解できる用語と形式で書かれているため、何がうまくいって、何がうまくいかなかったのかが分かります。

検証ツールと自動化されたテスト

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

組み込みの検証ツール

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

ヒント: アプリケーション品質ダッシュボードとPDCをスプリントごとに少なくとも1回はチェックします。

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

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

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

成功に向けたチェックリスト

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

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

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


このトピックは、下記のモジュールにも含まれています。

If you are having problems with your training, please review the Pega Academy Support FAQs.

このコンテンツは役に立ちましたか?

改善できるところはありますか?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice