Velocity活用の基礎｜第7回
電話システムを移行するときは、「新環境へ電話がつながった」だけでは確認が足りません。案内、分岐、営業時間、外部連携など、利用者がたどる流れを旧環境と比較します。Velocityを使う場合も、同じ条件で比較できる準備が重要です。
1. 変えない部分と変える部分を分ける
移行に伴って、案内や業務フローを改善することもあります。その場合、旧環境と完全に一致することを合格条件にすると、意図した変更まで不具合として検出してしまいます。
引き継ぐ仕様、変更する仕様、廃止する仕様を一覧にします。旧環境の挙動に既知の不具合がある場合は、それを正解として固定しないようにします。
2. 基準となる経路を残す
代表番号から業務が完了するまでの経路、入力、前提データ、案内内容を記録します。Velocityの資料では、IVRの構造把握を移行の基準づくりに活用する考え方が紹介されています。
取得した経路だけで全体を網羅したとみなさず、休日、例外、認証条件などの不足を業務要件から補います。
Avayaからの移行を検討する場合は、Avayaからクラウド移行する際の同等性確認も参考になります。
| 差分 | 判断の方向 |
|---|---|
| 承認済みの仕様変更 | 新仕様に対して確認 |
| 想定外の動作 | 原因調査と再試験 |
| 前提条件の違い | 条件をそろえて比較 |
3. 比較条件をできるだけそろえる
同じシナリオでも、顧客データ、時刻、受け側、接続条件が異なれば結果は変わります。比較前に一致させる条件と、一致できない条件を整理します。
番号が変わる場合は接続先を切り替えても確認意図が同じになるようにします。特定環境だけに依存する値は、共通の判定と分けて管理します。
4. 差分を三つに分類する
差が見つかったら、意図した仕様変更、想定外の動作、試験条件の違いに分けます。すべての差分を修正対象にするのではなく、承認された仕様と照合します。
音声の一致だけでなく、業務完了やデータの受け渡しなど、目的に必要な結果を確認します。画面やログで補う確認がある場合は、その証跡も対応づけます。
5. 切り替え判断と切り戻しを準備する
重要な経路が失敗した場合に移行を延期する条件、再試験の範囲、切り戻しの判断担当を決めます。合格件数だけで移行可否を決めないことが重要です。
切り替え後の監視も別に準備します。移行前の比較試験、負荷時の確認、実運用での監視を組み合わせ、各段階で確認した範囲を明確にします。
切替後の重要経路は、移行前後の監視と切り戻し確認も組み合わせて継続的に確認します。
混雑時の性能まで確かめる場合は、移行時に組み合わせる負荷試験の進め方を別途計画します。
6. 具体例で確認する
以下は説明のための仮想例です。
旧環境は同じ入力で担当者へ転送し、新環境は先にFAQを案内するよう仕様変更した例では、音声や経路の差は想定内です。ただし、FAQから担当者へ進む条件や終了時の案内は、新仕様に対して確認する必要があります。「旧環境と違うから失敗」「新環境でつながったから合格」のどちらにも寄せず、承認した要件で判断します。
参考資料とご相談
本記事で参照した資料：Cyara公式資料。本記事の手順や表は運用・試験設計の例です。利用できる項目や連携は導入構成に合わせて確認してください。
コールフローの棚卸しと期待結果の整理から始める際は、VelocityによるIVRの機能・回帰試験をご覧ください。IVR・連携システムの試験自動化を相談するから、自社の構成に合わせた確認範囲をご相談いただけます。