この記事の要点
- システム開発のテストは、小さな部品から順に、単体テスト・結合テスト・総合テスト・受け入れテストの段階で進めるのが一般的です
- 単体から総合までは主に開発会社が行い、発注する側はテストの計画と結果の報告で、範囲と残っている問題を確かめます
- 受け入れテストは発注する側が主役で、いつもの業務の流れでシステムを使い、業務に使えるかを確かめます
システム開発のテストは、小さな部品から順に、単体テスト、結合テスト、総合テスト、受け入れテストの段階で進めるのが一般的です。単体から総合までは主に開発会社が行い、最後の受け入れテストは発注する側が中心になって行います。
発注する側がテストの作業を細かく知る必要はありませんが、どの段階で何を確かめるのかを知っておくと、報告を読むときや、受け入れテストを準備するときに役立ちます。はじめての方向けに整理します。
テストの4つの段階
テストは、確かめる範囲を少しずつ広げながら進めます。段階の呼び方は会社によって少しずつ違いますが、考え方は共通しています。
| 段階 | 確かめること | 主に行う人 |
|---|---|---|
| 単体テスト | 部品（1つの処理や画面）が、設計どおりに動くか | 開発会社 |
| 結合テスト | 部品をつないだときに、正しくデータが受け渡されるか | 開発会社 |
| 総合テスト | システム全体が、要件のとおりに動くか。速さや負荷、セキュリティなども含む | 開発会社 |
| 受け入れテスト | 業務に使えるか。いつもの業務の流れで使って困る点がないか | 発注する側 |
単体テスト
単体テストとは、プログラムの小さな部品が、設計どおりに動くかを1つずつ確かめるテストです。開発する人が、作りながら確かめることが多く、プログラムで自動で確かめる仕組みを用意しておくこともあります。
結合テスト
結合テストとは、部品をつないで、データの受け渡しや処理の流れが正しいかを確かめるテストです。ほかのシステムとつなぐ場合は、つなぐ先との受け渡しもここで確かめます。
総合テスト
総合テストとは、システム全体を本番に近い状態で動かし、要件のとおりに動くかを確かめるテストです。システムテストとも呼ばれます。機能だけでなく、画面の表示の速さ、たくさんの人が同時に使ったときの動き、権限の設定、セキュリティなども確かめます。
受け入れテスト
受け入れテストとは、発注する側が、業務に使えるかを確かめるテストです。開発会社のテストが「作ったものが仕様どおりか」を見るのに対して、受け入れテストは「業務で困らないか」を見ます。仕様どおりでも、業務の流れに合わない点が見つかることがあります。
発注する側が見るところ
単体から総合までのテストは開発会社が行いますが、発注する側は、テストの計画と結果の報告で、次の点を確かめておくと安心です。
テストの計画で見るところ
- 何を、どの段階で確かめるか（範囲）
- 業務で大切な処理（お金の計算、締めの処理、権限など）が含まれているか
- 本番に近いデータや環境で確かめる段階があるか
- 発注する側が準備するもの（テスト用のデータ、つなぐ先の環境、立ち会う人）と、その期限
結果の報告で見るところ
- 予定したテストのうち、終わった数と残っている数
- 見つかった不具合の数と、直った数・直っていない数
- 直っていない不具合の影響の大きさと、直す予定
- 予定どおりにできなかったテストと、その理由
数字の多い少ないだけで良し悪しを決めるのではなく、直っていない不具合が業務に与える影響を、開発会社と一緒に確かめることが大切です。
受け入れテストの進め方
受け入れテストは、発注する側が中心になって進めます。準備から結果のまとめまで、次の順で進めると進めやすくなります。
- 観点を決める：業務の流れごとに、確かめる場面を書き出します。いつもの流れだけでなく、締め日、月末、取り消し、例外の処理も入れます
- データを用意する：業務で使うデータに近いテスト用のデータを準備します。個人のデータを使う場合は、扱いのルールを決めておきます
- 担当者を決める：実際にシステムを使う部門の人に入ってもらいます
- 実施して記録する：確かめた場面ごとに、結果と気づいたことを記録します。困った点は、画面の写しと手順を添えて伝えます
- 結果をまとめて判断する：見つかった点を、すぐに直すもの、稼働の後に直すもの、仕様の変更として扱うものに分け、開発会社と話し合います
受け入れテストで見つかった点が、もともとの仕様にないものだった場合は、不具合ではなく仕様の変更として扱うことがあります。扱い方は開発の途中で仕様を変えたいときの進め方で説明しています。
受け入れテストと検収の関係
受け入れテストで業務に使えることを確かめたら、検収に進みます。検収とは、納品されたものが契約の内容に合っているかを確かめて、受け取ることです。契約によっては、検収が支払いや責任の期間の起点になることもあります。
検収の手順と期限は、検収の進め方：受け入れテストから検収書までで説明しています。引き渡した後に契約の内容に合わない点が見つかった場合の扱いは、契約不適合責任とは。期間と請求できることをご覧ください。
テストを早めに考えておく理由
受け入れテストの観点は、開発の最後になってから考えるより、要件を決める段階から考えておくほうが、後の食い違いを減らせます。「何ができたら合格か」を先に決めておくと、作る側も同じ基準で確かめられるためです。
要件と受け入れの観点をあわせて考える進め方は、要件定義で決めること：はじめての方へでも触れています。発注する側の役割の全体は、発注する側のプロジェクト管理。担当者がすることにまとめています。
当社のご支援
当社のWebシステム開発では、区切りごとにできたものをお客様と一緒に確かめ、食い違いを早く見つけるようにしています。開発の進め方について相談したい場合は、お問い合わせからご連絡ください。
- テスト
- 受け入れテスト
- 検収
- 品質
この記事に出てくる用語
このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。