Velocity活用の基礎｜第3回
IVRは、自動音声で案内し、番号入力などに応じて次の処理へ進む仕組みです。テスト項目は、案内を順番に聞くだけでは足りません。利用者が選べる分岐と、その結果を組にして整理すると、Velocityで扱うテストの土台になります。
1. 利用者の目的ごとに経路を描く
契約の確認、住所変更、担当者への相談など、利用者の目的を出発点にします。電話番号からどの案内を通り、どこで目的が完了するかを書き出します。
メニューの数だけを数えると、途中の戻りや外部処理を見落とすことがあります。開始点、分岐条件、終了点をそろえた経路として整理します。
2. 入力と期待結果を対応づける
「1を押す」だけでなく、どの案内の後に入力し、何が起きれば正しいかを決めます。同じ番号でも、案内が違えば意味が変わるためです。
入力なし、許可されていない入力、やり直し、前のメニューへ戻る操作も、業務要件に沿って確認します。入力のタイミングや待ち時間も必要な条件として残します。
分岐ごとの判定基準は、案内・時間・転送の合格条件も参考に決めてください。
| 項目 | 記入例 |
|---|---|
| 前提 | 営業時間内、試験用顧客 |
| 操作 | 契約案内で1を入力 |
| 期待結果 | 契約窓口へ到達 |
| 例外 | 無入力時は再案内 |
3. 条件による分岐を見落とさない
営業時間、休日、顧客の状態、言語、認証結果などにより、同じ操作でも行き先が変わる場合があります。経路に加えて、前提となるデータや時刻を定義します。
すべての組み合わせを無条件に増やすと保守が難しくなります。重要な分岐、変更頻度、障害時の影響をもとに優先順位を決めます。
公開後に時間帯による切り替えを確かめる際は、営業時間・休日の監視条件も整理します。
4. 取得した構造を要件と照合する
Velocityの資料にはIVRの構造を発見・可視化する機能が紹介されています。現行の理解を助ける一方で、取得結果をそのまま正しい仕様として採用しないことが重要です。
認証や条件によって到達できない分岐、試験で通らなかった経路がないかを確認します。業務資料、担当者への確認、実際の動作を突き合わせて設計を整えます。
5. ケースの名前を業務で読める形にする
「ケース001」だけでなく、「営業時間内・契約窓口・正常入力」のように目的と条件を読み取れる名称にします。失敗時に影響する業務を把握しやすくなります。
作成後は、別の担当者が同じ期待結果を理解できるかレビューします。自動化の設定に入る前に曖昧さを減らすことが、結果の読みやすさにつながります。
6. 具体例で確認する
以下は説明のための仮想例です。
二つのメニューがあるだけでも、通常入力、無入力、無効入力、戻る操作を考えると確認項目は増えます。営業時間で動作が変わるなら、その条件も加わります。ケース数を先に目標にせず、どの要件を確認しているかを書き、重要な条件が抜けていないかをレビューします。似たケースを増やすだけでは、確認の広さは十分に増えません。
参考資料とご相談
本記事で参照した資料：Cyara公式資料。本記事の手順や表は運用・試験設計の例です。利用できる項目や連携は導入構成に合わせて確認してください。
コールフローの棚卸しと期待結果の整理から始める際は、VelocityによるIVRの機能・回帰試験をご覧ください。IVR・連携システムの試験自動化を相談するから、自社の構成に合わせた確認範囲をご相談いただけます。