システム開発のテスト工程を徹底解説!システムテストと受け入れテストの違いは?

システム開発で実施される各種テストは、要求を満たしているか?不具合(バグ)がないか?プログラム・システムをチェックして品質を担保するために必須の工程。しかし、具体的にどのようにテストに関わっていくべきなのか?わからない企業担当者の方は多いはず。

・システム開発ではどんなテストが実施される?
・テストはどのような方法で実施される?
・システムテストと受け入れテストの違いは?
・発注側が参加するテストは?方法は?

本格的に運用をはじめてから不具合が発覚した、といった事態にならないためにも、どのようなテストが実施されるのか?テスト工程にどう関わっていくべきなのか?クライアントとして把握しておきたいものです。

そこで本記事では、システム開発のフェーズごとに実施されるテスト工程を徹底解説!テストの流れ・方法を知ることで、自社がなにをすべきなのかも把握できるようになります

※現在、システム開発会社をお探しの方はシステム幹事にご相談ください。専任のアドバイザーが予算や目的をヒアリングし、最適な会社を厳選します。相談料・紹介料は一切かかりません。

【無料】おすすめのシステム開発会社を紹介してもらう

目次
  1. 1. システム開発で実施されるテストとは
    1. 1-1. システム開発のテストは主に4種類
    2. 1-2. テストが4行程に分かれる理由
  2. 2. 単体テスト
    1. 2-1. 単体テスト設計は詳細設計で作成
    2. 2-2. 単体テストの手法
  3. 3. 結合テスト
    1. 3-1. 結合テスト設計は基本設計で作成
    2. 3-2. 結合テストの手法
  4. 4. システムテスト(総合テスト)
    1. 4-1. システムテスト設計は要件定義で作成
    2. 4-2. システムテストの手法
  5. 5. 受入れテスト(ユーザーテスト)
    1. 5-1. 受け入れテスト設計は要求定義・要件定義で作成
    2. 5-2. 受け入れテストの手法
    3. 5-3. 受け入れテストには開発会社の協力が欠かせない
  6. 6. アジャイル型システム開発のテスト工程
  7. 7. システム開発のテストまとめ
    1. 7-1. システム開発会社をお探しの方へ

システム開発で実施されるテストとは

システム開発のテストは主に4種類

単体テスト

画面や機能ごとに、動作の検証をする

結合テスト

他の機能やシステムと連携させて、動作の検証をする

総合テスト

本運用を想定して、システム全体の動作を検証する

受入れテスト

納品前に仕様書の通り完成しているか確認する

システム開発におけるテストの役割は、開発したプログラム・システムが問題なく動作するか、不具合がないかをチェックして修正すること
人の手が介在するシステム開発では、バグがないということはあり得ません。不具合を解消し、問題なくシステムを活用するためにもテスト工程は必須です。

たとえば、システム開発の現場でもっともポピュラーな開発モデル「ウォーターフォール型」を採用している場合、「単体テスト」「結合テスト」「システムテスト(総合テスト)」「受け入れテスト(ユーザーテスト)」の、大きく4つのテスト工程が実施されます。

V字モデル

テストが4行程に分かれる理由

それでは、なぜテストが4つの工程に分かれているのか?

・設計時にシステムを細かいモジュールに分解し、プログラムごとに開発を進める
・テスト工程ごとに目的・重要性が異なる

以上の2つが大きな理由。具体的な手法とともに、それぞれのテスト工程における目的・重要性を解説していきましょう。

ウォーターフォール型システム開発についてより詳しく知りたい方は、以下の記事も参考にしてください。

関連記事ウォーターフォール型システム開発とは?開発工程・メリット・アジャイル型との違いを解説!

単体テスト

単体テスト

画面や機能ごとに、動作の検証をする

単体テストとは、分割されたモジュール(部品を集めて機能を持たせたもの)・プログラム単体ごとに実施するテストのこと。部品・構成要素(Component)、構成単位(Unit)ごとに実施されるため、コンポーネントテスト、ユニットテストと呼ばれる場合もあります。

選任のテスターが担当する場合もありますが、基本的にはモジュールのプログラミングを担当したシステムエンジニア(SE)・プログラマーが単体テストを実施します。

単体テスト設計は詳細設計で作成

単体テストは、V字モデルに沿った「詳細設計」で策定・作成された「単体テスト仕様書」に従って実施されます。ウォーターフォール型のV字開発モデルで、単体テストと詳細設計がリンクしているのはこのためだといえるでしょう。

単体テストの目的は、詳細設計書通りにモジュール・プログラムが動作するか?不具合がないか?確認すること。

システムの最小単位であるモジュール・プログラムなら、不具合を発見しても修正が容易。不具合を取り除いておけば、その後の問題切り分けもにも有利です。テスト工程全体をスムーズに進めるためにも、最初のステップである単体テストの重要性は高いのです。

関連記事システム開発の詳細設計とは?プロジェクトの位置付け・役割をわかりやすく解説!

単体テストの手法

単体テストでは、インターフェース(操作画面)がない「ドライバ」など、一時的に制作されたプログラムをテストする場合がほとんど。このため、単体テストではプログラム内部に着目した「ホワイトボックステスト」という手法を中心にしたテストが実施されます。

ホワイトボックステスト

ホワイトボックステスト

ホワイトボックステストとは、制作されたプログラムが設計通りの処理を実行できるか?網羅的に検証するテストのこと。あくまでもプログラムの内部構造や処理を検証するテストであり、設計時の仕様が正しいかどうかを検証するものではありません。

このことから、ホワイトボックステストはプログラムを「開発側の視点」に立って検証するテストだといえるでしょう。

具体的には、プログラムの「条件」「条件の分岐」「分岐後の命令」などを確認する制御フローテスト、プログラム内で定義した変数・固定値が適切に使用されているか確認する、データフローテストなどが挙げられます。

結合テスト

結合テスト

他の機能やシステムと連携させて、動作の検証をする

結合テストとは、テストの完了したモジュールをサブシステムとして結合し、意図した通りに動作するかを検証するテストのこと。多くの場合で選任のテスターが担当しますが、プログラミングを担当したSE・プログラマーがテストする場合もあります。

結合テスト設計は基本設計で作成

システム基本設計の流れ

結合テストは、基本設計時に策定・作成された「結合テスト仕様書」に従って実施されます。ウォーターフォール型のV字開発モデルで、結合テストと基本設計がリンクしているのはこのため。

結合テストの目的は、基本設計書通りにサブシステムが動作するか?不具合がないか?確認することです。

モジュール単体では問題なくても、組み合わせた場合に起こり得る、想定外のエラーを排除するためにも、結合テストは重要性の高い工程だといえるでしょう。システム内部のサブシステムを検証する「内部結合テスト」以外に、外部システムとの連携を検証する「外部結合テスト」が実施される場合もあります。

基本設計についてより詳しく知りたい方は、以下の記事も参考にしてください。

関連記事システム開発の基本設計とは?重要性・発注者としての関わり方を解説!

結合テストの手法

結合テストでは、サブシステムへの入力に対する正しい出力データが得られているか?正常なデータが引き渡されているか?結合したモジュール・プログラム間の連携を検証します。

テスト手法としては単体テストでも紹介した「ホワイトボックステスト」に加え、「ブラックボックステスト」「トップダウン・ボトムアップテスト」が代表的です。

ブラックボックステスト

ブラックボックステスト

ブラックボックステストとは、結合されたサブシステムにデータを入力し、正しい出力データが返ってくるかを検証するテストのこと。ホワイトボックステストとは逆に、プログラムの内部構造は検証せず、サブシステムが仕様書通りに動作するかを検証するものです。

このことから、ブラックボックステストはプログラムを「発注側・利用側の視点」に立って検証するテストだといえるでしょう。

ブラックボックステストは、プログラムの内部に着目した単体テストでは見逃してしまう、仕様の不備や設計ミスなどを探しだし、修正していくために欠かせないテスト工程です。

トップダウン・ボトムアップテスト

トップダウン・ボトムアップテスト

結合テストを実施する方法としては、サブシステムの上位モジュールから順番に検証していく「トップダウンテスト」、逆に、サブシステムの下位モジュールから順番に検証してく「ボトムアップテスト」の2つがあります。

優先度の高い機能からテストできるボトムアップ、仕様書との違い・機能のモレを発見しやすいトップダウンという特性があり、状況に応じて使い分けられています。

トップダウンテストでは機能漏れ、仕様の認識違いは検証できますが、開発とテストの同時進行が難しいことが欠点。一方のボトムアップテストは開発とテストを同時並行できるものの、やり直しが発生する可能性があります。そのため、トップダウンテストとボトムアップテストを併用することがあるのです。

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

システムテストとは、すべてのサブシステム・プログラムを結合し、システム全体として要件通りに動作するかを検証するテストのこと。ユーザーが使う本番環境、もしくはそれを想定した環境にシステムを置き、実稼働と同様の負荷をかけて機能・パフォーマンスに問題がないかを確認します。

一般的に、システムテストは選任のテスターが担当するケースがほとんどであり、開発に携わったSEやプログラマーが参加することはあまりありません

システムテスト設計は要件定義で作成

システム開発における要件定義とは

システムテストは、要件定義時に策定・作成された「システムテスト仕様書」に従って実施されます。ウォーターフォール型のV字開発モデルで、システムテストと要件定義がリンクしているのはこのため。

つまりシステムテストの目的は、要件定義で策定・作成した「システムテスト仕様書」通りにシステムが動作するか?不具合がないか?機能要件や非機能要件(機能以外に求められる条件)を満たしているか?確認することです。

システムテストは開発会社側が実施する最後のテストでもあり、品質の担保された要求通りのシステムを引き渡すための非常に重要性の高い工程。パフォーマンスも含めた総合的な観点からシステム検証することから、総合テストとも呼ばれています。

要件定義についてより詳しく知りたい方は、以下の記事も参考にしてください。

関連記事システム開発の要件定義とは?受託開発における重要性や進め方を解説!

システムテストの手法

システムテストでは、実稼働時と同様の負荷をかけても機能要件・非機能要件を満たせるか?開発したシステムを総合的に検証します。サブシステムごとの機能検証は結合テストまででほぼ完了しているため、それを補完しつつ総合的に検証する「確認テスト」「評価テスト」「負荷テスト」などが実施されます。

確認テスト

各モジュール・サブシステムのテスト・修正を経て変更されたプログラムや、プログラム同士の連携に不具合がないか?正しい挙動を示しているか?検証するために実施されるのが「確認テスト」

これは、システムが複雑化するほど、1つの修正がほかに影響を与える可能性が高くなるため。確認テストで実施される主要な手法は以下の2つです。

リグレッションテスト

プログラムの修正・変更がほかのプログラムへの

不具合を招いていないかを検証するテスト

デグレードチェックテスト

修正・変更したプログラムの不具合再発・機能不全が

発生していないか検証するテスト

評価テスト

評価テストとは、使い勝手、セキュリティ、障害時の耐性など、システムの性能を評価して検証するテストのこと。評価テストで実施される主要な手法は以下の3つです。

セキュリティテスト

不正アクセスや情報漏えいなど、セキュリティに関連する

要件を満たしているか検証するテスト

ユーザビリティテスト

ユーザー側の視点に立って視認性や使いやすさを検証する

障害許容性テスト

障害発生時に必要最低限の機能を維持して稼働できるか検証

負荷テスト

負荷テストとは、システムに大きな負荷をかけて稼働させ、耐久性やパフォーマンスに問題が生じないかを確認・検証するテストのこと。負荷テストで実施される主要な手法は以下の5つです。

性能テスト

仕様を満たす処理能力を発揮できるか?

システムに負荷をかけて検証するテスト

ロングランテスト

長時間の稼働に耐えられるか?

システムの稼働率・パフォーマンスを検証

ストレステスト

想定以上の負荷をかけるとどうなるか?

システムのストレス耐性を検証

ロードテスト

通常時・高負荷時を想定してシステムを稼働させ

耐久性・パフォーマンスを検証するテスト

キャパシティテスト

データ量や同時アクセス数の増大にシステムが

どのような挙動を示すか?確認・検証

受入れテスト(ユーザーテスト)

受け入れテストとは、完成したシステムが要件を満たす機能・性能を保持しているか?発注側が総合的に検証するテストのこと。総合的にテストするという意味ではシステムテストと同様ですが、ユーザーである発注側がテストを担当するため、ユーザーテストと呼ばれる場合もあります。

受け入れテスト設計は要求定義・要件定義で作成

受け入れテストは、要件定義時に策定・作成された「受け入れテスト仕様書」に従って実施されます。ウォーターフォール型のV字開発モデルで、受け入れテストと要件定義がリンクしているのはこのため。

本来、受け入れテストは「要求定義」とリンクされるべきではありますが、要求定義をもとにシステム要件(システム化するもの、しないものを決める)を定義したものが要件定義書・仕様書であるからです。

関連記事システム開発における要求定義の重要性|要件定義との違いや要求定義の実態・改善ポイントを解説!

受け入れテストの手法

受け入れテストは、目的・ゴールを達成できるシステムが納品されたのか?後々のトラブルを避けて確実に検収するためにも非常に重要性の高いテスト工程です。本来であれば、システムテストと同様、総合的なテストを念入りに実施することがベター。

ただし、システムテストで完了しているテスト項目もあるため、受け入れテストでは機能・ユーザビリティテストを中心に検証するケースが一般的。運用テストとして負荷テストを実施する場合もありますが、システムテストほど念入りに実施されないこともあります。

機能テスト(正常系・異常系)

機能テストとは、要件定義書・仕様書通りの機能要件を満たしているか?実稼働時の状況を想定しながらシステム全体の動作を検証するテストです。

具体的には、通常稼働時を想定したデータ入力・使い方をした場合に、正しい値が返されるか?動作に問題がないか?検証する正常系機能テスト。イレギュラーなデータが入力された、間違った使い方をした場合に、システムがどのような挙動を示すのか?検証する異常系機能テストが実施されるケースがほとんど。

正常系・異常系ともに、さまざまな条件を想定したテストデータを用意したうえで実施されます。

ユーザビリティテスト

ユーザビリティテストとは、実際の業務、あるいはそれを想定したシナリオを用意してシステムを稼働させ、ユーザーの使用感・操作感などをチェック・検証するテストのこと。

たとえば、ボタンの位置や大きさなどのインターフェース関連のほか、入力不備があった際のエラーメッセージの内容がわかりやすいか?ユーザー自身で問題解決できる操作感が得られるか?などが検証されます。

疎通テスト

疎通テストとは、外部システムなどと問題なく疎通(リクエストに対するレスポンス)できるか?検証するテストのこと。外部システムとの連携が要件として定義されているならば、すでに結合テストで実施済であるため、最終確認の意味合いで実施されるケースが多いようです。

セキュリティテスト

システムテストでも実施されるセキュリティテストは、本番環境に置かれた受け入れテストでも再度実施されます。外部攻撃を想定した不正な値、攻撃コードを用意し、システムがキチンと回避できるかどうかを検証することが一般的です。

負荷テスト

システムテストで実施される負荷テストは、運用テストとして受け入れテスト時に追加で実施される場合もあります。

システムテストに準拠した内容で行われる場合もありますが、性能テスト、キャパシティテストなどに限定するケースも。受け入れテストにおける負荷テストは、比較的プライオリティを低めに設定する場合が多いといえるでしょう。

受け入れテストには開発会社の協力が欠かせない

納品されたシステムが、仕様書通りの機能要件・非機能要件を満たしているか?確認するうえでも重要な受け入れテストですが、すべての発注側企業がテスト体制を整えられているわけではないでしょう。あらかじめデータを用意する必要もあるため、どのように対処していいのか困惑してしまう方も多いかもしれません。

そのためにも、パートナーとなるシステム開発会社との協力関係構築が重要。「受け入れテスト仕様書」策定・作成を依頼する以外にも、テストデータ作成、単体〜システムテストまでのテスト結果共有、テストツールの活用など、あらゆる面で協議を重ねておく必要があります。もっとも上流の工程となる、要件定義フェーズが非常に重要なポイントとなります。

アジャイル型システム開発のテスト工程

アジャイル開発

ここまでで、大きく4つに分類できるシステム開発のテスト工程を解説してきました。ただし、これはあくまでも「ウォーターフォール型システム開発」における一般的な例。システム開発の手法によっては、本記事の解説が当てはまらない場合もあります。

たとえば、システムをおおまかな機能に分割し、設計・開発・テスト・リリースを繰り返して(イテレーション)完成系を目指すアジャイル型の場合はどうでしょう?

イテレーションのサイクルに「テスト」が含まれていることからもわかるように、アジャイル型にもテスト工程は存在します。ただし、小さな機能ごとに短期間でのリリースを繰り返すため、ウォーターフォール型のように綿密なテストは実施されません。テストに時間をかけていては、アジャイル型の特徴(俊敏な開発)を活かせないからです。

そのため、アジャイル型におけるテスト工程は「ツールを活用した自動化」が目指されており、発注側はテストとリリース後のレビューを通じて、開発側にフィードバックを伝える役割を担う場合が一般的です。

関連記事アジャイル開発とは?メリット・デメリット、発注側の注意点を解説

システム開発のテストまとめ

本記事ではウォーターフォール型を中心に、システム開発のフェーズごとに実施されるテスト工程を目的・重要性を含めて解説してきました。

・単体テストの目的は、モジュール・プログラムが動作するか?不具合がないか?確認する
・結合テストの目的はサブシステムが動作するか?不具合がないか?確認する
・システムテストの目的は、「システムテスト仕様書」通りにシステムが動作するか?不具合がないか?機能要件や非機能要件を満たしているか?確認すること
・受け入れテストは、目的・ゴールを達成できるシステムが納品されたのか?後々のトラブルを避けて確実に検収するためのテスト

実際に発注側として作業に携わるのは受け入れテストだけですが、全体的なテスト工程を知っておくことで、テスト工程をスムーズに進められるでしょう

関連記事システム開発の検収トラブルを防ぐには?検収方法・契約内容・疑問を解説!

システム開発会社をお探しの方へ

現在、システム開発の外注をお考えの方はシステム幹事にご相談ください。

システム開発は会社によって得意・不得意が分かれることが多く、少ない情報から見極めるのは大変です。依頼をしようにも料金が書かれていないことが多く、どこの会社に問い合わせればいいのか迷っている方も多いでしょう。

少なくない時間と予算がかかるので、会社選びの失敗は絶対に避けたいところです。専門のコンサルタントがあなたの要望を丁寧にヒアリングし、予算にあった最適な開発会社を選びます。

コンサルタントのご紹介 システム幹事 コンサルタント 岩田真 岩田 専任のコンサルタントが、
お客様の予算と目的を丁寧にヒアリング。
最適な会社をピックアップ・ご紹介させていただきます!
初心者の方でも安心してご相談いただけます。

業界の相場や開発会社の選び方などWebサイトには載っていない情報をご提供します。

必ず開発会社に発注する必要はありません。システム開発の相場の情報から最適な会社選びまで無料でサポートします。お気軽にご相談ください。

【無料】おすすめのシステム開発会社を紹介してもらう