仕事やプライベートで使うパソコンやスマホのアプリケーションやゲームから、自動車や家電に組み込まれているコントローラ、あるいは日頃利用するようなサービスまで、すべてのコンピュータのプログラムはソフトウェアの部品を組み立ててつくります。自動車や家電でも部品を使うことで効率がよくなりますが、プログラムでも同じです。

このそれぞれの部品にバグがないことを確認するテストを単体（ユニット）テストと呼びます。最終的にはバグがないことを確認しますが、単体テストの目的はなるべくバグを出すことです。それがなぜかは後で説明しますね。単体テストではありとあらゆるケースを想定してテストします。それでバグをたくさん出した上で、それを直して問題ないことを確認するのが単体テストの目的です。

部品の単位で確認する単体テストに対し、その部品を組み合わせて動作を確認するのが結合（インテグレーション）テストです。ジョイントテストと呼ぶこともあります。

部品そのものの検査は単体テストで確認したので、もう問題ないはずではないか、と思いますよね。しかし、工業製品でも部品と部品を組み合わせてみたら問題が見つかることがあります。プログラムの部品も同様。組み合わせてみると思っていたのと違う動作をすることや、お互いに想定していた内容に食い違いがあってうまく動かないことも。そのようなバグがないことを確認するのが結合テストです。単体テストではなるべく色々なケースを試してバグを出し尽くすことを目的としていましたが、結合テストではバグがないことを確認するのが目的になります。

プログラムも他の工業製品と同様に部品を組み立ててつくります。具体的にプログラムの部品が何かと言うと、関数やクラスです。プログラミング言語によって呼び方違いますが、より一般的にはモジュールやコンポーネントと呼びます。プログラムの中でよく使う機能やデータの集まりをまとめたものと考えてください。

よく使うものはまとめておけばいちいち書かなくてよいですよね。そして、そのまとめた部品についてバグがないことを確認しておけば、他のところでもその部品を使うことができます。バグのないことを確認した部品を組み立てて、全体のバグがないようにつくるわけです。ただ、個々の部品にバグがなくても組み合わせたらバグがあることもあります。また部品としてはバグではないが、組み合わせた結果としてはバグということも。そのため、部品毎の単体テストとは別に、組み合わせた後に結合テストが必要なのです。

ざっくり説明で単体テストではバグを早めにたくさん出すと説明しました。バグなんて少ない方がよいですよね。しかし、単体テストの時点でその部品のバグがないことを確認しきっておかないといけないのです。

例えば、単体テストが不十分で部品のバグを1件見逃したとします。それが結合テストで見つかったとすると、どこで発生したかの調査が必要です。単体テストで問題がないことを確認しきっていれば組み合わせの時点で発生した問題だと推測できますよね。でも、単体テストが不十分だと部品までさかのぼって調べなければなりません。そして、部品に問題を見つけるとまた単体テストをやり直した上で、結合テストのやり直しです。このようにバグは早いうちに見つけた方が手間が少ないとされています。遅れれば遅れるほどピラミッドのように手間がどんどん増えてしまうのです。

プログラムの規模が大きくなると、結合テストも1回では済まなくなります。これは会社や開発チームの考え方によって違いますが、2回に分けることも多いです。結合（インテグレーション）テストのことを英字2文字でITと省略するため、ITa、ITbと呼ぶこともあります。

この分け方はプログラムの内容や開発チームの考え方しだいです。例えば、規模の大きなプログラムは部品のかたまりを一つの大きな部品と考えることもあります。その大きな部品単位でテストした上で、全体を組み合わせてさらにテストするわけです。また、規模が大きいといくつかの会社に分けて作成してもらうこともあります。その場合、会社ごとのテストと全体を組み合わせたテストに分けるのです。規模が大きくなると問題が出たときにどこが原因なのか分かりにくくなります。だから、テストも小分けするのです。

部品を組み合わせて結合テストをしたらそれで終わりかと言うと、まだテストがあります。それが総合テストです。総合テストでは何を確認するのでしょうか。

仕事で使うものやネットのサービスでは、ユーザがこう使うというシナリオがあります。例えばショッピングサイトならユーザが商品を検索、その商品をカートに入れ、決済を行うといった流れです。このようなあらかじめユーザがする作業の流れをシナリオとして用意しておき、その流れでバグがないかを確認するのが総合テスト（システムテスト）。ただ結合テストとの違いが分かりにくいですよね。結合テストとの違いは、より本物らしいデータと作業をして問題ないか確認することです。テストのためのデータを使うのが結合、本番さながらのデータを使うのが総合と考えてください。

総合テストが終わればテストは終わりでしょうか。実はまだあります。プログラムをつくるのは使う会社とは別ということも。そのような場合、実際に使う会社が確認するのが受入テスト（ユーザーテスト）です。別の会社からの依頼でプログラムをつくった場合、この受入テストに合格しないと代金を払ってもらえません。ですので受入テストが一番大事なテストです。同じ会社内でもプログラムのオーナーとなる部署が確認します。最終的に問題ないかを確認する大事なテストです。

また受入テストとは違いますが、主にゲームなどで正式サービス前にベータテストというものを行うこともあります。これは正式リリースほどではないが実際に多くのユーザに使ってもらって問題がないか、改善点がないかを確認するテストです。受入テストと少し似ていますね。

単体、結合、総合、受入テストというものがあると説明してきましたが、これで終わりでしょうか。大きなくくりとして一般的なのは以上です。しかし、さらに目的に合わせてさまざまなテストが存在します。

大規模で多くのユーザーが使うようなプログラムでは、つくっている時には実際に使う想定人数でのテストはなかなか難しいです。そのためのツールを使ったり、社内の人に協力してもらって実施するものを負荷（ストレス）テストと呼びます。本番と同じような使い方をしてみて問題ないかを確認するのが目的です。他にも長時間稼働しても問題ないかを確認するものや、性能が想定通りか確認するもの、セキュリティの問題がないか確認するものなど、色々なテストをおこなって初めてユーザーが使えるようになります。

色々なテストを紹介しましたが、実際にテストはどうやるのでしょう。これも会社や開発チームによるので教科書的な手順を紹介します。大きな流れとしてはプログラム（部品）を書く→単体テスト→組み合わせる→結合テスト→総合テスト、受入テストです。

それぞれのテストもその場で適当にテストするわけではありません。テストをどうやってするかの計画を立て、現実にどのようなデータやシナリオを使ってテストするかを決めます。そのためにテスト計画書やテスト仕様書というものを用意するのです。その後、テストした結果をテスト報告書としてまとめます。テスト報告書はテストごとに必要です。また、テストの結果でテスト仕様書の変更が必要になることも。テストをするのにも膨大な手間がかかっているわけです。