## 単体テスト仕様書の作り方とは？

システム開発において、システムエラーを未然に防ぐために重要な工程を担う単体テストですが、この単体テストを行う上では仕様書の作成が必須です。では、この単体テスト仕様書はどのように作成するのでしょうか？

### ポイントや注意点を抑えて作成ツールを活用しよう

単体テストにおける仕様書の作り方として重要なのは、ポイントや注意点を抑えることです。

機能の洗い出しやレビューの実施などを行い、正しくテストが実施できていない場合はテスト観点が不足していないか、テスト観点がわかりづらくなっていないかなどに注意しましょう。

また、テスト工程は効率が重視される傾向があるため、仕様書をテンプレート化したり、Excelでの作業の場合は作成ツールを活用したりして業務効率化を図ります。単体テストは比較的新人の方に任されることが多いため、テスト工程を通じてシステム開発について知識を深められます。

**知識をより深めることは、今後のキャリアアップにおいても重要なステップです。**

<center>[エンジニア転職を成功させるため ぜひ*『マイナビIT エージェント』*をご活用ください！](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv12_2)</center>

システム開発において必ず必要となる単体テストは、新人にとってスキルを磨く絶好の機会となります。当記事ではまず最初に、単体テストが含まれるシステム開発工程に関しての情報や、単体テストの概要、結合テストとの違いについて紹介します。

システム開発工程にはいくつかの種類があります。1番有名で多くの企業で採用されているのが「ウォーターフォールモデル」です。そのほかに「アジャイル開発」「スパイラルモデル」「プロトタイプモデル」といった開発手法も存在します。

ここでは、一般的なウォーターフォールモデルを例に流れを説明します。ウォーターフォールモデルは、下記のように、上流工程から下流工程に流れていくように実施されます。

**「要件定義→外部設計→内部設計→プログラミング→単体テスト→結合テスト→システムテスト→運用テスト→システム移行」**

さらに、開発対象が「インフラ」か「アプリ」であるかによって、多少工程は変わります。今回は「アプリのシステム開発」を基準にした単体テストについて紹介しましょう。

システム開発の工程とは？基本的な流れや略語の意味を解説！

システムテストとは？その手法やシステムテストの仕事に転職するには

運用テストと受入テストの違いとは？
相違点を理解してシステムの品質を高めよう！

**単体テストでは、プログラミングの対象単位であるモジュールごとに1つずつテストを行っていきます。**また、単体テストは、「UT工程」や「Unit Test」とも言い、メソッドなどの1つ1つの小さな単位ごとに行うテストのことを指します。1つの動作が正常にできているかをテストすることが目的です。

### 単体テストと結合テストの違い

「単体テスト」と「結合テスト」の違いについてわからなくなる人もいるでしょう。単体テストについては上述の通りです。結合テストとは、単体テストで正常を確認できたモジュールを複数組み合わせ、正常に稼働できているかの検証を実施します。

**結合テストは、「CT工程」や「Combined Test」とも言い、複数のモジュールを組み合わせて行うテストです。**単体テストで正常が確認できたモジュールも複数結合させた場合に正常に動作するのか、想定外の状況でも要件定義した通りシステム要件が満たされているか、を検証するのが目的となっています。

システム開発の工程の「単体テスト」と「結合テスト」の違いを徹底解説！

### 単体テストは新人に任されやすい業務

**単体テストは新卒入社した社員が任されやすい業務です。**理由としては、プロジェクトの理解、仕様書の読みこみ、プログラムの解析などができないと単体テストは実施できないので、システム開発に関する知識を深めるいい機会になるためです。

また、他の工程である設計や、結合テストよりも必要なスキルが少なくて済み、大きな問題が発生するリスクが低いことも理由として挙げられます。

<center>[開発案件の多い求人情報もアリ！？ 『マイナビIT AGENT』で転職相談を受けてみる](https://mynavi-agent.jp/it/lp/029.html?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv12_2)</center>

## 単体テストを担当するエンジニア職とは

前述の通り、単体テストは比較的新人のエンジニアが任されやすい業務ですが、実はテスト業務を専門とするIT職が存在します。今回は、その業務を担うテストエンジニアについて、概要や気になる年収について情報をまとめました。

**テストエンジニアが任される業務内容は、「単体テスト」から「システム移行」までのテスト工程を担当することが多いです。**近年ではテスト自動化ツールを活用することで、作業負担を減らす手法が増えており、今後はテスト関連の知識のみならず、そういったツールについても知見を求められるでしょう。

テストエンジニアは、仕事を通じてバグの修正やトラブル対処方法を身に付けられるため、システム開発のために必要な知識やスキルを得るにはおすすめの職種です。

テストエンジニアとは？テスターとの違い・向いている人・将来性を解説

テストエンジニアの年収についてですが、ここでは類似職種である「品質管理／QA／QC」の年収例を参考として紹介します。

「マイナビエージェント 職種図鑑」での「品質管理／QA／QC」の平均年収は526万円（※2023年8月執筆時点）、経済産業省2017年発表の「IT関連産業の給与等に関する実態調査結果」から近い職種の（顧客サポート/ヘルプデスク）を参考にすると、平均年収390万円と分かりました。

国税庁2020年発表の「民間給与実態統計調査」における民間企業平均年収は433万円なので、品質管理／QA／QCは調査媒体によって年収にバラつきがあることが分かります。

**テストエンジニアとして今後年収をアップさせるには、スキルアップやキャリアを積んでシステムエンジニアなどにキャリアアップする方法がおすすめです。**また、資格取得にチャレンジしてみると、昇進や転職の際に有利に働くでしょう。

【参考】：[マイナビエージェント 職種図鑑](https://mynavi-agent.jp/it/jobindex/14.html?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv12_2)
※【平均年収 調査対象者】2020年1月～2020年12月末までの間にマイナビエージェントサービスにご登録頂いた方
【参考】：[IT関連産業における給与水準の実態① ~ 職種別（P7）](https://warp.da.ndl.go.jp/info:ndljp/pid/11623215/www.meti.go.jp/press/2017/08/20170821001/20170821001-1.pdf)
【参考】：[民間給与実態統計調査-国税庁](https://www.nta.go.jp/publication/statistics/kokuzeicho/minkan2020/pdf/002.pdf?_fsi=AZhJ8QDV&_fsi=AZhJ8QDV)

## 単体テスト仕様書を作成する際に大切なポイント3つ

**単体テスト仕様書は、単体テストを実施する際に使用するドキュメントです。**そのため、開発するシステムの品質を上げるためにも、作成担当者には責任が伴う重要な役割を担っています。

システム開発では単体テスト仕様書のほかに、プロジェクト計画書や要件定義書、結合テスト仕様書などさまざまなドキュメントが存在します。単体テストの成否は、単体テスト仕様書の出来にかかっているといっても過言ではありません。

ここからは、品質の高い単体テスト仕様書を作るポイントを3つ紹介します。

要件定義書とは？仕様書との違いや書き方のポイントを解説

単体テストの仕様書では、テストの際に必要な全ての機能を徹底的に洗い出しましょう。要件定義書や設計書、そしてプログラミング担当者とコミュニケーションを取り、単体テストする機能を洗い出します。*それにより、プログラミングすべきものができていなかったなど、機能の漏れが見つかる可能性もあるでしょう。*

ただし、システム開発を行う上で、コスト、納期、品質のバランスが重要です。そのため、洗い出したテスト項目を全て実施することができないことも頭に入れておきましょう。

### テスト観点と方法を明確にわかりやすく示す

前述の通り、単体テストの担当者は新人の場合が多いため、戸惑うことなく単体テストが行える単体テスト仕様書を作る必要があります。*そのために、誰もが実施することができるテストの観点や方法を作成するのが大切です。*

単体テスト仕様書を作成する際には、テスト実施者にとって分かりやすい観点を一覧などにしてまとめます。例えば、検索する機能の場合は、「正常にデータを取得することができたか確認すること」がテスト観点になります。

網羅性を高め、項目の漏れのない仕様書を作成するためには、全体像を縦横の項目に分けた表であるマトリクスを使用するのも効果的です。

そして、テストケースは、テスト観点を用いて作成されます。テスト実施担当者が、機能の内容を全て理解できていないエンジニアや新人である場合を想定してみましょう。SIer企業などは、テスト担当者をプロジェクトの途中から雇うこともあります。

SIerとSESの違いとは？見分け方を解説！働くならどっちがいい？

単体テスト仕様書は、要件定義書や設計書から作られることが多いです。テスト観点を作成し、まとまった時点で、要件定義を行った人や、設計者にレビューをしてもらいましょう。*レビューを実施することで、気付かなかったテスト観点の漏れを防ぐことができます。*

また、開発者の立場だけではなく、顧客側の立場で、テスト観点を洗い出すことも有効な方法です。システム開発は、チームで行っていきます。わからないことがあったら、コミュニケーションを積極的に取りましょう。

以上の、単体テスト仕様書を作成する際のポイントは単体テスト工程で大切なポイントです。業務でも役立つことでしょう。

システム開発のスケジュール管理方法や立て方・使えるスキルを紹介！

## 仕様書を作成する上で注意すべき2点

単体テスト仕様書によっては、システム側には問題がないものの、単体テスト担当者が正しくテストを実施することができず、正常な出力結果が得られていない、といった場合もよくあります。

ここからは、単体テストを作成する際に注意するポイントを2つ紹介します。

システム側に不備がないテストで結果が正常ではないというような問題は、単体テスト仕様書にて、テストが必要な機能を十分に洗い出しできていない場合に起こります。

また、要件定義書や設計書のインプットが十分にできていないことでも発生するでしょう。*テスト観点が不足していると、テストケースが足りない状態となり、機能が正しく動作しているかどうかテストできないまま、次の工程へ進んでしまうことになりかねません。*

### テスト観点の表現がわかりづらい、ズレている

*単体テスト仕様書の「テスト観点」がわかりづらく、曖昧なテストケースを作ってしまうことも、問題が発生する要因です。*また、テスト観点がシステム要件とズレてしまうと、単体テストをきちんと実施できたとしても、要件通りの正常な動作かどうか、わかりかねる結果となってしまう可能性があります。

以上の、単体テスト仕様書を作成する際の注意点を頭に入れておくことで、実際の業務でも活かすことができるでしょう。

<center>[あなたに合った企業選びをサポート致します。 エンジニア転職のご相談はぜひ *『マイナビIT エージェント』*へ！](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv12_2)</center>

## 単体テスト仕様書の作成は面倒くさい？

単体テスト仕様書の作成において「面倒くさい」という声はよく聞かれます。結論から言うと、*テストエンジニアという職種もあるように、単体テストが「面倒くさい」と感じるかどうかは人によって分かれるでしょう。*

これは、テストが「面倒くさい」と言われる理由が、単純作業の繰り返しであること、無駄な作業が多く効率が悪いことが多いためです。これらを解消するには、前述した作成時のポイントや注意点に注力する必要があります。

### 単体テストの効率をアップさせる方法

テスト工程は、効率が重要視されます。なぜなら、テストはあくまで仕様書に基づいた単純作業であり、膨大な量のテスト項目がある場合もあるため、1つ1つの作業に工数を多くかけてしまうと、テスト全体のコストが大きくなってしまうからです。

単体テストにかかる工数の例としては、単体テスト仕様書作成工数やレビュー工数などが挙げられます。

**単体テストの効率を上げるには、単体テスト仕様書のテンプレート化が1つの方法です。**テンプレート化することで、テスト効率が作成者の能力に依存するようなことが減り、品質の偏りも減少します。メンテナンスするためのコストの問題もあるので、案件によって使い分けましょう。

また、エクセル作業の場合、不要な作業が発生することも多いです。そのため、できる限り、無駄な作業を省くための作成ツールなども開発されています。工数を減らすためには、作成ツールの利用も検討することも大切です。

おすすめのテスト自動化ツールには、以下のようなものがあります。必要に応じて活用してみましょう。

【参考】：[Autify](https://autify.com/ja/)
【参考】：[MagicPod](https://magicpod.com/)
【参考】：[mabl](https://www.mabl.com/ja/)

他にも、開発の前例を参考にしてみるなど、効率を上げる方法はさまざまです。プロジェクトに合った効率化を図りましょう。

## 仕様書はわかりやすさと効率を意識した作成が肝心

単体テストはシステム開発の工程の中の1つで、未然にシステムエラーを防ぐ大切な役割を果たします。この記事では、知識やスキルを磨くいい機会であるため、新人に任されやすい業務であることも紹介し、単体テスト仕様書を作成する上でのポイントと注意点、効率化の方法についても解説しました。

テスト観点・方法を明確に定めたテスト仕様書を作成することで、効率的かつ的確なテストを実施することができます。**単体テストを適切に実施することができれば、プログラムの問題を早い段階で見つけることができ、手戻りを減らすことも可能であるため、コスト削減にも繋がります。**

今後テストエンジニアとして邁進していきたい、あるいはテストエンジニアからキャリアアップしていきたい場合は、自分に合う企業への転職がおすすめです。その際、転職エージェントを活用することで、優良企業と出会いやすくなるでしょう。

そこでぜひご活用いただきたいのが[マイナビIT エージェント](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv12_2)です。 

マイナビIT エージェントは、IT・Webエンジニア向けの無料の転職⽀援サービスです。

IT・Webエンジニアの転職事情に詳しいキャリアアドバイザーが、あなたのご経験やスキルをお伺いし、転職活動のプランをご提案致します。

アドバイザーは企業側の人事担当者と直接連携を取れますので、求人票に載っていない企業情報も確認することができます。残業時間や給与面など、働き方などをしっかり確認の上で応募企業を選んでいくのが良いでしょう。

・資格やプログラミングの勉強をしているけれど、企業が求めるレベルに達しているのかわからない
・スキルアップをして市場価値を上げていける企業の選び方を知りたい
・数多くあるITエンジニアの職種の中で、自分に向いている仕事は何か知りたい

こうした悩みを抱えていらっしゃる方は、まずは無料登録でキャリアカウンセリングをおすすめ致します。

「単体テスト」はシステム開発の工程の中の1つで、未然にシステムエラーを防ぐ大切な役割を果たしています。また、知識やスキルを磨くいい機会であるため、新人に任されやすい業務です。この記事では、単体テストの詳細と、仕様書を作成する上でのポイントを紹介します。

単体テストの定義や結合テストとの違いについて

単体テスト仕様書の作り方のコツ

単体テスト仕様書を作る上での注意点

新人が単体テスト仕様書を作るには？ポイントや注意点を解説

*[【マイナビITエージェント】あなたの転職活動を無料でサポートいたします](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=banner&utm_campaign=acv12_2)*

## 「単体テスト」と「結合テスト」の違いとは？

開発の現場では、エラーを検知する「テスト」作業が非常に重要です。ここでは、「単体テスト」と「結合テスト」はどういったものなのかを、システム開発の工程とともに紹介します。

### どちらもシステム開発で重要な工程の1つ

システム開発を行う上で、エラーや不具合はつきものです。どんなに細かくチェックを行っても、実際動かしてみると予期しないエラーが出たり、求めている機能が使えなかったりすることは多々あります。

そこで、必要になるのが「テスト工程」です。作成したシステムを納品するまでに、顧客が求める要件が満たされているか、たとえエラーが出力されてもシステムが稼働するような作りになっているかを地道にテストしなければなりません。

そんなテスト工程のうち、よく知られているのが「単体テスト」と「結合テスト」です。**同じシステム開発において実施されるテスト工程ですが、「単体テストは機能を小さい単体でテストする」、「結合テストは複数のモジュールを組み合わせてテストする」といった違いがあります。**

それぞれのテストを行う目的やタイミングは異なりますが、どちらもシステム開発では欠かせない重要な工程の1つです。

そもそも、このシステム開発はどのような流れで行われるのでしょうか？システム開発は決められた手順通りに進めていきます。例えるなら、家を建てる過程と似ています。

一般的には、*「要件定義→外部設計→内部設計→プログラミング（構築）→単体テスト→結合テスト→システムテスト→運用テスト→システム移行」といった流れをたどります。*

なお、「インフラエンジニア」と「アプリエンジニア」ではプログラミングの有無など、多少工程は変化します。今回は「アプリのシステム開発」を基準に紹介します。

要件定義とはシステム開発プロジェクトを進める前に、顧客にとって必要な機能や要件をまとめる作業のことです。プロジェクトが進んでいくとともに要件定義に立ち返ることも多く、目的をはっきりさせる工程でもあります。プロジェクトが上手くいくかは要件定義で決まると言っても過言ではありません。

外部設計では要件定義で作成した内容をもとに、外見的な見た目の部分を設計していきます。ユーザーの使いやすさに影響を与える部分になるので、使いやすいシステムを作るために大切な工程になります。

内部設計では、システムの中身であるプログラミングの設計をします。外部設計はユーザー側からの視点よりでしたが、内部設計では開発者側からの視点よりで設計していきます。

内部設計でプログラミングの設計が決まったら、設計書通りプログラミングを行っていきます。ただプログラミングを行うのでなく、設計書を作成した人やテストを行う人と積極的にコミュニケーションを行うのも大切です。

プログラミングを使う仕事とは？種類別の例や向いている人の特徴

後で詳しく紹介しますが、単体テストではプログラミングの粒度（単位）ごとにテストを行っていきます。この単位はモジュールと言われることもあります。単純作業になりがちなため、より効率が求められる工程でもあります。

こちらも後で詳しく紹介しますが、結合テストは複数のモジュールを組み合わせて、正しく機能しているかを検証します。結合テストはテスト項目の洗い出しが難しい部分でもあります。

*・総合テスト（システムテスト）*

総合テストでは全ての作成したプログラムが、要件定義で作成したシステム要件通りに正しく動くかをテストする工程です。性能や機能のテストを行います。ここからは、アプリの基盤を作成したインフラエンジニアの人と協力して行っていくこともあるでしょう。

運用テストでは実際にシステムを運用する顧客先の環境を設定し、システムに影響や不具合がでないかをテストしていきます。これまでのテストと比較すると実用性に重きを置いたテストとなっています。

運用テストってどんなテスト？目的や内容、注意すべきポイントとは？

システム移行は、古いシステムから新しく開発システムへ切り替える工程です。成功するか、ハラハラする工程でもあります。

保守・運用では、システムが問題なく運用しているかチェックしたり、よりよい状態にシステムを稼働させることができないか、プログラムを修正したりします。システムは24時間365日稼働していなければならないものもあるため、常にシステムを監視する業務も含まれます。

【保守・運用】仕事内容や将来性、必要なスキルについて徹底解説！

### システム開発のモデルの紹介

**システム開発には、さまざまな種類の開発モデルが存在します。**例えば、「ウォーターフォールモデル」、「アジャイル開発」、「プロトタイプモデル」、「スパイラルモデル」などです。ここでは、システム開発で最もよく使われる2種類のモデルを紹介します。

*・ウォーターフォールモデル*

**ウォーターフォールモデルは、要件定義や設計などの上流工程から、テスト、保守・運用などの下流工程へ、順を追って行われていくのが特徴です。**例えば、設計が完全に行われていないのに、プログラミングを行うことはありません。

スケジュール管理がしやすいので、大規模なシステム開発に適している開発手法と言えます。一方、工程でのミスが生じた場合の手戻りがある場合、時間を要してしまうのがデメリットです。

ウォーターフォール開発モデルとは？各工程やメリット・デメリットを解説！

アジャイルには「素早い、機敏な」という意味があります。アジャイル開発は文字通りスピード感のある開発手法です。**短い開発期間で単位を区切り、変更や修正を行います。**

メリットは、新しい技術開発などですぐに成果物が欲しいとき、とりあえず作ってみることができる点です。一方、スケジュール管理がしづらいのはデメリットです。

アジャイル開発の特徴、メリット・デメリット、DXとの関係など

<center>[『マイナビIT AGENT』なら、 IT業界に精通した専任アドバイザーと豊富な求人で、 あなたの転職活動を丁寧にサポートします。](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv12_2)</center>

ここでは、まず「単体テスト」について詳しく紹介します。上述したように、単体テストでは、プログラミングの対象単位ごとにテストを行っていきます。具体例を詳しく説明します。

新人が任されやすい単体テストとその仕様書の作成について徹底解説！

単体テストは「Unit Test（UT工程）」とも呼ばれる通り、メソッドや関数などの1つ1つの小さな単位ごとに行うテストのことです。**1つの画面や1つの機能で実施される動作をテストすることが目的となっています。**

しかし、実際にシステム開発で作るプログラムでは、画面や機能が複数存在している場合が多いです。そのため、動作の連携に関しては単体テストではなく、後で紹介する結合テストでチェックを行います。

一般的に、単体テストは条件分岐を網羅する観点からテストを行います。**理由としては、条件分岐を網羅することで、品質をある程度は確保できるからです。**

ただし、コスト、納期、品質のバランスの観点から、100％の品質を確保するテストはできないことは頭に入れておきましょう。

単体テストの手法の種類はさまざまです。代表的な手法である、「ホワイトボックステスト」と「ブラックボックステスト」を取り上げて紹介します。

**ホワイトボックステストは、プログラムが設計したとおりに動作するかを1つ1つ網羅的に確認するテストです。**つまり、「開発者側の視点」に立ったテストとも言えます。

例えば、設計書ではエラーが発生すると定義された文字列を入力し、出力結果が正常かどうかを検証します。ホワイトボックステストのメリットは、1つ1つのモジュールに対して網羅的に検証できることです。一方、デメリットは工数が増えてしまうことです。

**ブラックボックステストは、開発するシステム自体の仕様を満たしているかどうかを確認する機能のテストです。**つまり、「利用者側の視点」にたったテストと言えます。内部のプログラムについては考慮しないため、「ホワイトボックス」とは逆の「ブラックボックス」と呼ばれています。

テスト例として、設計書で0～100までの数値を正常と設定した場合、境界付近である値（例えば、0、-1など）を選んでテストします。理由としては、境界付近にプログラムの欠陥が多いためです。

ブラックボックステストのメリットは、利用者の要件を満たしていることが確認できる上に、工数を抑えることができる点です。一方で、プログラムの内部処理が適切に行われているのかわからない点はデメリットです。

### 単体テストの仕様書を作成する

単体テストを実施する際は、単体テスト仕様書と呼ばれるドキュメントを用意します。仕様書を作成する際は、「入力手順」「テスト方法」「テスト観点」などを詳しく記載しましょう。単体テストの仕様書を丁寧に作成すると、網羅的にテストを行うことが可能になり、結果的にシステムの品質を上げられます。

結合テストでは複数のモジュールを組み合わせて、正しく機能しているかを確認します。ここからは結合テストについて詳しく紹介します。

「結合テスト」の観点や目的を押さえ、システムの品質を担保しよう！

結合テストは「Combined Test（CT工程）」とも呼ばれており、複数のモジュールを組み合わせて行うテストのことです。**「モジュールを結合させたときに、設計したように動作するのか」「想定外の状況のエラーが出力されても、システム要件が満たされているか」といったことを検証するのが目的です。**

また、単体テストで正常を確認できたモジュール同士を組み合わせるだけでなく、その他の外部モジュールを結合したテストも行うことがあります。

**結合テストは要件定義に基づいて、機能要件や非機能要件の観点からテスト項目を洗い出します。**単体テスト同様に、コスト、納期、品質のバランスの観点からテスト項目を選定することが大切です。

単体テストと違い、結合テストではシステムの全体的なデータの流れを把握ができる技術が必要になります。1つ1つの機能にエラーがなくても、連携させると問題が発生する可能性があるためです。

プロジェクトの成否を左右する非機能要件の一覧について詳しく解説！

**結合テストの手法としては、「インターフェーステスト」「ブラックボックステスト」の2つが代表的です。**具体的に紹介します。

インターフェースとは、モジュール同士を接続したときに、データの引き渡しを仲介する仕組みのことを指します。インターフェーステストは、結合テストの中では「定番」と言ってもいいほど一般的なもので、「連結テスト」とも呼ばれます。

インターフェーステストでは、機能間やモジュール間でデータを引き渡す際に、引き渡されるべきデータがきちんと引き渡されているか、連携に関わるモジュールが設計した通りに正常に動作しているかなどを検証します。

単体テストで説明した通り、ブラックボックステストはプログラムの内部構造を考慮しないで、入力に対して正常な出力結果を得ることができるか検証するテストです。

結合テストでは、単体テストで正常を確認できたモジュール同士を結合して、ブラックボックステストを実施することで、仕様を満たしているかどうかを確認します。

また、この2つ以外に「トップダウンテスト」と「ボトムアップテスト」があります。「トップダウンテスト」は上位モジュールを呼び出した後に、下位モジュールヘと移行してテストを進めていく方式です。「ボトムアップテスト」はプログラムの下位階層にあるモジュールから、優先的にテストを進めていく方式です。

## 単体テストと結合テストを実行するエンジニアは？

システム開発において重要な役割であるテスト工程ですが、実際の業務では誰が実施するのでしょうか？ここでは、テスト工程を担うエンジニアについて解説します。

### 基本はテストエンジニアが行う

テスト工程を行うのは「テストエンジニア」と呼ばれる業種です。**テストエンジニアはテストの実行だけでなく、テスト計画の策定、結果の分析、改善提案まで幅広い技術と知識を求められます。**

近年は品質管理やセキュリティーがさらに重要視されているため、大きな責任も伴います。また、効率向上のために「IaC」のようなテスト自動化ツールを導入する企業もあり、常に新しい知見が必要です。

テストエンジニアの求人の探し方と、そのポイントを解説！

「単体テスト」と「結合テスト」はシステム開発の工程の中のひとつです。テスト工程はシステム開発を行う上で、未然にシステムエラーを防ぐ大切な役割を果たしています。この記事では、「単体テスト」と「結合テスト」の位置づけと違いについて徹底解説していきます。

単体テストと結合テストはシステム開発の中の一工程

単体テストはメソッドや関数など1つ1つの小さな粒度（単位）ごとに行う

結合テストは複数のモジュールを組み合わせて行う

「単体テスト」と「結合テスト」の違いとは？やり方や観点を解説

単体テストの記事（1ページ目）