システム開発のテスト工程や種類、手法、実施の手順を徹底解説

システム開発におけるテストは、開発するシステムの品質に直結する、非常に重要な工程です。

この記事では、システム開発におけるテストの種類や手法、実施手順を紹介します。システム開発の全体像への理解に役立てば幸いです。

システム開発におけるテストとは

システム開発では、開発したシステムが期待通りに動作するかを確認するためにテストを行ないます。

一般的には、テストを通して不具合の発見・修正を繰り返しながらシステムを完成させることから、開発したシステムの品質を担保するうえでも、テストは非常に重要です。

テストの観点は機能要件・非機能要件の2つ

システム開発のテストにはさまざまな種類がありますが、大きく分けると「機能要件」「非機能要件」という2つの観点があります。

機能要件のテストとは

機能要件とは、システムの具体的な機能や動作を指します。

システム開発における機能要件のテストでは「開発した機能が正しく操作できるか」という観点で、開発したシステムが設計通りに機能するかを確認します。

非機能要件のテストとは

非機能要件とは、システムの耐久性やセキュリティなど、機能以外の性能を指します。

たとえば、システムの応答速度をテストしたり、同時アクセス数を増やしながら、何人まで問題なくシステムを利用できるかをテストしたりします。

システム開発会社と依頼者の双方が実施する

テストは、システム開発会社（エンジニア、テスターなど）、システム開発の依頼者（依頼者、システムの利用者など）が実施します。

テストの担当者は、テストの工程や種類によって異なります。

システム開発の成功のポイントは、システム開発の依頼者と開発者が双方でテストを実施することです。

システムの利用者がテストを実施することで、実際の利用環境を想定した操作を確認でき、システムの品質を高めることにつながります。このため、システム開発会社にテストを丸投げするのではなく、システムの依頼者もテストを行なうようにしましょう。

テストの工程と種類

システム開発のテストはいくつかの工程に分かれており、工程ごとに異なるテストを行ないます。ここでは、工程別に代表的なテストを紹介します。

単体テスト

単体テストは、システム内の機能を構成する部品がそれぞれ正しく動作するかを確認するテストです。

通常、エンジニアが、システムのプログラミングを行なったあとに実施します。

単体テストは、テスト工程の最初で実施します。このため、単体テストの段階で不具合を早期発見し修正することにより、後の工程での問題発生を防ぐことにつながります。

結合テスト

結合テストは、単体テストでテストした部品同士を組み合わせ、正しく連携・動作するかを確認するテストです。

システム開発会社のエンジニアとテスターが共同で行なうことが多いです。

総合テスト・システムテスト

総合テスト・システムテストは、システム全体の機能や性能が仕様通りに動作するかを確認するためのテストです。

一般的にはシステム開発会社のエンジニアとテスターが実施します。

総合テスト・システムテストとして実施するテストにはさまざまな種類、分類があります。ここで主なテストの種類を紹介しましょう。

機能テスト

機能テストとは、システムが仕様通りに動作するかを確認するためのテストです。

回帰テスト（リグレッションテスト）

回帰テスト（リグレッションテスト）は、システムに新しい変更や修正を加えた後、既存の機能が正常に動作するかを確認するためのテストです。

特に、頻繁に更新を行うシステムの開発の際に重要です。

デグレーションテスト

デグレーションテストは、回帰テスト（リグレッションテスト）と同じく、システムの変更や修正に伴い、既存のシステムに悪い影響が発生していないかを確認するためのテストです。

回帰テスト（リグレッションテスト）とデグレーションテストの違いとして、回帰テスト（リグレッションテスト）は機能上の不具合、デグレーションテストは非機能面の劣化に焦点を当てるという考え方があります。ただし、実務上はほぼ同義で使用することもあります。

ユーザビリティテスト（操作性テスト）

ユーザビリティテストは、利用者にとってシステムが使いやすいかを評価するためのテストで、直感的に操作できるか、必要な機能を簡単に見つけられるかなどを確認します。

実際にシステムを利用する人からもフィードバックを収集すると、システムの使いやすさの向上につながるでしょう。

性能テスト（パフォーマンステスト）

性能テスト（パフォーマンステスト）は、システムの処理速度や一度に処理できるデータ量などにおいて、開発したシステムが期待する基準を満たしているかを確認するためのテストです。

負荷テスト

負荷テストは、開発したシステムに負荷をかけた際（同時アクセスを増やすなど）の挙動を確認し、安定して動作するかを評価するためのテストです。

ストレステスト

ストレステストは、システムに極限の負荷をかけた場合の挙動を確認するためのテストです。これにより、開発したシステムの限界を確認します。

負荷テストと同義で使用する場合もありますが、負荷テストは高負荷時に安定して稼動するかを確認するため、ストレステストは限界値を確認するためのテストとして分ける考え方もあります。

スロングランテスト（耐久テスト）

ロングランテスト（耐久テスト）は、システムを長時間稼働させた際の挙動を確認するためのテストです。

システムを一定期間連続稼働させ、メモリの枯渇などの問題が発生しないかを確認しながら、長期的に安定して動作するかを確認します。

ロードテスト

ロードテストとは、負荷をかけた状態と、負荷をかけていない通常の使用状況を比較して、その差が想定内であるかを確認するテストです。

キャパシティテスト（容量テスト）

キャパシティテスト（容量テスト）とは、データの最大容量を確認するためのテストです。大量のデータを入力し、開発したシステムが問題なく動作するかをテストします。

セキュリティテスト

セキュリティテストは、外部からの攻撃や不正アクセスに対して、システムにどれだけの耐性があるかを評価するためのテストです。

システムの脆弱性を発見し、データの保護やプライバシーの確保を強化することで、システムの安全性を高めます。

障害回復テスト

障害回復テストは、障害が発生した際に、システムがどれだけ迅速に復旧できるかを評価するためのテストです。

システムの一部を意図的に停止させ、その後の復旧プロセスを観察します。

移行テスト

移行テストは、既存のシステムが存在し、新たに開発するシステムへデータ、ファイル、ソースコードなどを移行する必要がある場合に実施します。テスト内容は、移行対象の内容に応じて異なります。

移行する内容の完全性・一貫性を検証し、途中で失われたり、破損したりしないことを確認します。

受け入れテスト

受け入れテストは、システムを実際に利用する人のシチュエーションを想定しながら、期待通りに動作するかを評価するためのテストです。受け入れテスト終了後は、システムを正式にリリースし、運用を開始します。

受け入れテストは、システム開発の依頼者や、実際にシステムを利用する人が実施します。

運用テスト

運用テストは、実際の運用環境でシステムが問題なく動作するかを確認するためのテストです。

受け入れテストとほぼ同義で使用することも多いですが、システムの開発方法（開発会社へ外注したか、自社内で開発したか）によって呼び分けることがあります。

システムを開発会社へ外注した場合は、外部からの納品を受け入れる意味で「受け入れテスト」、自社内で開発した場合は「運用テスト」と呼ぶ傾向があるといえるでしょう。

アジャイル開発の場合

システム開発の手法には、大きく「ウォーターフォール型」「アジャイル型」の2種類があり、ウォーターフォール型の開発では、全ての機能の開発を終えた後に「単体テスト→結合テスト→総合テスト・システムテスト→受け入れテスト」の順にテストを実施します。/p>

一方、アジャイル開発とは、開発する機能を細かい単位に分け、2週間などの短いサイクルに区切って、小さな開発サイクルを繰り返す開発手法です。

このため、アジャイル開発の場合は、短い間隔で小さなテストを繰り返す傾向があります。

これにより、早い段階での不具合の発見・修正がしやすく、開発するシステムの品質向上につながりやすいというメリットがあります。

一方で、アジャイル開発では、システム開発会社と依頼者が定期的にコミュニケーションをとりながら、テストを継続することが不可欠です。

開発するシステムの規模や内容によって、適切な手法を選ぶことが大切です。

おもなテストの手法

システム開発にはさまざまなテストの手法があります。代表的な手法と具体例を紹介しましょう。

ホワイトボックステスト

ホワイトボックステストは、システムの内部構造を考慮し、システムが意図通りに動作するかを確認するためのテスト手法です。具体的には、制御フローテストやデータフローテストなどを含みます。

制御フローテスト

制御フローテストは、処理の経路を検証するためのテスト手法です。システム内に条件分岐（たとえば、点数に応じて合格・不合格を自動判定するなど）がある場合、正しく処理されるかを確認します。

データフローテスト

データフローテストは、システム内のデータの流れを検証するためのテスト手法です。データが正しく作成、使用、破棄されるかを追跡し、全体の流れにおいてデータの整合性がとれているかを確認します。

ブラックボックステスト

ブラックボックステストは、システムの内部構造を考慮せず、入力したデータとその結果などに基づいて検証するテスト手法です。具体的には、同値分析や限界値分析などを含みます。

同値分析

同値分析では、代表的な値を選んでテストを行ないます。

たとえば、入力できる数字が1~100の場合、有効な数字（例：25、50、75）、無効な数字（例：-5、120）をいくつか選んで、入力時の挙動が期待通りかを確認します。

限界値分析

境界値とは、入力するデータ範囲の上限や下限を指します。限界値分析では、入力値の境界付近を重点的にテストします。

たとえば、入力できる数字が1~100の場合、0、1、100、101、入力時の挙動が期待通りかを確認します。

テストの流れ・手順

一般的なテストの流れ・手順は以下のとおりです。

それぞれ順番に説明します。

テスト計画を作成する

テスト計画を作成する際は、以下の点を検討しましょう。

テスト方針

テスト方針とは、テストの目的や範囲、手法を明確にするための指針です。以下などを明確にしましょう。

体制、メンバー

以下などの、テストを実施する体制やメンバーを明確にします。

スケジュール、テストの実施手順

テスト開始から終了までのタイムラインを明確にしましょう。具体的に確認するべきポイントは以下です。

テスト環境、使用するツール

テストを実施するための環境や使用するツールを明確にします。

テスト環境はハードウェア、ソフトウェア、ネットワーク構成など、テストツールはテスト管理ツール、バグトラッキングツール、自動化ツールなどを含むことがあります。

テストデータの準備

テストに使用するデータの方針（実際のデータを使用する、テスト専用のデータを生成するなど）、データ項目、準備の手順を明確にします。

管理規定

テストを管理するための規定を明確にします。具体的には、テストケースの作成や管理、テスト結果の評価や報告、不具合の報告や追跡方法、変更・管理の方法を確認します。

テストケースの詳細

テストケースには、各テスト項目の目的、前提条件、入力するデータ、期待される結果、実行手順などを記載しましょう。

結果の記録、評価方法

テスト結果の記録方法、評価基準を明確にします。どの基準で合否を判断するか、指標（KPI）などを具体的に示しましょう。

不具合の報告、管理方法

不具合を発見した場合の記録方法、報告方法、優先度の設定方法、修正依頼～再テストの手順を明確にします。

テスト仕様書を設計する

テスト仕様書とは、テストの計画や実行手順をドキュメント化したものです。

前述のテスト計画で策定した内容を文書で明記することにより、テストの一貫性や効率性を担保します。

テストを実施する

計画をもとにテストを実施します。テストを実施する際の手順は以下のとおりです。

テスト環境の確認、テストケースの準備

テストに必要なハードウェア、ソフトウェア、ネットワーク設定などの環境が、事前の計画通りに設定されているかを確認します。

また、作成したテストケースを準備しましょう。

テストの実施

テストケースに従ってテストを実施して、結果を記録します。期待される結果と実際の結果を比較し、期待通りでない場合や不具合を発見した場合は、詳細を記載しましょう。

結果の分析

テストの結果をもとに、不具合や課題を洗い出したり、システムの品質やパフォーマンスを評価したりします。結果を分析し、改善すべき点を検討しましょう。

不具合の修正、再テスト

発見した不具合を開発チームへ報告し、システムの修正を依頼します。

修正完了後は再テストを実施し、課題が解消されているか確認しましょう。再テストの際は、修正箇所だけではなく、関連する機能に影響がないかもあわせて確認することが大切です。

テストの評価

すべてのテスト完了後、結果を総合的に評価し、システムがリリース基準を満たしているかを判断します。

テスト報告書の作成

テストの結果をまとめた報告書を作成します。報告書の詳細について、次の項目で見ていきましょう。

テスト結果を報告する

テスト結果を報告する際は、報告書に以下の内容を記載しましょう。関係者に報告書を確認してもらい、承認後、次のステップに進みます。

テストの概要

テストの目的、範囲、実施期間、使用したテスト環境など、テストの概要を簡潔に記載します。これにより、報告書の全体像を把握しやすくなります。

テストケースの結果

テストケースの記録を共有。成功した項目と失敗した項目を明確にし、失敗した項目の原因や影響を説明します。

不具合の詳細

発見した不具合について、詳細を記述します。不具合の種類、発生条件、再現手順、影響範囲などを具体的に記載しましょう。

統計データ

テスト結果を、成功率、失敗率などの統計データにまとめ、システムの品質を定量的に評価します。

改善点と提案

テスト結果に基づいて、システムの改善点や提案を記載します。コードの修正、パフォーマンスの最適化、セキュリティ強化などを提案することが多いです。

次のステップ

テスト結果を踏まえた、次のステップを明確にします。再テストの計画や、リリース前の最終確認など、今後のアクションプランを具体的に示します。

まとめ