システム開発技術とは、企業や組織の「業務課題を解決し、効率化する仕組み（システム）」をIT技術を用いて、企画・設計・プログラミング・テスト・運用するまでの一連の技術とプロセスの総称で、具体的には、要件定義、設計、コーディング、テスト、運用・保守などの工程があり、ウォーターフォールやアジャイルといった様々な開発手法が存在します。
画像参照：https://www.co-well.jp/blog/system_dev_flow
単体テスト（UT）
単体テスト（ユニットテスト）とは、ソフトウェアを構成する関数やメソッド、クラスなどの最小単位が、設計通りに正しく動作するかを検証するテストです。開発の早い段階（コーディング直後）に開発者自身が行い、バグの早期発見と修正、開発効率の向上を目的とし、後工程での手戻りを防ぐ重要な役割を担います。
目的とメリット
- 早期のバグ検出: 開発の初期段階で不具合を見つけ、修正コストを削減します。
- 品質向上と信頼性: 個々の部品が正しいことで、システム全体の品質と信頼性を高めます。
- 手戻りの防止: 後工程で大規模な手戻りが発生するのを防ぎます。
- 設計の改善: テストを通じて、仕様の矛盾や抜け漏れを設計段階で発見できます。
テストの手法（観点）
単体テストでは、主に以下の2つの観点でテストを行います。
- ホワイトボックステスト: コードの内部構造（ロジック、分岐、経路）に着目し、設計通りに動作するかを検証します。
- ブラックボックステスト: 外部仕様に基づき、正しい入力に対して期待通りの出力が得られるか（仕様通りの振る舞いか）を検証します。
テストの単位と実施タイミング
- 単位: 関数、メソッド、クラスなどのプログラムの最小単位。
- タイミング: プログラミングが完了した後、すぐに開発者が実施するのが一般的です。
結合テスト（IT）
結合テストは、単体テストで個別に検証された複数のモジュールを組み合わせて、それらが連携して設計通りに動作するかを確認するテストです。モジュール間の「インターフェース（つなぎ目）」でのデータの受け渡しや、機能間のつながりに問題がないかを検証し、単体テストでは見つけられない連携不備やデータ不整合を早期に発見して、後の工程での手戻りを防ぐことが目的です。
目的
- モジュール間の連携検証: 単体では問題なくても、組み合わせると不具合が発生することがあるため、その連携部分をチェックします。
- データ連携の確認: データが正しく渡され、意図した通りに処理されるかを確認します。
- システム品質の向上: 連携部分のバグを早期に発見し、後工程（システムテスト、受け入れテスト）での大きな問題を防ぎます。
種類（実施方式）
- トップダウンテスト: 最上位のモジュールから順に結合し、下位モジュールはスタブ（仮のモジュール）で代用しながらテストを進めます。
- ボトムアップテスト: 最下位のモジュールから結合し、上位モジュールはドライバ（仮のモジュール）で代用しながらテストを進めます。
- サンドイッチテスト: トップダウンとボトムアップを組み合わせた方式です。
- ビックバンテスト：単体テストを終えたモジュールを一度に結合して一気にテストする手法です。
- 一斉テスト：単体テストを省略してモジュールを一度に結合する手法です。
単体テストとの違い
- 単体テスト: モジュール単体の内部ロジックや機能が正しいかを確認（例：入力画面で数値が正しく入力できるか）。
- 結合テスト: モジュール間の連携やデータの流れが正しいかを確認（例：入力画面で入力したデータが、別画面の参照機能に正しく反映されるか）。
結合テストのポイント
- テスト仕様書の作成: 結合テストの項目を事前に洗い出し、テスト仕様書を作成します。
- 環境の整備: 実際のシステムに近い環境（データベースなども含む）でテストを実施することが重要です。
- ブラックボックステスト: 内部構造を意識せず、入力に対して正しい出力を返すかを検証する手法も用いられます。
トップダウンテスト
トップダウンテストは、ソフトウェア開発の結合テスト手法の一つで、システムの上位モジュール（親）から下位モジュール（子）へ向かって順に結合・テストしていく方法です。重要な上位モジュールからテストするため致命的な不具合を早期発見でき、全体の構造を把握しやすいですが、未完成の下位モジュールを代替するスタブ（ダミーモジュール）の作成工数が増えるのがデメリットで、大規模システムで利用されます。
特徴
- テストの方向: 最上位モジュールから開始し、下位モジュールに向かってテスト範囲を広げます。
- 未完成モジュールへの対応: 下位モジュールが未完成の場合、「スタブ」と呼ばれる仮のモジュールを作成して代替します。
- 検証のタイミング: システムの全体的な動作や主要な機能の連携を早期に確認できます。
メリット
- 致命的な欠陥の早期発見: システムの根幹部分の不具合を早い段階で見つけられます。
- 全体像の把握: 上位からテストすることで、システム全体の動作フローを理解しやすいです。
- 重要なモジュールの信頼性向上: 重要なモジュールが繰り返し使われるため、その信頼性が高まります。
デメリット
- スタブ作成の工数: 未完成の下位モジュールが多いほど、多くのスタブを作成する必要があり、手間がかかります。
- 詳細部分の発見の遅れ: 下位レベルの細かい不具合や、下位モジュールが完成した後に現れる問題は発見が遅れることがあります。
どんな時に使う？
- 画面UIやコントローラー層など、ユーザーインターフェースや操作フローを重視する場合。
- システムの中枢部分（最上位モジュール）に重要な機能や致命的なバグが潜んでいる可能性がある場合。
ボトムアップテスト
ボトムアップテストとは、ソフトウェア開発における結合テスト手法の一つで、システムの一番下位（呼び出される側）のモジュールから順にテストし、上位モジュールへと結合しながら検証していく方法です。上位モジュールが未完成の場合は、それを模倣する「ドライバ」という代替モジュールを作成してテストを進め、重要な計算処理など根幹部分の安定性を優先的に確認できるのが特徴です。
特徴と流れ
- 開始点: システムの最下位モジュール（他のモジュールから呼び出される部品）からテストを開始します。
- テストの進行: 下位モジュールをテストし、問題なければ次にそれらを呼び出す上位モジュールと結合してテストします。このプロセスを繰り返して最上位まで進めます。
- ドライバの利用: 上位モジュールが未完成の場合、「ドライバ」というダミーの呼び出し元モジュールを作成して、下位モジュールの動作を確認します。
- メリット:
- 開発とテストを並行して行いやすく、開発サイクルを回しやすい。
- ロジックや計算処理など、システムの核となる部分の安定性を早期に確認できる。
- 問題の発生箇所を特定しやすい（結合部分が明確なため）。
- デメリット:
- 最上位モジュールで問題が見つかると、多くの下位モジュールの修正が必要になり、手戻りが発生するリスクがある。
- テストごとにドライバの作成・変更が必要になる。
トップダウンテストとの違い
- トップダウンテスト: 上位モジュールからテストし、下位モジュールを「スタブ（Stub）」というダミーで代替する。
- ボトムアップテスト: 下位モジュールからテストし、上位モジュールを「ドライバ（Driver）」で代替する。
ビックバンテスト/一斉テスト
ビッグバンテスト/一斉テストとは、ソフトウェア開発における結合テストの手法の一つで、開発されたすべてのモジュールを一度に結合（合体）させて、まとめてテストを行う方法です。単体テストが終わった部品を「一斉に」テストするため、段階的に結合する「増加テスト（トップダウン/ボトムアップ）」と対照的で、準備が簡単でテスト工数を短縮できる反面、不具合の原因特定が難しいという特徴があり、小規模なシステム開発に向いています。
特徴
- 手法: すべてのモジュールを一度に結合してテストを開始する（「出たとこ勝負」的な側面も）。
- 準備: 各モジュールは単体テストが完了している必要があるが、ドライバやスタブ（模擬プログラム）は不要。
- メリット:
- テスト開始までの準備が簡単。
- テスト工数や期間を短縮できる可能性がある。
- デメリット:
- 不具合が発生した際、原因がどのモジュールにあるのか特定しにくい（デバッグが困難）。
- 適用: 小規模なシステムや、構造が単純なシステムに適している。
他の結合テスト手法との比較
- 増加テスト（トップダウン/ボトムアップ）との違い:
- ビッグバンテストは「一斉に」結合するのに対し、増加テストはモジュールを1つずつ追加しながら段階的に結合していく。
- 増加テストは手間がかかるが、原因特定がしやすい。
「ビッグバンテスト」と「一斉テスト」の関係
- 基本的には同じ意味で使われることが多い。
- 厳密に区別するなら、ビッグバンテストは「単体テスト後に一斉結合」、一斉テストは「単体テストも省略して（ほぼ）未テストのまま一斉結合」という解釈もあるが、一般的には同義として扱われる。
システムテスト（ST）
システムテストとは、開発されたシステム全体が要件定義通りに動作するか、総合的に検証する最終段階のテストで、「総合テスト」とも呼ばれ、単体・結合テスト後に本番に近い環境で機能、性能、セキュリティ、ユーザビリティなどを多角的に確認し、品質を確保します。最終納品前の重要な工程であり、システム全体を俯瞰し、ハードウェアも含めた不具合を発見して、顧客満足度を高める役割があります。
主な目的
- 要件適合性の検証: システムが仕様書通りの機能や性能を満たしているか確認。
- 統合性の確認: 個々の機能が連携し、システム全体として正しく動作するか。
- 品質の総合評価: ユーザビリティ、パフォーマンス、セキュリティ、安定性などを評価。
- リスクの低減: 開発環境では見つからない問題を本番環境を想定して発見し、残存リスクを減らす。
確認する観点（種類）
- 機能テスト: 要件定義された機能が正しく動作するか。
- 性能テスト: 応答時間、スループット、負荷耐性などを評価。
- セキュリティテスト: 不正アクセスや脆弱性がないか確認。
- ユーザビリティテスト: 使いやすさや操作性、分かりやすさを評価。
- 互換性テスト: 異なる環境（ブラウザ、OS、ハードウェア）での動作を確認。
- 運用・保守性テスト: 運用や保守がスムーズに行えるか。
- 障害・リカバリテスト: 障害発生時の復旧プロセスを確認。
テストの実施プロセス
- テスト計画: テスト範囲、体制、リスク、スケジュールを決定。
- テストケース作成: 要件に基づき、具体的なテスト手順（テストケース）を設計。
- テスト実行: 設計したテストケースを用いて、本番に近い環境で実施。
- 不具合管理: 発見された不具合を報告、修正、再テストする。
- テスト完了: 結果を分析し、完了報告書を作成して終了。
単体テスト・結合テストとの違い
- 単体テスト: プログラムの最小単位（モジュール）が個別に正しいか確認。
- 結合テスト: モジュールを結合した際の連携部分に問題がないか確認。
- システムテスト: これらを終えた後、システム全体を要件定義書に基づいて評価する、開発の最終段階。
運用テスト（OT）
運用テストとは、システム開発の最終段階で、本番環境に近い環境で実際の業務手順や負荷を想定し、システムが安定して管理・運用できるか、ユーザー視点で最終確認するテストです。機能が仕様通りかだけでなく、性能、応答時間、エラー処理、セキュリティ、マニュアルとの整合性なども検証し、実運用での問題発生を防ぎ、リリース後の安定稼働と品質向上を目指します。
目的と重要性
- 実運用への適合性確認: 開発環境と本番環境のギャップをなくし、実際の業務フローやユーザー権限で問題なく動作するかを確認します。
- 安定性と性能の検証: 想定される負荷やデータ量での処理速度、応答時間、耐久性などをチェックし、システム全体の安定性を保証します。
- トラブルの未然防止: 誤操作や障害発生時のエラー処理、復旧手順などを確認し、リリース後の障害リスクを低減します。
- 最終的な品質保証: 顧客や運用担当者が「このシステムなら安心して使える」と判断するための最終関門であり、受け入れテスト（UAT）を兼ねることも多いです。
主なチェック項目
- 業務シナリオ: 実際の業務手順書に沿って操作し、一連の流れが問題なく完了するか。
- 権限管理: 一般ユーザー、管理者など、役割に応じた適切な権限で操作できるか。
- 性能・負荷: 想定される最大負荷をかけ、応答時間やリソース使用率が許容範囲内か。
- エラー・障害対応: 意図的にエラーを起こし、エラーメッセージ表示や復旧手順が適切か。
- 運用・保守: 運用マニュアルと手順の整合性、バックアップ・リカバリ手順の確認。
実施主体とタイミング
- 実施主体: 開発者ではなく、実際にシステムを利用する運用担当者やユーザー部門が中心となることが多い。
- タイミング: システム開発工程の最終段階、本番稼働直前に行われる。
関連するテストとの違い
- 受け入れテスト（UAT）: 運用テストと目的が重複することが多いが、受け入れテストは「顧客（発注者）が納品物を受け入れるか」の検収が主目的で、運用テストは「実際に運用できるか」の機能・安定性確認が主目的とされます。受託開発では、運用テストの合格が受け入れの条件となることもあります。
受け入れテスト（UAT）
受け入れテストとは、開発されたシステムやソフトウェアが発注者の要求や業務要件を満たしているか、実際の利用環境で問題なく使えるかを確認する最終テストで、リリース前に行われ、ユーザー視点での「使える品質」を見極める重要な工程です。単なる技術的な検証ではなく、ビジネスの現場で本当に役立つかを確認し、承認・検収の判断材料となるテストで、通常は発注者側が実施します。
目的
- 業務要件の充足確認: 定義されたビジネス要件通りにシステムが機能するかを確認します。
- ユーザー視点での検証: 実際のユーザーが使いやすいか、運用上の問題がないかを確認します。
- 最終的なリリース判断: 問題がなければリリース（本番稼働）を承認し、問題があれば修正を指示します。
他のテストとの違い
- 単体テスト・結合テスト: 開発者視点で個々の機能や連携を技術的に検証します。
- システムテスト: 開発者視点でシステム全体を技術的に検証します。
- 受け入れテスト: 発注者（ユーザー）視点で、業務で使えるかどうかに焦点を当てます。
主な種類（目的別）
- ユーザー受け入れテスト（UAT）: ユーザーが実際の業務シナリオで利用し、要件を満たすか確認。
- 運用受け入れテスト（OAT）: リカバリ、保守性、信頼性など、運用準備状況を評価（非機能テスト）。
実施主体
- 発注側（エンドユーザー）が実施するのが基本。
- 専門人材やリソース不足の場合、外部の専門業者に委託することもある。
受け入れテストは、システム開発の成功を左右する最終関門であり、ビジネスへの価値を最終確認する上で非常に重要です。
退行テスト
退行テスト（リグレッションテスト）とは、ソフトウェアの修正や機能追加後に、以前は正常に動いていた部分に新たな不具合（デグレ）が発生していないかを確認するテストで、「回帰テスト」とも呼ばれ、変更による予期せぬ影響がないかを確かめるために必須の品質保証活動です。プログラムが複雑化するほど重要度が増し、テストの効率化のために自動化が進められています。
目的
- バグの再発防止: バグ修正が他の箇所に悪影響を与えていないかを確認する。
- 品質維持: 新機能追加や改修後も、システム全体の品質が低下していないかを保証する。
- 影響範囲の確認: 変更がシステム内の他の機能や連携部分に意図しない副作用（リグレッション）を起こしていないかを検出する。
実施タイミング
- バグ修正後: 修正した箇所だけでなく、関連する周辺機能も確認する。
- 機能追加後: 新機能の追加で既存機能が壊れていないかを確認する。
- 環境変更後: OSやデータベースのバージョンアップなど、環境変更時にも実施する。
重要性
- 複雑なシステム: ソフトウェアが大規模・複雑になるほど、相互依存性が高まり、一部の変更が全体に影響するリスクが増大するため。
- 品質保証の要: 顧客に確実に仕様通りのシステムを届けるために不可欠。
効率化の方法
- テスト自動化: 過去のテスト資産（テストケース）を再利用し、自動化することで工数と時間を大幅に削減する。
コメント