システム開発のテスト工程｜種類と流れを解説

01はじめに｜この記事でわかること

要点：この記事は、システム開発を発注する側の方に向けたテスト工程の読み方です。4つのテストがそれぞれ何を確かめる工程なのか、どこを開発会社に任せ、どこで自社が動くのかを、期間と社内工数の目安とあわせて整理します。

「来月からテスト工程に入ります。2か月ほどみてください」。開発会社からそう言われて、スケジュール表に「テスト」という長い帯だけが引かれている。その2か月に自分たちが何をするのか、聞きそびれたまま進んでしまう。よくあるご相談です。

ここでつまずくと、あとが苦しくなります。最後の受入テストは、発注した側が自分の業務で試して合否を判断する工程です。ここに人と時間を割けないまま日程が過ぎると、確かめきれないまま本番に進み、動き出してから業務が止まります。この記事では、2000年創業のWeb制作・システム開発会社ZenWeb Japanが、Webシステム開発のご相談で実際にお伝えしている見方をご紹介します。

まずはテスト工程の全体像をつかめる解説動画をご紹介します。

02テスト工程とは｜4つの段階に分かれる理由

要点：テスト工程は、単体テスト・結合テスト・総合テスト・受入テストの4段階に分かれます。小さな部品から順に、確かめる範囲を広げていく形です。段階を分けるのは、不具合が出たときに原因の場所をすぐ絞り込めるようにするためです。

料理にたとえると分かりやすくなります。まず材料をひとつずつ味見して、次に合わせたソースを味見して、最後に一皿として通しで確かめる。最後にお客様が召し上がって「これでいい」と言う。テストの4段階もこれと同じ順番です。

• 単体テスト。プログラムを1本ずつ動かして、想定どおりの結果が返るかを確かめます。
• 結合テスト。画面と処理、システムと外部サービスなど、つないだ状態で確かめます。
• 総合テスト。本番に近い環境で、業務の流れを最初から最後まで通します。
• 受入テスト。発注した側が自分の業務で試し、納品してよいかを判断します。

まとめて一度に確かめないのは、そのほうが結局は早く終わるからです。全部つないでから「どこかが変」となると、原因を探すだけで数日が消えます。順番に範囲を広げれば、直前の作業が原因だと分かります。工程の並び全体を先に押さえたい方は、基本設計と詳細設計の違いもあわせてご覧ください。

03テストは設計と対になっている｜V字モデル

要点：4つのテストは、それぞれ前半の工程と一対一で対応しています。受入テストは要件定義、総合テストは基本設計、結合テストは詳細設計、単体テストは実装を確かめる工程です。この対応関係をV字モデルと呼びます。

この対応を知っていると、テストの合否を何で判断するのかがはっきりします。テストは「なんとなく動くか」を見る作業ではなく、前半で決めた文書と照らし合わせる作業だからです。

• 受入テストが見るのは要件定義書です。やりたかった業務ができるか。判断するのは発注した側です。
• 総合テストが見るのは基本設計書です。画面の並びや帳票、処理の流れが決めたとおりか。
• 結合テストが見るのは詳細設計書です。機能どうしの受け渡しが決めたとおりか。
• 単体テストが見るのはプログラムです。1本ずつが想定どおりに動くか。

逆にいうと、前半の文書があいまいなままだと、後半のテストで合否を決められません。「これは仕様なのか不具合なのか」という押し問答が起きるのは、たいてい要件定義の書き方が原因です。工程の入口については要件定義の進め方で詳しくご紹介しています。

04テスト工程の内訳｜工数と発注者の関与

要点：テスト全体を100とすると、単体テストがおよそ35%、結合テストが25%、総合テストが25%、受入テストが15%です。発注した側の出番は最後の15%に集中します。逆にいえば、そこだけは代わりがいません。

ここで注目していただきたいのは、割合の小ささではなく代わりのきかなさです。単体から総合までは、人を増やせば早く終わります。受入テストだけは、その業務を毎日している人しか判断できません。人数でも残業でも埋められない工程です。

05単体テスト｜プログラムを1本ずつ確かめる

要点：単体テストは、プログラムを1本ずつ動かして、入力に対して正しい結果が返るかを確かめる工程です。作った人がそのまま担当することが多く、発注した側が立ち会うことはありません。確認するのは結果の記録だけで十分です。

たとえば消費税の計算なら、税率や端数の丸め方、金額がゼロやマイナスのときと、条件を変えて何度も動かします。地味ですが、ここを飛ばすと後ろの工程で不具合が山のように出ます。

発注する側が気にすべき点はひとつだけです。単体テストをどこまで自動で回しているか、記録は残るのか。オフショア開発の品質管理でもご紹介したとおり、体制が離れているほどこの記録が効いてきます。

06結合テスト｜つなぎ目で不具合が出やすい

要点：結合テストは、機能どうしをつないだ状態で確かめる工程です。画面から入れた値が正しく保存されるか、別のシステムに正しく渡るかを見ます。単体では問題がなくても、つなぐと合わないという不具合がいちばん多く出る工程です。

よくあるのは、受け渡しの決めごとが少しずつずれている場合です。片方が日付を「2026/08/13」で渡し、受け取る側は「20260813」を待っている。片方は税抜き、もう片方は税込み。単体では両方とも正しく動いています。

ここで発注した側に出番が生まれることがあります。会計ソフトや基幹システムなど、社外のサービスとつなぐ場合です。テスト用の接続情報を用意したり、相手先の担当者と日程を合わせたりするのは、発注側でないと動けません。API連携の仕組みを押さえておくと、この調整がぐっと楽になります。

07総合テスト｜本番に近い条件で通す

要点：総合テストは、本番と同じ構成の環境で、業務の流れを最初から最後まで通す工程です。機能が動くかだけでなく、混み合う時間帯の速さ、障害からの復旧、権限の分け方など、使い続けられるかを確かめます。

ここで確かめるのは、日常ではなく山場です。月末の締め、期末の棚卸し、キャンペーン初日のアクセス。ふだんの10倍の量を流したときに耐えられるかどうかを見ます。

• 性能を見ます。想定の人数が同時に使ったとき、画面が待たされずに開くか。
• 障害からの復旧を見ます。途中で止まったとき、データが壊れずに戻せるか。
• 権限を見ます。アルバイトの画面に、見せてはいけない情報が出ていないか。
• 移行を見ます。今のシステムから移したデータが、欠けずに入っているか。

クラウドで動かす場合は、この工程で本番と同じ構成を組んで試せるかが分かれ目になります。業務システムのクラウド化では、テスト用の環境を短期間だけ用意できる点も利点のひとつです。

08不具合が見つかる時期と手直しの重さ

要点：不具合の数は単体テストでいちばん多く見つかりますが、直す重さは後の工程になるほど増えます。単体テストでの手直しを1とすると、受入テストでは8倍、本番稼働後は20倍ほどの作業量になります。

後になるほど重くなる理由は、直す範囲が広がるからです。稼働後の手直しでは、プログラムを直すだけでなく、すでに溜まったデータの手当てと、業務を止めない切り替えの段取りまで必要になります。なお、国内の開発データについては、独立行政法人情報処理推進機構（IPA）が5,546プロジェクト分を集計したソフトウェア開発分析データ集2022を公開しています

09受入テスト｜発注者が主役になる工程

要点：受入テストは、発注した側が自分の業務でシステムを試し、納品を受けてよいかを判断する工程です。UATとも呼びます。ここで合格を出すと検収となり、そのあとの手直しは原則として有償になります。

ここが4つのテストの中でいちばん性格が違います。ほかの3つは「設計どおりに動くか」を見ますが、受入テストで見るのは「自分たちの仕事が回るか」です。設計どおりでも、実際の業務では使えないと分かることがあります。

たとえば在庫の登録画面で、1件ずつ入力する作りになっていた。設計書のとおりです。けれども現場は毎朝50件をまとめて入れています。この食い違いは、実際に触ってみないと見えません。在庫管理システムの開発のように毎日使う業務ほど、この差が大きく出ます。

10受入テストの進め方｜5つの手順

要点：受入テストは、合格ラインを決める、実際の業務データを用意する、業務の流れどおりに試す、指摘を1か所に集める、再テストして検収を判断する、という5つの手順で進めます。行き当たりばったりで触るのがいちばん危険です。

手順そのものは難しくありません。多くの現場でつまずくのは、始める前の準備を飛ばして、いきなり画面を触りはじめるところです。

1. 合格ラインを決めます。どの業務が通れば合格かを、テストを始める前に文書にします。ここが決まっていないと、指摘が出続けて終わりが見えなくなります。
2. 実際の業務データを用意します。先月の実データを写して使うのが確実です。きれいな見本データだけで試すと、桁の多い金額や長い取引先名で崩れる問題を見逃します。
3. 業務の流れどおりに試します。機能を1つずつ押すのではなく、受注から出荷、請求までを通しで動かします。つなぎ目の抜けはここで見つかります。
4. 指摘を1か所に集めます。メールや口頭ではなく、一覧表にまとめ、不具合か仕様変更かの区別と、直す優先度を付けます。
5. 再テストして検収を判断します。直った箇所をもう一度試し、周りに影響が出ていないかも確かめてから、合格を出します。

特に大事なのは4番目です。指摘がばらばらに届くと、開発会社側で漏れが起きます。担当者を1人決めて、そこに集めてから渡すだけで、やり取りの往復が減ります。

11規模別の受入テスト期間と社内の工数

要点：受入テストの期間は、300万円未満の案件で2週間、300〜1,000万円で4週間が目安です。あわせて発注側にも、中規模で延べ12人日ほどの時間が必要になります。この社内工数を見込まずに始めると、日程が押します。

延べ12人日は、4名が3日ずつ手を止める計算です。繁忙期と重なると、まず動けません。日程を決めるときは、月末の締めや棚卸しの時期を外せるかを先に確かめてください。

12テスト仕様書と記録｜納品物として求めるもの

要点：テストの成果物として求めたいのは、テスト仕様書、実施した結果の記録、不具合の一覧の3点です。契約書の納品物一覧に入っているかを、発注する前に確認してください。あとから請求しても出てこないことがあります。

この3点がそろっていると、次の改修のときに助かります。どこまで確かめた作りなのかが分かるからです。ないと、改修のたびに「触っていいのか分からない」という調査から始まります。

• テスト仕様書。どんな条件で何を確かめたかの一覧です。抜けている観点も、これを見れば分かります。
• 実施結果の記録。いつ、誰が実施し、合格したかの記録です。画面の写しが添えられることもあります。
• 不具合の一覧。見つかった不具合と、直したか見送ったかの判断が残ります。

受入テストで画面を見るときは、設計段階の図と見くらべるのが早道です。ワイヤーフレームで決めた項目の並びが、そのまま実物になっているかを確かめてください。検収の条件や納品物の決め方については、IPAが公開している情報システム・モデル取引・契約書（第二版）が参考になります。

13受入テストで指摘が出る時期の推移

要点：受入テストの指摘は、開始から2週目にいちばん多く出ます。1週目は操作に慣れる期間で、件数は伸びません。2週間しか取らない日程は、山場の手前で終わってしまう危険があります。

重大な指摘が2週目に集まるのは、業務を通しで動かし始めるからです。1週目は「文字が小さい」といった見た目の指摘が中心になります。この山を越えるまで日程を取れるかが、稼働後の落ち着きを左右します。

14テスト期間を削ると何が起きるか

要点：日程が押したとき、いちばん削られやすいのがテスト期間です。ただし削った分は消えるのではなく、稼働後の問い合わせと手直しに姿を変えて戻ってきます。しかも、そのときは業務を止めながらの対応になります。

開発が遅れても、公開日や稼働開始日は動かせないことが多いものです。そうすると、後ろにあるテストが縮みます。気持ちは分かりますが、ここは踏みとどまってください。

• 問い合わせが増えます。確かめきれなかった箇所が、稼働直後に現場からの連絡として集中します。
• メンテナンスの費用が増えます。本来なら開発費に含まれていた手直しが、月々のメンテナンスの中で追加費用になります。
• 現場の信頼が落ちます。使いはじめて数日で止まると、新しいシステムそのものが敬遠されます。

どうしても縮めるなら、範囲を減らすほうが安全です。全機能を薄く試すのではなく、止まったら業務が止まる機能だけを厚く試す。稼働後の費用がどう変わるかは、システム保守・運用費用の相場で整理しています。開発費全体の考え方はシステム開発の費用相場もあわせてご覧ください。

15まとめ｜発注側が押さえる3点

要点：押さえる点は3つです。受入テストの期間を3週間以上とること、社内の工数を先に確保すること、テストの記録を納品物に入れておくこと。この3つが決まっていれば、テスト工程で大きく困ることはありません。

テスト工程は、開発の最後にあるおまけの期間ではありません。ここまでに作ったものを、自分たちの仕事で受け取れるかを確かめる場所です。

• 期間を決めます。受入テストは3週間以上。重大な指摘が出る2週目を必ず含めてください。
• 人を決めます。その業務を毎日している方に、まとまった時間を空けてもらってください。
• 記録を残します。テスト仕様書と結果の記録を、契約の納品物一覧に入れてください。

この3つは、どれも発注する側にしか決められないことです。Webシステム開発のご相談では、最初の打ち合わせでこの3点を一緒に決めています。会社の考え方はZenWeb Japanのトップページでもご紹介しています。

16よくある質問

1. 総合テストとシステムテストは違うものですか？

同じ工程を指す言い方です。本番に近い環境で、業務の流れを最初から最後まで通して確かめる工程を、会社によって総合テストと呼んだりシステムテストと呼んだりします。中身は変わりません。見積書や工程表で言葉が混ざっていても、心配はいりません。

2. 受入テストは自社だけで進めるのですか？

試すのは自社ですが、進め方は開発会社が支えるのが一般的です。何をどの順で確かめるかの一覧を作ってもらい、それに沿って自社の担当者が実際の業務で動かします。操作に不慣れな段階では、開発会社の担当者に同席してもらうと進みが早くなります。契約前に、この支援が含まれるかを確認しておいてください。

3. 受入テストで見つかった不具合の修正は無料ですか？

設計書と違う動きであれば、原則として無償で直します。一方、設計どおりだけれど使いにくいという指摘は仕様変更にあたり、追加費用の相談になります。この線引きでもめないために、受入テストを始める前に、どちらに当たるかを誰が判断するのかを決めておいてください。

4. テスト期間はどれくらい見ておけばよいですか？

ZenWebの集計では、300万円未満の案件で受入テストに2週間、300〜1,000万円で4週間が中央値です。ただし重大な指摘は開始2週目に集中するため、可能であれば3週間以上を確保することをおすすめします。単体から総合までは開発会社側の工程なので、見積時の工程表で確認してください。

5. テストを外部の会社に依頼できますか？

単体から総合テストまでは、第三者の検証会社に依頼する方法があります。大規模な案件や、品質を厳しく問われるシステムで選ばれます。ただし受入テストだけは代われません。その業務を毎日している方でないと、使えるかどうかを判断できないからです。外部に依頼する場合も、最後の合否は自社で出すことになります。