Velocity活用の基礎｜第4回
設計書には正しい流れが書かれていても、テスト側に反映されていなければ確認漏れが起きます。Velocityを使った試験では、カスタマージャーニー、つまりお客様が目的を達成するまでの道筋と、確認内容を対応づけることが重要です。
1. 装置の並びより利用目的を先にする
「IVRから別システムへ接続する」だけでなく、「利用者が契約内容を確認できる」と目的を書きます。目的が明確なら、途中でどの情報や応答が必要かを整理できます。
電話が接続しても必要な案内がなく終了すれば、利用目的は達成していません。技術的な成功と業務上の成功を分けて考えます。
2. 設計に判定可能な条件を加える
各段階で、入力、条件、期待する応答、次の状態を記載します。「適切に転送する」といった表現は、どこへの転送か、何を確認して到達と判断するかまで具体化します。
動的な情報を案内する場合は、固定部分と試験データによって変わる部分を分けます。設計段階でこの違いが明確なら、テストの判定条件も作りやすくなります。
電話経路ごとの入力と分岐は、IVRテスト項目の具体化を参考に整理してください。
| 設計の要素 | テストに必要な情報 |
|---|---|
| 利用目的 | 完了を判断する条件 |
| 分岐 | 入力と前提データ |
| 変更 | 適用版と更新対象ケース |
| 要件 | 対応する実行結果 |
3. 自動生成後もレビューする
Velocityは設計とテスト作成をつなぐ考え方を持つ製品です。自動生成は作業を助けますが、業務要件の欠落や誤解が設計にあれば、そのままテストへ引き継がれる可能性があります。
業務担当は目的と案内を、開発担当は条件と実装を、テスト担当は検証可能性を確認します。全員が同じ図を見ても、見る観点は分けると効果的です。
4. 変更の理由と版を残す
案内変更や分岐追加の際は、変更理由、承認者、適用時点を記録します。設計、テスト、試験対象の版が異なると、正しい変更でも失敗に見えることがあります。
変更によって追加するテスト、修正するテスト、残すテストを整理します。不要になったケースは理由を残して除外し、履歴を追える状態にします。
5. 対応表で確認漏れを探す
重要な要件にテストが対応しているかを見ます。テスト数が増えていても、同じ経路の似た確認ばかりなら、別の重要経路が未確認のままかもしれません。
要件から結果へ、結果から要件へたどれると、失敗の業務影響も説明しやすくなります。設計とテストをつなぐ価値は、実行を速めることに加えて、確認範囲を説明できることにあります。
6. 具体例で確認する
以下は説明のための仮想例です。
住所変更のジャーニーなら、本人確認、対象情報の入力、変更内容の確認、完了案内を一つの目的へ結び付けます。電話が最後まで進んでも変更が保存されていなければ、業務は完了していません。電話経路で確認する項目と、外部システム側で確認する項目を分け、必要な連携や証跡を準備します。
Salesforceと連携する構成では、Salesforce連携を着信から記録まで確認する手順も参考に、電話と業務処理の確認範囲を決めます。
参考資料とご相談
本記事で参照した資料：Cyara公式資料。本記事の手順や表は運用・試験設計の例です。利用できる項目や連携は導入構成に合わせて確認してください。
コールフローの棚卸しと期待結果の整理から始める際は、VelocityによるIVRの機能・回帰試験をご覧ください。IVR・連携システムの試験自動化を相談するから、自社の構成に合わせた確認範囲をご相談いただけます。