- Test Suite の利用を開始する
- Studio
- Orchestrator
- Testing ロボット
- Test Manager
プレビューAI を利用した生成
このページでは、Test Manager で AutopilotTM を使用して効果的なテスト ケースを生成するためのガイドラインとベスト プラクティスを示します。
このセクションでは、Test Manager の要件の主な特性について概説します。
要件には、多くの場合、機能面 (ソフトウェアが実行すべきこと)、パフォーマンス面 (動作速度)、ユーザビリティ (使いやすさ)、セキュリティ (動作の安全性) などの品質面に影響する特定の機能についての記述が含まれます。
AutopilotTM などの AI モデルで要件が正しく解釈されるようにするには、要件をより具体的に記述する必要があります。漠然とした曖昧な記述では、無関係な、または誤ったテスト ケースが生成される可能性があります。それを軽減するには、要件の目的の概要を説明した、簡潔でありながら正確な、ユーザーを中心に据えたステートメントから始めます。ユーザーに最終的なメリットをもたらすことを重視します。
例: 生命保険のアプリケーションの場合、次のように開始できます。
私は保険契約者になる可能性があるため、保険料を計算して、予想される費用を把握したいと思います。
これにより、ユーザーにとっての期待されるメリットが明らかになり、その要件をテストするための明確な目標が設定されます。
AutopilotTM がいかに効率的に正確かつ詳細なテスト ステップを生成できるかは、ユーザー ジャーニーとアプリケーション シーケンスを理解できているかどうかに大きく依存します。そのため、ユーザーがアプリケーションに対して行う特定の操作について詳しく説明することが非常に重要であり、その後のアプリケーションの応答 (アプリケーションの開始から最終的なテストの実施まで) が大切になってきます。これにより、AutopilotTM が操作の時系列を認識できるようになり、より正確で詳細なテスト ステップにつながります。
例: 保険料の計算機能の場合、ワークフローを次のように記述します。
ユーザーはメイン画面から操作を開始し、メイン メニューから「見積もりを取得」画面に移動する。次に、年齢や性別などの個人データを指定されたフォーム フィールドに入力する。利用可能なオプションから希望の保険適用範囲と保険期間を選択する。ユーザーが「保険料を計算」をクリックすると、アプリケーションは保険料を計算して次の画面に表示する。
明確かつ測定可能な承認基準は、アプリケーションの期待値を設定し、AutopilotTM で特定の結果が検証されるようにするために不可欠です。これには、ユーザーが規定の使用法に従わない可能性がある場合、無効なデータが入力される可能性がある場合、アプリケーションがエラー状態になる可能性がある場合など、ポジティブ/ネガティブの両方のシナリオを含める必要があります。また、セキュリティ、使いやすさ、スケーラビリティなどの、機能以外の要因も考慮する必要があります。明確に定義された承認基準がないと、AutopilotTM で不適切なテスト ケースが生成される可能性があります。
例: 生命保険アプリケーションの保険料の計算機能については、次のいずれかの例のような具体的な承認基準を指定します。
- システムは、ユーザーの年齢を考慮して保険料を計算する必要がある。25 歳を超えたら毎年、基本保険料 100 ドルに 5 ドルずつ追加する必要がある。
- システムは、関連する健康リスクの増加に伴い、喫煙者の保険料を 50 ドル引き上げる必要がある。
- ユーザーが 18 歳未満の年齢を入力した場合、システムはエラーメッセージを表示する必要がある。
- 同時接続ユーザー数が 1000 以下の場合、保険料計算プロセスは 3 秒を超えてはならない。
このセクションでは、考慮事項を念頭に置いてテスト ケースが生成されるようにするため AutopilotTM に追加できる指示の例を示します。
フロー図からエンドツーエンドのテスト ケースを生成する際に Autopilot への指示に含めることができるガイドラインのリストは、以下のとおりです。
- フロー図内の一意の各パスを個別のテスト ケースとして検証します。
- 図内のエンドツーエンドのパスのテストに専念します。
- 各テスト ケースが最初から最後までのジャーニー全体を表すようにします。
- 図内のすべてのジャーニー全体をテストすることにより、包括的なカバレッジを実現します。
以下に示した、Autopilot で迅速なテストを実現するさまざまなアイデアを生成するためのガイドラインを確認してください。
- テスト ステップは作成せず、テスト ケースのタイトルのみを作成します。
- テスト ケースのタイトルは最大 12 ワードに制限します。
- 独自のテスト ケースを 50 個以上作成します。
以下に示した、Autopilot でわかりにくい問題を見つけるためのテスト ケースを生成する際のガイドラインを確認してください。
- 型にはまらない、妥当と思われるテスト シナリオのみを生成して、隠れた問題を明らかにします。
- 標準テストでは見落とされがちな、より深い洞察を必要とするテスト シナリオに焦点を当てます。
- システム設計と想定されるユーザーの行動から弱点を見つけます。
- 異常な行動などの、ユーザーのさまざまな行動に基づいて、問題を明らかにします。
命名規則を使用してテスト ケースを生成するために Autopilot への指示に含めることができるガイドラインのリストは、以下のとおりです。
- すべてのテスト ケースのタイトルを動作動詞 "Verify" で始めます。
- タイトルは 6 ワードを超えない、明確かつ必要な情報が伝わるものにします。
- "UiPath |TC-01" を各テスト ケースのタイトルの先頭に付けます。"TC-01" は、各テスト ケースのタイトルの先頭にあるテスト ケースの番号です。
有効なエンドツーエンドのシナリオのみのテスト ケースを生成するために Autopilot への指示に含めることができるガイドラインのリストは、以下のとおりです。
- 有効かつ完全なユーザー ジャーニー専用のテスト ケースを作成します。
- 無効な入力やフィールドの検証を目的としたテスト ケースは避けます。
- テスト ケースのタイトルは、6 単語を超えない、明確かつ必要な情報が伝わるものにします。
このセクションでは、AutopilotTM に提供可能なサポート ドキュメントを示します。これらのドキュメントは、Test Manager の要件の説明を補足する追加情報です。これらのドキュメントは、Autopilot が要件をより深く理解し、要件に対してより正確で有用なテスト ケースを生成できるようにすることを目的としています。
アプリケーション内でのステップバイステップの操作を示すために、ユース ケース図、フローチャート、またはプロセス図を、画像または BPMN ファイルとして含めることを検討してください。プロセス図は、Autopilot が特定の要件を満たすうえで重要な、ユーザー アクティビティの連続した論理的なフローを把握するのに役立ちます。これらのプロセス表現に基づいて、Autopilot は、アプリケーションの実際のワークフローと厳密に一致した、より正確なテスト ケースを生成できます。
Autopilot が理解しやすくなるよう、UI/UX の要件を示す視覚的な図を追加することを検討してください。これは、新しいフロントエンド機能をテストするときに特に役立ち、レイアウト、ユーザー操作、およびテストする要素を明確に示すのに役立ちます。
医療、金融、電気通信などの規制対象の業界では、コンプライアンスおよび規制に関する文書を含めることを検討してください。これらのガイドラインは、多くの場合、Test Manager のさまざまな要件 (ユーザー ストーリーやユース ケースなど) に例外なく適用されます。これらの文書をアップロードすることで、Autopilot は、特定のコンプライアンス基準に直接リンクされているテスト ケースだけでなく、要件ごとに生成されるテスト ケースにコンプライアンス標準を統合できます。これにより、すべてのテスト ケースが業界の規制に準拠し、Autopilot によってテストされるすべての要件で一貫してコンプライアンスを遵守できます。
このセクションでは、AutopilotTM の現在の制限事項の概要を説明します。
次のファイル拡張子のみをアップロードでき、そこから Autopilot はテキスト コンテンツのみを処理します。
- DOCX
- XLSX
- TXT
- PNG
- JPG
- BPMN
Autopilot の入力トークン容量は 128,000 で、これは約 96,000 語、つまり 512,000 文字に相当します。
要件の説明とサポート ドキュメントがこれらの制限を超えないようにしてください。
ドキュメントのおおよそのトークン数を確認するには、ドキュメントを TXT ファイルとして開き、その内容を Open AI トークナイザー ツール にコピーします。 指定されたトークン数は概算です。 実際のトークン数はもっと多くなる可能性があります。