アダプタのテストのチェックリスト
Rapid Adapter Builderを使用して作成したアダプタのテスト計画を作成するには、ここに示すガイドラインを使用します。
メタデータの確認
アダプタをOracle Integrationにプッシュした後、そのメタデータが正確で読みやすいかどうかを確認します。
-
ナビゲーション・ペインで、「設計」、「アダプタ」の順にクリックします。
-
リストでアダプタを見つけます。
-
次の情報が正しいことを確認します:
- アダプタの名前
- バージョン
-
アダプタをポイントし、「詳細を開く」
を選択 -
アダプタの詳細が正しいこと、および期待どおりに表示されることを確認します。
たとえば:
- すべてのテキストは正確ですか?
- すべてのリンクが機能し、正しいURLを開いていますか。
- すべてのテキスト・フィールドは妥当な長さですか。
- タイ・ポはありますか?
-
必要に応じて、今すぐ、またはテスト終了後にメタデータを更新します。
「情報定義の追加」を参照してください。
接続のテスト
接続を作成できるかどうか、それが要件を満たしているかどうか、および正確でわかりやすい接続情報であるかどうかを確認します。
-
アダプタに基づく接続を1つ以上作成します。
ヒント:
アダプタを最適化し、ドキュメントとサポートの必要性を低減するには、このレビューのためにUXライターと提携します。接続の作成中に、次を確認します:
- アダプタを使用して接続を作成できますか。
- アダプタは必要なすべてのシナリオに対応していますか。
- 各アクションの説明は意味があるのでしょうか。
- すべての接続プロパティとセキュリティ・プロパティ、および対応するヒントを確認します。
- テキストは想定どおりに表示されますか。
- 文章は意味があるのでしょうか。
-
テキストは妥当な長さですか?
一般的に、短いほうが良いですが、理解できることが最も重要です。
-
テキストは一貫していますか?
たとえば、一部のフィールドは動詞を使用し、他のフィールドは名詞を使用しますか。
-
用語は一貫性があり、理解しやすいですか。
たとえば、一部のフィールドが「変更オーダー」と表示され、他のフィールドが「オーダー更新」を使用すると、ユーザーが混乱する可能性があります。
-
接続プロパティまたはセキュリティ・プロパティの値は、開発者がアダプタを使用して作成したすべての接続で同じになりますか。 その場合は、デフォルト値を設定し、アダプタ定義ドキュメントのプロパティを非表示にします。
-
マッピングの作成中に、次を確認します:
-
マッパーを簡単にナビゲートできますか、それとも圧倒的ですか。
-
カスタム・レスポンスのマッピングはわかりやすくなっていますか。 プロパティは理解しやすいですか?
-
-
接続を使用する統合を作成します。
「Oracle Integration 3での統合の使用」の「統合を作成」を参照してください。
-
テスト中に、アダプタ定義ドキュメントで行う必要のある変更を特定した場合は、今すぐ変更するか、テスト終了後に変更します。
「接続定義の確認」を参照してください。
統合のテスト
統合が実行時に想定どおりに実行されるかどうかを確認します。
-
実行時に統合をテストします。
「Oracle Integration 3での統合の使用」の「統合のアクティブ化」を参照してください。
-
統合が期待どおりに実行されること、および次の情報を確認します:
-
答えはわかりやすいでしょうか。
たとえば、理想的なレスポンスは、ユーザーが知っておく必要のある情報のみを返し、それ以外は何も返しません。
-
統合は、想定していたことを実行しましたか。
統合によって新しいレコードが作成される場合は、各フィールドに正しい情報が配置されていることを確認してください。 たとえば、姓と名のフィールドが交換されていないことを確認します。
-
-
統合が期待どおりに実行されない場合は、その理由を判断します。
たとえば、APIコールが失敗している可能性があります。
-
アダプタ定義ドキュメントを必要に応じて、今すぐ、またはテスト終了後に更新します。
参照
改善の機会の特定
機能的で一貫性のあるアダプタでも、改善の余地がある場合があります。
たとえば:
-
ユーザーがオブジェクトの識別子を入力する必要がある状況を考えてみます。
アダプタをテストして識別子を入力すると、接続とその統合機能が予期したとおりになります。 しかし、現実世界では、ユーザーは簡単にこの識別子を取得することはできません。 たとえば、表示名のみを知っている場合があります。 または、関連する識別子のみをドロップダウンに表示できます。
-
アダプタにカスタム・プロパティが表示されない場合があります。
たとえば、国際企業では、各国に固有のHRソフトウェアがあり、従業員レコードに異なる必須フィールドがある場合があります。 1つの国のHRソフトウェアのみで動作するアダプタの使用は制限されています。 すべてのカスタム・フィールドを含むすべてのHRシステムと連携するアダプタは、より包括的なソリューションを提供します。
このような機能は、Postmanコレクションから変換するアダプタ定義ドキュメントの一部ではありません。 かわりに、これらの要件に対応するアダプタ定義ドキュメントを更新する必要があります。
改善の機会は膨大であり、スコープのクリープにつながる可能性があります。 エンド・ユーザーおよび製品所有者と協力して、これらの改善の機会を特定し、優先順位を付けます。
ドキュメントのテスト
稼働する前に、アダプタのドキュメントをユーザー・インタフェースに対してテストし、次のことを確認します:
-
アダプタのドキュメントはありますか。
-
ドキュメントは正確ですか。
-
ユーザーは、ドキュメントを使用してアダプタを使用して接続を作成できますか。
「アダプタ・ドキュメントの公開」を参照してください。
必要に応じて追加テストを完了
たとえば、組織の要件に従って次のテストを完了します:
- 機能テスト
- 要件テスト
- ユーザー・エクスペリエンスのテスト
- パフォーマンス・テスト