利益:
- 人工知能のサポートを受けて、等価クラス、境界値分析、デシジョンテーブルなどの技術を使用して、要件と受け入れ基準を包括的なテストケースに変換する機能
- ポジティブなシナリオ、ネガティブなシナリオ、エッジケースのシナリオを個別に作成し、人工知能が見逃したエッジケースを製品情報で補完する機能
- トレーサビリティを確立し、テスト ケースを合格基準にリンクすることでカバレッジ ギャップや不必要な肥大化を排除する機能
テスターの仕事は、多くの場合、この白紙の状態から始まります。テスターには要件 (「ユーザーはパスワードをリセットできなければならない」) があり、この 1 つの文を、ソフトウェアが実際に正しく動作することを証明するための数十の具体的なチェックに変換する必要があります。この変換はテスト設計と呼ばれます。テスト シナリオ (「無効なパスワードは拒否する必要がある」など、何をテストするかを説明する高レベルの目標) と、そのシナリオを具体的な手順、入力、予想される結果で詳細に説明する実行可能ユニットであるテスト ケースの違いを理解することが重要です。人工知能 (AI) はまさにこの白紙の瞬間を加速し、1 つの要件を数秒で数十のシナリオ草案に変えます。ただし、覚えておいてください。AI は、あなたが考えられる状況を再現します。どの状況が本当に重要であるかを製品知識に基づいて選択します。
この単元では、AI サポートを利用して要件を包括的ですっきりとしたテスト スイートに変える方法を段階的に学習します。
ステップバイステップ: 要件からテストセットまで
ステップ 1 — 要件を明確にします。 AI に生の要件を与える前に、受け入れ基準 (ジョブが「完了」したとみなされるために満たさなければならない条件) を収集します。 「パスワードはリセット可能である必要があります」だけでは十分ではありません。 「リセットリンクは30分間有効」「同じパスワードの使い回し不可」などのルールが本番テストの元です。
ステップ 2 — テスト手法を実装します。 AI について単に「台本を書こう」と言うのはやめてください。古典的なテスト設計手法の名前を尋ねます。
- 等価クラス (等価分割): 入力を、同じ動作を生成すると予想されるグループに分割します。たとえば、年齢フィールドの場合、「有効な範囲」、「小さすぎる」、および「大きすぎる」がクラスです。各クラスから 1 つの例をテストするだけで十分です。
- 境界値分析: 境界で最もエラーが発生するという事実に基づいて、しきい値をテストします。 18歳の年齢制限を17歳、18歳、19歳に分けてテストするようなものです。
- デシジョンテーブル: 複数の条件の組み合わせと、それぞれの組み合わせで期待される結果を表にまとめます。
- 状態遷移: システムの状態から状態への遷移 (注文: 作成→支払い→出荷など) と無効な遷移をテストします。
ステップ 3 — 正、負、およびエッジ状態を分離します。肯定的なテスト (正しい入力による期待される結果)、否定的なテスト (無効な入力による適切なエラー)、およびエッジ ケース (境界線または異常なケース) を求めます。 AI は一般的にポジティブな面を強調します。ネガティブケースとエッジケースは、明示的に要求しない限り不完全です。
ステップ 4 — 優先順位を付けて整理します。 AI は 60 のシナリオを生成できます。それらはすべて同じ価値があるわけではありません。リスクの高いもの (金銭、セキュリティ、データ損失) を優先し、重複するものを結合します。
ヒント: 「この要件から考えられない 5 つのエッジ ケースを生成する」という別のリクエストを AI に送信します。 AI の最も貴重な貢献は、あなたが見落としていた異常な状況をしばしば思い出させてくれるということです。
弱いプロンプト / 強いプロンプト
弱: 「パスワード リセットのテスト ケースを作成する。」
Strong: 「次の受け入れ基準を使用して、『パスワード リセット』機能のテスト ケースを生成します。リンクは 30 分間有効、1 回限りの使用、最後の 3 つのパスワードは再利用不可、5 回の不正試行後に 15 分間アカウント ロック。等価クラスと境界値分析を適用します。ポジティブ ケース、ネガティブ ケース、およびエッジ ケースを個別の見出しに示します。ケースごとに: ID、前提条件、手順、テスト データ、期待される結果、関連する受け入れ基準。セキュリティ/ロック シナリオを強調表示します。」
強力なプロンプト。ルール、テクニック、出力形式、優先順位を示します。したがって、AI は装飾的なテスト ケースではなく、実行可能で追跡可能なテスト ケースを生成します。
テストケースの出力形式
チームのテスト管理ツール (TestRail、Zephyr、Xray など) に直接インポートできる構造化フォーマットを求めてください。次の表は、優れたテスト ケースのコンポーネントを示しています。
エリア
説明
例
ID
固有のID
TC-PWD-014
タイトル
簡単な目的
期限切れのリンクは拒否されます
前提条件
テスト前に必要な条件
リセットリンクは 31 分前に生成されました
ステップ
連続アクション
1. リンクをクリックします。 2. 新しいパスワードを入力します。
テストデータ
使用される具体的な値
古いリンク、新しいパスワード「Abc!2345」
期待される結果
検証対象の動作
「リンクの有効期限が切れました」エラー、パスワードは変更されません
合格基準
トレーサビリティリンク
AK-3: リンクは 30 分間有効です
優先順位
リスクレベル
高い
コピー可能な 4 つのテンプレート
1) 技術ベースのシナリオ制作:
あなたの役割: 上級テスト設計者。機能のテスト ケースを生成: [機能と許容基準]。適用: 等価クラス、ブレークポイント分析、デシジョン テーブル。3 つのグループで出力を提供: ポジティブ / ネガティブ / エッジ ケース。各ケース: ID、前提条件、ステップ、テスト データ、期待される結果、関連する許容基準、優先度 (高/中/低)。
2) エッジケースハンター:
次の機能について、通常見落とされるエッジ ケースを 10 個リストします: [機能]。それぞれについてなぜリスクがあるのかを一文で書きます。空/null、入力が長すぎる、同時実行、タイムアウト、フォーマット エラー、Unicode/絵文字、マイナス/ゼロ、ネットワーク停止などの軸について考えてみましょう。
3) デシジョンテーブルの作成:
次のビジネス ルールのデシジョン テーブルを作成します: [rules].Columns: 条件の組み合わせ。行: 各条件と期待されるアクション。達成不可能または矛盾する組み合わせにフラグを立てます。次に、それぞれの組み合わせに対するテスト ケースを提案します。
4) トレーサビリティ管理:
次の許容基準のリストと次のテスト ケースがあるとします:[基準] / [ケース]。 NO テスト ケースによってどの許容基準が満たされるか (カバレッジ ギャップ)、どの基準にも満たされないケース (冗長ケース) が表形式で表示されます。
ミニケース3個
ケース 1 — エッジ状態の値。フィンテック チームの専門家は、送金機能用に 18 個のスクリプトを作成しました。彼は「エッジケースハンター」テンプレートを AI に適用しました。 AIは「2つのデバイスから同時に同じ残高を転送する」という状況（同時実行）を思い出させました。このシナリオをテストしたところ、二重支出の脆弱性が発見され、運用開始前に解決されました。単一のフリンジ状況により、潜在的な 6 桁の損失が回避されました。
ケース 2 — 膨らみをトリミングする。あるチームがAIに会員フォームのスクリプトを作成させたところ、74件のケースが登録された。トレーサビリティ テンプレートを実行すると、74 件のケースが 9 件の合格基準のみを満たしており、多くのケースが同じ同等性クラスを再テストしていることがわかりました。セットは 74 件から 23 件の重要な症例に減少しました。実行時間は 68% 減少しましたが、カバレッジは減少しませんでした。
ケース 3 — 間違った仮定。 AI は、日付フィールドに「2 月 31 日」などの無効な日付をテストすることを提案しましたが、チームが使用していたカレンダー コンポーネントがすでにこれをブロックしていたことは知りませんでした。専門家は、AI によって生成された 6 つの日付シナリオのうち 4 つを、製品のコンテキストでは不要であるとして削除しました。 AI が生み出す可能性。製品情報の選択を行いました。
よくある間違い
- 受け入れ基準を示さずにスクリプトをリクエストする。何が真実なのかを知らずに、AI は表面的なシナリオを作成してしまい、多くの場合、本当のリスクを見逃してしまいます。
- 検査結果が陽性だったことに落ち着いているところだ。ネガティブなケースやエッジケースを明示的に望んでいません。ここにエラーが潜むことがよくあります。
- 生み出されたものをありのままに受け入れる。 AI が製品のコンテキストを知らないことを忘れ、不必要または不可能なシナリオをセットに残します。
- トレーサビリティを回避します。ケースを受け入れ基準に関連付けない。その結果、どの基準がテストされていないのか (カバレッジギャップ) がわかりません。
- 数量の誤謬。 「台本が60本公開された」ので嬉しい。価値は数値ではなく、リスクをカバーする範囲にあります。
要約すれば
テスト設計とは、一文の要件を、ソフトウェアの正しさを証明する具体的な実行可能なケースに変換することです。 AI はこの変革を大幅に加速します。AI は、許容基準、古典的なテスト手法 (等価クラス、ブレークポイント、デシジョン テーブル、状態遷移)、および明確な出力形式を与えると、包括的な青写真を生成します。しかし、AI はポジティブな方向に偏っており、製品のコンテキストを知らず、不必要な肥大化を引き起こす可能性があります。あなたの仕事は、ネガティブなケースやエッジケースを明示的に要求し、トレーサビリティを確立し、リスクごとに優先順位を付け、プルーニングすることです。
アプリケーションタスク
独自のプロジェクトから機能を選択し、承認基準を書き留めます。 「テクニックベースのシナリオ生成」テンプレートでAIにテストケースを生成させます。次に、「エッジケースハンター」と「トレーサビリティチェック」テンプレートを適用します。その結果、(1) AI がスキップするエッジ ケースを少なくとも 3 つ追加し、(2) どの許容基準にも当てはまらないケースを除外し、(3) 未テストの許容基準がある場合は新しいケースを書き込みます。最終セットをスプレッドシートに注ぎます。
チェックリスト
- [ ] 脚本を依頼する前に、受け入れ基準を明確にしました。
- [ ] YZさんに名前による同値類と境界値解析を依頼しました。
- [ ] 正、負、エッジ状態を個別に生成しました。
- [ ] 各テスト ケースを合格基準 (トレーサビリティ) にリンクしました。
- [ ] スコープギャップと不要なケースを表で確認してみました。
- [ ] リスク別に優先順位を付けて、膨らんだセットを剪定しました。