Velocity活用の基礎｜第8回
CI/CDは、変更を統合し、テストや提供までの手順を継続的に進める考え方です。電話サービスでも、変更のたびに必要な試験を実行できれば、問題を早い段階で見つけやすくなります。Velocityを組み込む際の設計事項を整理します。
1. どの変更をきっかけにするか
すべての変更で全経路を実行すると、結果を待つ時間が長くなることがあります。案内、分岐、共通処理など、変更の種類に応じて確認範囲を選ぶ設計を考えます。
最初は重要な短い試験を実行し、より広い回帰試験を別の段階で行う方法もあります。これは運用設計の例であり、製品の固定された実行方式ではありません。
変更箇所から対象経路を選ぶ際は、変更の影響範囲と回帰試験も確認してください。
2. 試験の前提を自動実行に合わせる
手動なら気づけるデータ不足や環境未準備も、自動実行では失敗として現れます。試験対象の版、接続先、データ、受け側が準備できたことを確認してから実行します。
他の試験と同じデータを使う場合は、同時実行による干渉を防ぎます。予約や更新を行う試験では、準備と後処理を含めて再実行可能にします。
| 段階 | 確認事項 |
|---|---|
| 起動前 | 版・接続先・データの準備 |
| 実行中 | 完了と異常終了の把握 |
| 結果取得 | 失敗・未実行・未取得を区別 |
| 提供判断 | 重要経路と残る課題 |
3. 起動・完了・結果取得を分ける
試験を開始する要求が成功しても、試験そのものが合格したとは限りません。完了を確認し、結果を取得して、リリース判断へ渡す流れを設計します。
公式ページではCI/CDとの連携が紹介されています。利用するAPIや連携方式、権限、実行上限、結果の取得方法は自社の構成に合わせて確認します。
4. 失敗と未実行の扱いを決める
製品の動作不良、試験環境の問題、実行自体の失敗を区別します。結果を取得できなかったものを合格扱いにせず、確認が完了していない状態として扱います。
一時的な失敗を再実行する場合も、最初の結果を残します。成功するまで繰り返すだけでは、不安定な動作を見逃すおそれがあります。
実行結果を改善へつなげるには、試験失敗の分類と再試験の手順も参考になります。
5. 人が判断する情報をそろえる
重要経路の結果、未解決事項、未実施範囲、変更した版をまとめます。リリースを止める条件と、例外を承認する担当を事前に決めます。
試験連携の目的は、承認をなくすことではなく、判断に必要な情報を繰り返し提供することです。運用が安定してから実行範囲や頻度を広げます。
6. 具体例で確認する
以下は説明のための仮想例です。
夜間に自動試験を起動する運用では、朝に担当者が結果を見るまで対象環境が変わるかもしれません。試験した版と実行時刻を結果へ対応づけ、結果がどの変更に対するものか追えるようにします。試験が実行されなかった場合も担当者が気づけるよう、起動失敗や結果未取得の扱いを別に決めておきます。
参考資料とご相談
本記事で参照した資料：Cyara公式資料。本記事の手順や表は運用・試験設計の例です。利用できる項目や連携は導入構成に合わせて確認してください。
コールフローの棚卸しと期待結果の整理から始める際は、VelocityによるIVRの機能・回帰試験をご覧ください。IVR・連携システムの試験自動化を相談するから、自社の構成に合わせた確認範囲をご相談いただけます。