Velocity活用の基礎｜第2回
機能試験と回帰試験は、同じ手順を使う場合があっても、確認の目的が違います。Velocityで自動化を進める前に、この違いを整理すると、変更時にどのテストを実行すべきか決めやすくなります。
1. 機能試験は要件から出発する
新しく追加した予約メニューなら、案内、入力、予約処理、結果の通知などを要件と照合します。正常な入力だけでなく、入力なしや対象外の値に対する動作も必要に応じて確認します。
「画面や音声が何か返った」では不十分です。利用者に何を伝え、どの状態になれば目的が達成されるのかを具体的な期待結果にします。
2. 回帰試験は変更の影響を探す
予約メニューの追加により、既存の問い合わせ窓口や共通の認証処理が変わっていないかを確かめます。直接変更していない経路でも、共通部品や設定を使っていれば影響する可能性があります。
前回使った機能試験のケースを、以後の回帰試験へ組み込むこともできます。試験の名称だけで別々の資産と考える必要はありません。
| 変更例 | 新機能の確認 | 既存機能の確認 |
|---|---|---|
| 予約メニュー追加 | 予約の完了 | 問い合わせ分岐 |
| 営業時間変更 | 新しい時間帯の案内 | 休日・例外日 |
| 共通認証の更新 | 更新した認証条件 | 認証を使う各経路 |
3. 変更内容から実行範囲を決める
案内文だけの変更、分岐条件の変更、外部連携の変更では、影響範囲が違います。変更箇所と、そこを通る経路を対応づけて選定します。
重要な業務経路は、直接の影響が小さく見えても毎回確認する候補になります。一方、全件を毎回実行できない場合は、実施しなかった理由と残るリスクを明記します。
クラウド基盤の更新で確認すべき範囲は、SaaSアップデート時のIVR回帰試験も参考になります。
4. 自動化の結果を同じ基準で読む
Velocityは機能・回帰試験の自動化を支援する製品として案内されています。テスト実行後は、失敗が実装、期待結果、試験環境のどれに由来するかを確認します。
要件が正しく変更されたのに古い期待結果が残っていれば、テストは失敗します。このとき合格するまで基準を緩めるのではなく、変更の承認内容に合わせて更新します。
変更前後を比較する基準は、電話試験の期待結果の決め方で項目別に整理できます。
5. 試験計画に目的を書き添える
各ケースに業務目的、対象経路、実行条件、期待結果、変更との関係を記録します。何を保証したいケースなのか分かれば、保守や選別がしやすくなります。
リリース判断では、成功率だけでなく、未実施と未解決の内容を示します。多数の軽微なケースが合格しても、重要な受付が失敗していれば影響は大きいためです。
6. 具体例で確認する
以下は説明のための仮想例です。
共通の案内文を更新する例では、その案内を使う窓口が三つあれば、変更箇所は一つでも影響候補は三経路です。共通部品と利用経路の対応を記録しておけば、次の更新時に試験範囲を選びやすくなります。過去に問題が起きた経路は、重要な回帰試験として残す候補になります。
参考資料とご相談
本記事で参照した資料：Cyara公式資料。本記事の手順や表は運用・試験設計の例です。利用できる項目や連携は導入構成に合わせて確認してください。
コールフローの棚卸しと期待結果の整理から始める際は、VelocityによるIVRの機能・回帰試験をご覧ください。IVR・連携システムの試験自動化を相談するから、自社の構成に合わせた確認範囲をご相談いただけます。