自動化の受入テストはどう準備する？

動いていると言うには共通基準が必要

自動化がファイルを読み、見積表を作ります。開発者は画面に結果が出たので完了と考えますが、企業側は一部の行が欠けていると気づきます。同じ出力への判断が違うのは、受入基準を最初に決めていないためです。受入テストは、どの入力がどの出力になるべきかを共同で確認できる形にします。納品の話し合いが印象だけに頼らなくなります。

ソフトウェア完成後ではなく、業務の設計段階から始めます。責任者と小さなサンプルデータを作り、正解を手作業で説明します。見積計算に使う項目、記録を除外する条件、人の承認が必要な操作を記載します。開発者も同じ例を使います。後で見つかった事例が範囲の追加なのか、既存ルールへの違反なのかが分かりやすくなります。

代表的なデータを選ぶ

整った記録だけを試すのは簡単ですが、日常業務はそうとは限りません。空欄、重複、不正な日付、想定外の文字、同名の別顧客を例に含め、選んだ理由を書きます。実際の個人データを不要にテスト環境へ持ち込まないでください。代表データでも実システムの項目長や形式を保ち、アプリが出会う条件に近づけます。

行数だけでは正しさを判断できません。入力と出力の項目対応、合計の計算、無効な記録の保存先も確認します。除外理由は見えるようにし、再実行で同じ記録を二重作成しないようにします。一部の例を開発者と共有し、一部を納品確認に残すこともできますが、すべての期待は明確な業務ルールに基づく必要があります。

期待する結果を書き出す

各テスト行にシナリオ、入力、操作、期待出力、実際の結果を設けます。例えば商品コードが空の記録は、見積を作る代わりに確認待ち一覧へ入るべきかもしれません。エラーメッセージの意味も期待結果に含め、利用者が修正すべき項目を理解できるようにします。誤操作を防ぐことも、正しいファイルを作ることと同じく受入の一部です。

丸め処理、日付、文字比較には曖昧な表現を使いません。業務責任者が認めたルールを具体例で示します。価格の出典や通貨の扱いが不明なままでは結果を評価できません。判断できない場合に停止したり権限のある人へ回したりする必要があれば、その動作を別に試します。推測で続行することが適切とは限りません。

エラーと中断を忘れない

ファイルがない、接続が切れる、外部サービスが応答しないときの動作を書きます。半分まで処理した後の再起動は以前の記録を壊さないか、利用者にエラーが見えるか、ログに完了済み記録が残るか。こうした問いは成功時だけでなく、企業が制御を保てるかを試します。中断試験は実際の取引を生まない環境で行います。

復旧計画も具体化します。誤った出力でも元データは残るか、以前の結果を保存できるか、どの操作を戻せるかを確認します。取り消せない操作を自動化する前には、人の承認や別の確認点を検討します。テスト記録は例だと明示します。実顧客への試験通知や実際の支払い開始は、受入確認の近道にはなりません。

権限と利用者の流れを一緒に試す

管理者アカウントだけで試すと、一般利用者の問題を見逃します。関係する役割で、開ける画面と実行できる操作を確認します。権限のない人はボタンが見えないだけでなく、操作自体ができてはいけません。使った役割を報告書に記録します。成功した役割が分からなければ、他の社員にも同じ結果が出るとは言えません。

データ選択、事前確認、実行、結果表示、例外処理まで追います。出力を別のアプリが使うなら、その受け渡しも試験に含めます。ファイル生成だけでは不十分な場合があります。責任者は結果を普段の仕事で使い、誤りを見分けられるでしょうか。こうした受け渡し点から自動化フローを定義します。

納品報告を判断資料にする

終了時には合格、不合格、未実行を分けます。残った不具合には影響、暫定対応、再試験の条件を書き、未解決を成功件数に含めません。責任者が受入か修正依頼かを判断できる情報を揃えます。版、試験日、データセットを記録すると、次の版で繰り返す試験も判断しやすくなります。

最初の受入後は、小さな変更ごとに全体を試し直す必要がない場合もあります。変更ルールに関係する試験と基本フローを再実行します。以前の合格は新しい版の証拠にはなりません。データ業務では一括データ転送を記録比較と合わせて確認します。小さく明確で再現可能な試験群は、変更管理の一部になります。

注意：デモと受入は異なる

用意した動画で滑らかに動いていても、実際の受入テストの代わりにはなりません。特定の版とデータで再現可能な試験が必要です。性能要件があれば環境と測定方法を説明し、未確認の時間や成功率を約束しません。目的は納品範囲を見えるようにし、企業が認めた動作を記録することであり、完璧さの主張ではありません。

作業の終わりには、使った例と決定を一緒に保存します。次の担当者がその方法を選んだ理由を理解できるようにします。不明点は隠さず、責任者と確認しましょう。小さな実地試行が、立派でも使われない文書より多くを教えてくれることがあります。定期的な意見をもとに改善します。

よくある質問

最初の一歩は？

実際の業務と代表的な例を一つ選び、期待する結果を説明します。

誰が確認する？

業務の責任者とアプリを利用する人が一緒に確認します。

いつ更新する？

業務やアプリが変わった際に、影響を受ける手順を再確認します。