単体テストや結合テストを終えたあと、総合テストではシステムを実際の業務に近い流れで確認していきます。
私がアプリSEとして総合テストに関わっていたときは、実際の業務を想定した確認を行っていました。
個々の機能だけを見るのではなく、
- 実際の業務の流れで処理が最後まで進むか
- 用意したデータで一連の処理に問題が出ないか
- 外部システムとの連携に問題がないか
- エラーが発生した場合に状況を共有できるか
といった点を確認していました。
この記事では、私が総合テストで実際に意識していたことを紹介します。
総合テストでは業務の最初から最後まで通していた
途中の一機能だけを動かして終わるのではなく、業務の開始から処理を進め、外部連携や後続処理を含めて最後まで結果を確認します。
私自身、総合テストでは、この一連の流れを確認することが重要だと考えていました。
IPAの資料でも、要件定義で明確になった業務シナリオを総合テストで漏れなく実施するための準備や、業務フローを活用した総合テストシナリオの作成が示されています。
単体テストや結合テストで個別の機能や接続を確認していても、業務全体を通して確認する段階では見る範囲が広がります。
私が担当した総合テストでは、個々の機能だけでなく、業務全体の流れとして最後まで成立するかを見るようにしていました。
過去データがあれば実際のデータを使うこともあった
私が経験した総合テストでは、過去の本番データをテストに使うこともありました。
その場合でも、個人情報に関係する部分はそのまま使用せず、マスキングしていました。
過去データを利用できる場合には、それを使って一連の処理を確認します。
一方で、使用できる過去データがない場合には、本番で発生する内容を想定したテストデータを作成していました。
私が経験した環境では、
- 利用できる過去データがあれば使う
- 個人情報に関係する部分はマスキングする
- 適切な過去データがなければ想定データを作る
という形で準備することがありました。
実際の業務で扱うデータに近い条件で、一連の処理を確認することを意識していました。
外部システムとの連携も可能であれば実際に確認していた
総合テストでは、外部システムとの連携も確認していました。
連携先にもテストできる環境があり、実際にデータをやり取りできるのであれば、連携まで含めて確認していました。
一方で、相手側にテスト用の環境がなく、実際の連携を総合テストで行うことが難しい場合もありました。
そのような場合には、実際のデータ連携を行わず、机上で処理内容や連携方法を確認することもありました。
私が経験した範囲では、実際に確認できる連携は動かし、難しい部分は机上確認で補うということがありました。
本番環境しかない連携先では送信先を何度も確認していた
私が経験した総合テストの中には、連携先に本番環境しかないケースもありました。
こちら側の環境は分けていても、連携先の都合によっては、本番側とのデータのやり取りが発生することがありました。
このような作業で怖かったのが、送信先を間違えることです。
誤って意図しない本番側の場所へデータを送ると、そのままDBへの登録やデータ作成などにつながる可能性がありました。
そのため私は、
「送信先はここで間違いないか」
「この階層へ送ってよいか」
といった点を、事前に明示的に複数回確認していました。
相手からすると、不思議に思っていたかもしれません。
それでも私は、本番側へ誤ってデータを送ることをかなり怖いと感じていました。
そのため、どの環境のどの送信先へデータを送るのかは、作業前に何度も確認していました。
エラーや障害は共通のファイルへ記録していた
総合テストでは、エラーや障害が発生したときの記録先もあらかじめ揃えていました。
私が担当していた現場では、WBSやエラー時の記録用ファイルをSharePoint上にまとめていました。
エラーが発生した場合は共通のファイルへ記録し、全体の打ち合わせでも同じ資料を見ながら状況を共有できるようにしていました。
全体のスケジュール調整そのものは別の担当者が行うことが多く、私が主に関わっていたのはエラーや障害が発生したときの確認でした。
私にとっては、問題が起きたときに関係者が同じ資料を見られる状態にしておくことが重要でした。
総合テストで単体・結合テストレベルの不具合が出ると厳しく見られた
私が経験した現場では、
「これは単体テストで見つけるべきだったのではないか」
「結合テストで確認できたのではないか」
と言われるような不具合が総合テストまで残っていると、厳しく見られることがありました。
私の経験では、総合テストは、それまでの単体テストや結合テストでどこまで確認できていたかが表れやすい工程でもありました。
単体テストについては単体テスト仕様書で意識していたこと、結合テストについては結合テストで確認していたことでも紹介しています。
エラーが全く出ない場合もテスト内容を確認したくなった
一方で、エラーや障害が全く出ない場合に、私はテスト内容をもう一度確認したくなることもありました。
もちろん、問題なくテストが完了すること自体が悪いわけではありません。
WBSどおりに進み、何も問題が起きなければ、進行面ではむしろ楽でした。
ただ、あまりにも何も起きない場合には、
「必要なテストパターンを本当に確認できているか」
と、網羅性を確認することがありました。
これは、エラーが出なければテスト不足という意味ではありません。
私自身が、結果だけでなく、予定していたテストパターンを実施できているかも確認していたという経験です。
まとめ：総合テストでは業務全体を通して確認していた
私の経験では、総合テストで重要だったのは、個々の機能をもう一度確認することではなく、業務・データ・外部連携・運用を一つの流れとして成立させられるかを見ることでした。
単体テストや結合テストとは確認する範囲が変わり、実際の業務に近い形で全体を見る工程だったと感じています。
