定義が不十分な業務フローを自動化すると、その曖昧さまでソフトウェアに持ち込まれがちです。受け入れテストでは、プロセスの責任者とともに、提案された動作が本番環境でそのフローに頼る前に業務ルールを反映しているか確認できます。要件設計や技術テストに取って代わるものではなく、合意済みのルールと観測可能な結果を結び付けるものです。
業務受け入れテストで何を検証するか
受け入れテストでは、具体的な状況において、ソリューションやフローが業務上必要な結果を生み出すかを確認します。たとえば、一定の条件を満たす申請が正しいステータスに遷移し、必要な記録が作成され、対応すべき担当者にタスクが割り当てられるかを検証します。
関連する他の活動とは、次のように異なります。
- 非公式なプロセスレビュー：話し合いや手順の確認で問題が見つかることはありますが、検証可能な条件や結果が明確に残るとは限りません。
- 技術テスト：APIの応答、関数、連携、エラー処理などを検証します。実装された業務ルールが誤っていても、テストに合格することがあります。
- 受け入れテスト：合意済みの業務ルールの観点から、責任者が評価できるシナリオと基準を用いて動作を検証します。
目的は、要件を別の言葉で一つずつ繰り返すことでも、コードのテスト戦略全体を定義することでもありません。「利用者は、この動作をプロセス上妥当なものとして受け入れるか」という問いに答える、扱いやすい一連の状況について合意することです。
実際の業務を反映するシナリオを選ぶ
まず、プロセスの主な流れを図にします。何が開始のきっかけとなり、どのような判断が行われ、誰が関与し、どう完了するのかを整理します。次に、判断を変えたり介入を必要としたりする例外を特定します。あらゆる組み合わせを列挙する必要はありませんが、結果、リスク、運用負荷に影響する差異はカバーするのが望ましいです。
最初のシナリオ群には、通常、次の内容を含めます。
- 通常フロー：有効な入力が、最も一般的なルールに従って処理され、完了に至るケース。
- 重要な例外：情報の欠落、未充足の条件、またはルートを変える確認の必要性があるケース。
- 判断の境界値：しきい値ちょうどの値と、有用であればその直前・直後の値。これにより条件に境界値を含むかが明確になり、解釈の違いを防げます。
- 再試行または重複：フローで起こり得る場合、同じ入力の再送、操作の再実行、応答の遅延を含むケース。
- 人による介入：自動処理で解決するのではなく、停止、エスカレーション、または担当者への割り当てが必要なケース。
エラーの影響、発生頻度、障害の検知しにくさを基準にシナリオの優先順位を付けます。同じルールを検証し、同じ結果になるケースが二つあるなら、一つで十分な場合があります。一方、例外によって判断者や引き受ける義務が変わるなら、別のケースとして扱うべきです。
再現可能な入力と初期状態を準備する
各シナリオでは、テスト開始前にどのような情報が存在するかを記述します。ルールに影響するフィールド、案件の事前状態、該当する場合は権限や未完了タスクを含めます。「不完全な申請をテストする」という指示だけでは、どの情報が欠け、他にどの情報が入力済みなのかが明確でなければ不十分です。
動作の評価に支障がない限り、合成データまたは匿名化データを使用します。便宜上、実際の個人データをコピーするのは避けてください。データの露出を抑えられるだけでなく、管理されたデータを使えば、業務記録の変化に左右されず同じケースを再実行できます。外部連携が関わる場合は、期待する応答と、検証中にそれをどのようにシミュレートまたは制御するかを記録します。
前提条件も記録します。たとえば、新規案件から始めるのか、すでにレビュー済みの案件から始めるのかを明示します。初期状態が統一されていないと、不一致の原因が直前のテスト、残存データ、または検証対象のルールのどれなのか判断できないことがあります。
意図ではなく観測可能な結果を定義する
各シナリオについて、確認可能な兆候を使って期待結果を記述します。「プロセスが正しく動作する」では検証できません。代わりに、何が変化し、何が変化してはならないかを示します。
- ステータス：ケースの最終ステータスと、発生すべき、または発生してはならない遷移。
- データ：作成・更新されるレコード、フィールド、識別子と、関連する値。
- 通知：送信される通知、その宛先、送信条件。
- 未完了の作業：記録されるタスク、担当者、期限、またはエスカレーション理由。
- 禁止される操作：たとえば、レビューが必要なケースをクローズしないことや、再試行時にレコードを重複作成しないこと。
観測可能な結果と、内部実装上の判断は分けておくのが望ましいです。合意済みの制約に含まれない限り、受け入れの判断を、キュー、テーブル、特定のサービスをシステムが使うかどうかに依存させるべきではありません。そうすれば、アーキテクチャが変わっても基準を有効に保てます。
ルールの未決事項を曖昧にせず、不一致に対処する
観測された結果が期待と一致しない場合は、ケース、入力、初期状態、実際の動作、期待される動作を記録します。ルールを確認した人と、未決の判断も記載します。不一致が常に技術的な不具合とは限りません。ルールの曖昧さ、受け入れ基準の不足、または合意内容と異なるシステム実装が明らかになることもあります。
修正を決める前に、見つかった問題を分類します。
- ルールが曖昧、または矛盾している：責任者が妥当な動作を決めるまで、そのケースの受け入れを中断します。
- 合意済みのルールと異なる動作：不具合、その影響、再テストの条件を記録します。
- 期待結果が古くなっている：変更をレビューして承認します。テストに合格させるためだけに基準を変更してはいけません。
- データまたは環境の問題：準備を修正して再実行し、その試行では結論を出せなかった理由を示す証拠を残します。
不一致ごとに担当者とステータスを割り当てます。判断やフォローアップのない指摘一覧は、受け入れの証拠ではなく、意見の食い違いの原因になります。
変更後にシナリオを再実行し、自動化できるか判断する
ルール、フォーム、連携、運用手順が変わったときは、受け入れ済みのシナリオを再利用できます。影響を受けるケースと、二次的な影響が及んだ可能性のある主なフローを再実行します。ソフトウェアの自動テストは技術的な検証を迅速に実行できますが、結果が業務上妥当かどうかの確認には、引き続き業務検証が必要です。特に方針や責任分担が変わる場合は重要です。
自動化の前に、各シナリオに再現可能な入力、検証可能な結果、疑問を解決できる権限を持つ担当者がそろっていることを確認します。チーム、チャネル、ケースの種類によって異なるルールを適用するなら、その適用範囲を明示します。どの動作がいつ受け入れられたか分かるよう、現行ルールのバージョンまたは参照先を管理します。
自動化前のチェックリスト
- フローの開始点と終了点、各判断の責任者が特定されていますか？
- 通常フロー、影響の大きい例外、ルールの境界値をカバーしていますか？
- 各ケースに入力、初期状態、再実行に使える安全なデータが記載されていますか？
- 期待結果は、ステータス、データ、通知、タスクの観測可能な変化として表現されていますか？
- 不一致への対処方法と、ルールを承認できる人が明確ですか？
- 実装不具合、未決のルール、準備上の問題を区別できますか？
- プロセスが変わったときに検証を再実行する基準がありますか？
「いいえ」が複数ある場合、自動化の前にフローをさらに定義する必要があります。「はい」であれば、業務プロセスの受け入れテストを共通の基盤として、運用上の受け入れと技術的なテストカバレッジを混同せずに動作を検証できます。その結果、通常フローから外れたケースも含め、何が起きるべきかについて検証可能な合意が得られます。
