【システム開発】UT、ITa、ITb、ST、UATの違いとは【テスト工程を徹底解説】

IT業界のシステム開発でよく耳にするテスト工程の名称とその内容を徹底解説します。

大前提として会社やプロジェクトによってその呼び方や指し示す範囲は異なります。そのため、一つの物差しとして考えていただければと思います。

まず、テスト工程の全体の流れは次のようになっています。

この１つ１つの工程が何を確認するためのテストであり、このテストが完了した際にはどういう状態になるのか、この後１つずつ掘り下げていきますので、ぜひ最後までご覧ください。

単体テスト（UT）
結合テスト
システム総合テスト(ST)
受入テスト（AT）
ユーザテスト(UAT)
まとめ

単体テスト（UT）

１つ目は、Unit Testのことで内部設計（プログラム仕様書）に沿って作成したテスト仕様書をもとにテストします。よく言うホワイトボックステストです。単体テスト仕様書の作成をこのタイミングを行うこともありますが、通常は内部設計工程で実施することが推奨されます。

テストデータの作成はこの工程で行うことになります。よく炎上しているプロジェクトだと、テストデータの作成に時間がかかってテスト消化が進まないという声が頻繁に聞こえてきます。これはテスト工数の見積が甘いことや、テスト実施者が仕様をわかっておらず、設計者にテストデータの作成方法を聞きながらでなければ実施できないことなどの原因が考えられますがが、先んじて対処が必要です。

何を持って「単体」と呼ぶかが非常に重要です。例えば、よくあるWebシステムの１つとしてMVCモデルを採用している場合、JSP（ビュー）、サーブレット（コントローラ）、ビジネスロジック、DAOファイルなどといったようにプログラムファイルが複数存在し、それぞれで動作検証ができる場合はそれぞれで実施することとなります。しかし、これらを”結合”したうえで１つの画面、機能、処理として成り立つように結合したものを「単体」と呼ぶこともあります。私の経験上は、現実的には後者のケースが多く、プログラムを結合させて１つの機能（画面）にしたうえで単体テストすることが多いです。

しかし、単体というからには何一つとして結合させずにテストすること意味している場合もあり、そういった解説をしているサイトなども数多くあります。ここでは、最も細かい単位という意味で、JSPはJSPファイルのみで、サーブレットはサーブレットファイルのみでテストしたということで読み進めてもらえればと思います。

いずれにしてもこの段階で、項目レベルの確認は済ませておきます。具体的には、データベースへの登録処理においては、テーブルの項目１つ１つに対して期待した値が正しく設定されているかどうか、登録内容を照会した際に画面項目の１つ１つは正しいテーブルの正しい項目から取得した値が表示されているかなど、最も細かい粒度で確認します。ここが品質の根幹となります。

最も指し示す範囲が狭い場合の「単体テスト」。ここでは、jspファイルなどのファイル単位。パターン①

結合テスト

内部結合テスト(ITa)

続いては、結合テストの１つであるIntegration Test Aの略です。結合テスト（前半）とも呼ばれます。単体テストが終わったプログラムを繋げてみる工程になります。最もわかりやすい例を挙げると、単体テストまでで画面や機能といった塊でのテストを終えている場合でいえば、画面遷移のテストや画面や機能同士がつながるかどうかのテストが該当します。

外部設計書もしくは内部設計書に記載されている画面遷移通りに遷移できるかどうかのテストになります。前工程までで完成したある塊（画面や機能）に対してすべての画面、機能を繋げていく作業ともいえます。ある画面から共通機能をきちんと呼び出して処理が完了できるか、一覧画面から画面照会し単票画面に遷移できるかなどを確認します。

また、前段までのテスト環境は、各個人のPCに構築したローカル環境（開発環境）で実施することが多いです。しかし、ここからは複数の機能を結合していくため、検証環境と呼ばれるような準本番環境にシステムをデプロイしてテストすることが多いです。

プロジェクトによっては単体テストが早く終わったメンバが複数の画面、機能を繋げてみてモンキーテスト的に叩いてバグだしすることもあります。ただ、やっぱり工程として定義するのが理想です。

単体テストではjspファイルのみのテストに留まっているような場合、１つの画面や機能になるように結合したテストを行う。パターン①

単体テストで画面や機能が出来上がっている場合、それらを繋げてみる。パターン①(上段テスト範囲実施後)及びパターン②

外部結合テスト(ITb)

３つ目はこちらも結合テストの１つであり、Integration Test Bのことで、結合テスト（後半）に当たります。ここでは、サブシステム間、モジュール間の機能を繋げて、内部結合テストよりも広い視点でつながるかどうかを検証します。

複数システムが存在しないような場合は実施しないこともあります。

また、自社管轄ではないシステム（＝対向システム、IF連携先システム）との連携テストは後続工程で実施するイメージです。あくまでこの工程では内部結合テストの範囲を広げたイメージと考えるのが自然です。例えば、SAPなどのERPパッケージがわかりやすいですが、SDモジュールとMMモジュールを繋げたテストや、ロジ（SD・MM）モジュールと会計（FI・CO）モジュールを繋げたテストなどがこれに当たります。

１つ具体例を挙げるとすると、サブシステム間、機能間のデータの整合性を確認することが挙げられます。例えば、あるグループ会社の親会社と子会社に同時にシステムを導入するとして、親会社からの子会社への発注データをもとに、子会社側で受注データを作成するといったような場合、システム設計工程でどのようなデータの繋がりをするかを決めています（発注者側の発注番号は、受注者側のどこに保持するかなど）。単体テストやコンポーネントテストでは発注者側の発注データの出来方や、受注者側の受注データの出来方というそれぞれでのテストはできていますが、お互いがつながった時に成立するかという観点でのテストはできていません。後続の結システムテストでも確認することは可能ですが、後続になるとどうしても先ほどのような項目レベルでの確認をすることが難しくなるため、項目レベルでのデータの整合性確認というテストを実施し、品質を高めることは重要となります。したがって、サブシステム間、機能間で高難度なデータ連携（データの引き渡しや授受）が行われる場合には、テスト工程の１つとしてよく計画します。

ここまでで少なくともアプリケーションとしては「動く」ものをしっかりと完成させます。したがって、画面遷移でエラーが起きたり、予期せぬエラーが起きたりなどがないように徹底的なバグ出しを行い、アプリとしての完成度を高めることが重要です。

結合テストの種類

さらに、単に「動く」アプリケーションのテストだけではなく、「使える」アプリケーションにする必要があります。そこで、結合テストでは、いくつかのテストの種類を設け、これらを実施していきます。

代表的なものに、ユースケーステスト、ユーザインタフェーステスト、業務シナリオテスト、リグレッションテスト、負荷テスト（ストレステスト）などがあります。ただし、結合テストの中で実施するテストに関しては様々なものがあるため、明確に”コレ！”というものはありません。

ユースケーステストでは、アクター（対象システムとやり取りをするシステム及びユーザ）と対象システムとの間の関係性が妥当かどうか、アクターが期待した結果を得られるかどうかを検証します。例えば、利用ユーザーがショッピングサイトで買い物をする際、購入品をカートに入れるとカートに購入予定の商品が入るといったように、アクターの行為に対して対象システムが見せる挙動を定義し、その通りに動くかどうかを検証します

ユーザインタフェーステスト（ユーザビリティテスト）は、ユーザインタフェース要件に沿って、ユーザが実際にシステムを利用する際の状況や環境、また想定利用者のITリテラシーに合わせて、業務を実施するに耐え得るユーザインタフェースかどうかを検証します。例えば、タブレット端末での操作に支障がないかや、屋外も視認できるような画面レイアウトや色味になっているか、高齢者といったITリテラシーの高くない人でもスムーズに操作ができるかなどを検証します。

業務シナリオテストでは、業務フローで定義した一連の作業（シナリオ）に沿ってユーザーがシステムを使って問題なく一連の操作ができるかどうか検証します。”シナリオ”というくらいですから、ユーザーが実際にシステムを使用する際に想定される操作や手順に沿ってシステムを動かし、業務上の問題が発生しないかを確認します。

リグレッションテストでは、変更を加えていない既存機能が、今回の改修によって影響がでていないか、使えないようになってしまっていないかどうかを検証します。注意点としては、すべてのケースで問題がないことを確認ことは証明することは、”魔女がいないことを証明すること”のように、不可能です。したがって、実施するとなると膨大な工数がかかります。したがって、よく実施される具体的な方法としては、最低限の業務が実施できるかどうか、基本的な業務シナリオに沿ってシステムを一連の流れで動かしてみることなどが挙げられます。

ここまで内部結合テストや外部結合テスト、そしてその中のいくつかのテストの種類についてみてきましたが、いずれにしてもブラックボックステストに相当します。ITaとITbといった結合テストのことを、IPA情報処理推進機構では「ソフトウェア適格性確認テスト」と呼んでいます。

また、もっとこうしたらよいのでは・・・？という点があり、顧客に逆提案を行い改善を図っていくことはべき論でいえばなしです。既に「検証」フェーズに入ってしまっているため、その場合は、仕様変更として別工数をもらって別途対応していくことが筋です。所謂、変更管理対象として扱います。ただ、ここはシステム屋としてもっと良いものをという思いで悩む部分でもあるため、顧客との信頼関係によって調整することが多いです。このあたりはプロジェクトマネージャーの腕の見せ所だったりします。

重要なことは、これらのテストを実施することで結合テストを通じて、単に”動く”アプリケーションから業務で”使える”アプリケーションにブラシュアップしていくということです。

システム総合テスト(ST)

５つ目はSystem Testのことで、ハードウェアや通信も含めてシステム全体で問題ないか評価します。システム全体での確認となるため、総合テストとも言われます。結合テストから一歩進んでいるため、IPA情報処理推進機構では「システム適格性確認テスト」と呼ばれています。

今回のプロジェクト、システム開発で構築や実装したもの全てが対象です。システム「全体」ですから、対向システムが複数システムがある場合は、システム間の連携設定（バッチやそれに関連するディレクトリ設定、HUFLT設定など）も組んだうえで、本番さながらの環境を用意し、システム間の連携テストもこの工程で実施します。

勿論、システム「全体」ですから開発したアプリケーションだけではなく、インフラ面も含めたシステム全体で評価を行います。したがって、非機能要件関連のパフォーマンス、セキュリティに関するテストなどもここで検証していきます。

特に非機能要件はインフラが関わってくる部分も多く、新システム導入の場合でインフラ環境も設定した場合には、アプリとインフラの統合テストを実施します。例えば、APサーバやDBサーバがデュアル構成の場合は、サーバの片方を停止した状態でも問題なくアプリ側のデータ登録や処理が可能かどうかや、アプリ側で入力したデータのバックアップが正常に取得され、定めた時点に正常に復元できるかどうかを確認します。

既存システムに対する追加開発・保守開発の場合は、リグレッションテスト（他の機能への影響確認）もこのフェーズで行うこともありますが、前段の結合テストの中で実施することも多いです。

また、本番稼働後に運用や保守に移行していけるかについても確認を行います。

アプリケーションだけではなく、インフラや周辺システムとの連携に関してもテスト範囲とする

この段階で、アプリとインフラ及び周辺システムとの連携も含めて顧客にベンダーとしては100点と言えるものを納められるように努めます。

受入テスト（AT）

７つ目はAccept Testのことです。とはいえあまりATという言葉は耳にしません。検収テストと呼ぶこともあります。受入テストとユーザテストの区別は結構曖昧で、実際のところは一緒になっている現場が多いと思います。むしろ一般的には、ユーザ受入テストと呼び、UATと呼ぶ方が標準的な気もしています。どちらにしても、ここからのフェーズが顧客側（発注者側）が主体のテスト工程です。

顧客（発注者側）のシステム部門やPMO、事務局が納品物を点検する工程です。この時、顧客側は、システム要件定義、業務要件定義の内容を基にベンダーが作成したシステムに問題ないかを確認します。

ベンダー目線では上記で発生した課題や不具合を順次調査し、原因分析と対応を繰り返し対応していくこととなります。

ユーザテスト(UAT)

最後はUser Test、User Accept Testのことで、受入テストがシステム部門やPMO、事務局による確認工程だとすれば、ユーザテストは、その名の通り、ユーザ部門による確認工程です。ユーザ部門は、業務分析の内容やRFPに記載されている内容が実現できているかどうか、期待した投資対効果は得られるかどうかという観点で判断します。

しかし、すぐには投資対効果の実績収集はできないため、システムとして問題がない、業務が回れば問題ないという基準で判断する現場も多いです。

受入テストと同じく、ベンダー目線では上記で発生した課題や不具合を調査し、原因分析し、対応していていきます。