Velocity活用の基礎｜第1回
音声案内を少し変更しただけなのに、別の窓口へつながらなくなった。電話サービスでは、変更箇所以外への影響も確かめる必要があります。Cyara Velocityは、こうした機能試験と回帰試験を自動化し、設計と確認内容をつなげるための製品です。
1. 機能試験は「期待どおり」を確かめる
例えば「1番を押すと契約窓口へ進む」という要件なら、発信、案内、番号入力、到達先を順に確認します。接続できただけでは、利用者の目的を達成したかは分かりません。
期待する結果を明確にすると、担当者が変わっても同じ基準で判定できます。案内の内容、入力後の動作、応答時間の扱いを試験前にそろえます。
2. 回帰試験は既存の動作への影響を見る
新しいメニューを追加したとき、追加部分だけでなく、既存の問い合わせや時間外案内も確認します。共通の設定を変更した場合は、想定以上の経路へ影響することがあるためです。
毎回同じ確認を手作業で繰り返すと、時間がかかり、実施した範囲も分かりにくくなります。繰り返しが多く、判定条件が明確な項目から自動化を検討します。
試験の目的を整理する際は、機能試験と回帰試験の違いも確認してください。
| 試験 | 主な問い |
|---|---|
| 機能試験 | 要求した動作を満たすか |
| 回帰試験 | 既存の動作に悪影響がないか |
| 負荷試験 | 多くの利用が重なっても動くか |
3. Velocityで設計とテストをつなぐ
公式製品情報では、ジャーニーの可視化、テスト作成・保守、回帰試験、開発工程との連携が紹介されています。利用者がたどる経路を設計し、その設計に対応するテストを管理する考え方です。
自動生成されたテストにも、要件との照合が必要です。現在の動作を取得できたことと、その動作が正しいことは同じではありません。業務側と設計を確認します。
入力と期待結果の具体化には、IVRのテスト項目の作り方が参考になります。
4. 実行する前提をそろえる
試験先の番号、利用するデータ、受け側、実行時間、必要な接続を準備します。テストデータの不足や接続設定の誤りでも失敗するため、製品の不具合と試験準備の問題を区別します。
本番へ影響する予約や登録が含まれる場合は、試験専用の条件と後処理を決めます。実際のお客様や受付担当者へ不要な処理を発生させない設計が必要です。
小規模な試行へ進む際は、Velocity導入前の準備で対象経路や判定条件を整理できます。
5. 合格後も確認範囲を明示する
全件合格とは、実行したテストの条件を満たしたという意味です。未実施の分岐や、想定していないデータ条件まで正しいとは限りません。
Velocityの機能・回帰試験と、負荷時の性能確認、運用開始後の監視は目的が異なります。確認済みの範囲と残る確認事項を示し、人がリリースを判断できる結果にまとめます。
6. 具体例で確認する
以下は説明のための仮想例です。
契約窓口を追加する例では、新しい番号入力で正しい窓口へ進むことを機能試験で確認します。同時に、以前からある問い合わせ窓口や時間外案内を回帰試験へ含めます。各ケースの結果を「接続成功」だけで終わらせず、案内と到達先まで記録すると、変更した機能と既存の業務を分けて説明できます。
参考資料とご相談
本記事で参照した資料：Cyara公式資料。本記事の手順や表は運用・試験設計の例です。利用できる項目や連携は導入構成に合わせて確認してください。
コールフローの棚卸しと期待結果の整理から始める際は、VelocityによるIVRの機能・回帰試験をご覧ください。IVR・連携システムの試験自動化を相談するから、自社の構成に合わせた確認範囲をご相談いただけます。