Velocity活用の基礎｜第9回
自動テストが失敗したら、最初に期待と違った段階の証拠を保存し、対象システム・試験環境・期待結果を分けて調べます。Velocityの結果を読む場合も、失敗という判定だけで対象システムの不具合と決めつけず、再実行前に条件を残します。
1. 最初に失敗した段階を見る
後続の処理が連続して失敗していても、原因は最初の入力や接続にある場合があります。最初に期待と違った地点を見つけ、そこへ到達するまでの前提を確認します。
同じ経路で直前に成功した結果があれば、版、データ、時刻、接続条件を比べます。比較対象がない場合も、確認できた事実から順に整理します。
2. 失敗を三つの視点に分ける
対象システムが要件を満たさない場合、試験用データや受け側が準備できていない場合、期待結果が仕様変更に追いついていない場合を分けます。
一つの失敗に複数の要因が重なることもあります。分類は調査を始めるための仮説であり、最初の分類を確定原因として扱わないようにします。
| 原因候補 | 確認するもの |
|---|---|
| 対象システム | 要件と実際の応答 |
| 試験環境 | データ・接続・受け側 |
| 期待結果 | 仕様の版と承認内容 |
判定条件の書き方は、自動テストの期待結果の設計で確認できます。修正後は、機能テストと回帰テストの違いを踏まえ、変更した箇所と影響を受ける既存経路を分けて試験します。
3. 再実行の前に結果を残す
失敗した実行の条件と証跡を保存してから、再現を試します。再実行で成功した場合も、失敗がなかったことにはしません。
断続的な問題では、成功と失敗の回数、時間帯、同時に動いていた処理を比べます。毎回異なる条件で試すより、条件を固定してから一つずつ変えるほうが調査しやすくなります。
4. 修正する対象を選ぶ
期待結果が古いなら、承認済みの仕様に合わせてテストを更新します。データが不適切なら準備手順を直します。実装の問題なら、再現条件を開発担当へ渡します。
原因を調べずに待ち時間だけを延ばしたり、判定項目を削ったりすると、本来検出すべき問題まで通過させる可能性があります。変更の理由を記録してレビューします。
5. 再試験と回帰試験を組み合わせる
修正箇所が直ったことを再試験で確認し、関連する既存経路への影響を回帰試験で確認します。同じ失敗だけが消えたことをもって全体の確認完了としないことが大切です。
Cyaraの研修資料でも結果分析が扱われています。自社では、結果と変更記録を結び付け、次回の調査で再利用できる形にまとめると、試験資産の価値が高まります。
6. 具体例で確認する
以下は説明のための仮想例です。
番号入力後に想定の案内が流れなかった例では、入力が受け付けられたか、試験データが対象条件を満たすか、案内の仕様が変わっていないかを順に見ます。期待結果を書き換えるのは、その内容が承認された仕様と違うと確認できた場合です。再実行で成功した場合も、最初の失敗と条件差を残します。
| 記録欄 | 説明用の記入例 |
|---|---|
| 最初の差 | 番号入力後、期待する案内が確認できない |
| 正常だった範囲 | 接続と入力前の案内までは確認済み |
| まだ確定していないこと | 入力受付、試験データ、案内仕様のどこに差があるか |
| 残す証跡 | 実行識別子、時刻、対象版、入力条件、取得できた応答 |
| 次の確認 | 承認済み要件と条件を照合し、一つずつ比較して再試験 |
参考資料とご相談
本記事で参照した資料：Cyara Academy Course Guide（2023年公開の研修資料）およびCyara Velocity公式製品ページ。本記事の手順や表は運用・試験設計の例です。利用できる項目や連携は導入構成に合わせて確認してください。
IVRの機能・回帰試験の進め方は、Cyara Velocityの自動テストと導入支援をご覧ください。対象フロー、期待結果、現在の結果確認方法をもとに、IVR自動テストの設計と結果分析を相談することができます。