システム開発のテストとは

システム開発のテストは、成果物を確認し、品質とリスクに関する情報を得る活動です。

工程・種類・手法は異なる分類軸なので、「いつ・どこまで」「何を」「どう確かめるか」に分けると理解しやすくなります。

テストの目的

テストの目的は、要求や設計に対する違い、不具合、利用上のリスクを見つけ、修正やリリースの判断に必要な情報を提供することです。

合格数を増やすことだけが目的ではなく、重要な機能が期待どおりに動くか、残る問題を受け入れられるかを評価します。

ただし、テストで不具合を見つけることはできても、すべての不具合が存在しないと証明できるわけではありません。

対象の重要度とリスクに応じて優先順位を付け、限られた期間でどこまで確認するかを決めます。

開発全体での位置づけは、開発エンジニアが関わる工程でも確認できます。

出典：ISTQB「Certified Tester Foundation Level Syllabus v4.0.1」

検証と妥当性確認

検証では、仕様書や設計書、コードなどの成果物が、定めた要求や基準を満たしているかを確かめます。

レビューや静的解析のようにプログラムを実行しない活動も、品質を確かめる方法に含まれます。

妥当性確認では、完成したシステムが利用者の目的や実際の業務に合っているかを見ます。

仕様どおりでも操作しにくい、業務の流れに合わないという問題は起こり得るため、文書との一致と利用目的への適合を分けて考える必要があります。

「仕様どおり」と「使う目的に合う」の両方を確認することが重要です。

開発手法で進め方が変わる

ウォーターフォール型では、単体、結合、システム、受入のように段階を分け、前工程の成果物を基に確認する進め方が代表的です。

各工程の開始条件、終了条件、承認者を明確にしやすい一方、後半で見つかった問題が前工程へ影響する場合があります。

アジャイル開発では、短い反復の中で設計、実装、テストを繰り返し、機能ごとにフィードバックを得ます。

工程名が表に出ない場合でも、部品、連携、システム、利用目的を確かめる観点は必要です。

システム開発のテスト工程

テスト工程は、どの範囲の成果物を、どの段階で確認するかを表します。

単体、結合、システム、受入が代表的ですが、名称、境界、担当者はプロジェクトによって異なります。

単体テスト

単体テストは、関数、クラス、モジュールなど、プロジェクトで定めた小さな単位を確認する工程です。

入力と出力、条件分岐、境界値、例外処理などを対象にし、主に実装担当者がコードに近い位置で実施します。

外部サービスやデータベースを代替する仕組みを使う場合は、実際の接続を確認していない範囲を明確にします。

単体テストを通過しても、複数の機能や外部システムを組み合わせた動作が保証されるわけではありません。

確認した単位と代替した依存先を記録すると、次工程の確認範囲が分かりやすくなります。

結合・システムテスト

結合テストでは、モジュール、API、データベース、外部サービスなどを接続し、インターフェースやデータの受け渡しを確認します。

接続順、データ形式、タイムアウト、エラー時の連携など、単体では見えにくい問題が対象です。

システムテストでは、統合されたシステム全体を対象に、要求された機能と品質特性を評価します。

実運用に近い環境で、業務シナリオ、性能、セキュリティ、使用性などを確かめる場合があります。

結合とシステムテストの区切りは一律ではないため、対象範囲をテスト計画で確認してください。

受入テスト

受入テストは、利用者や発注側の立場から、業務要件や受入条件を満たしているかを確認する工程です。

実際の業務シナリオやデータを基に、運用へ移せるか、契約上の条件を満たすかを判断します。

開発チームが事前にテストしていても、受入側が確認すべき判断まで代行できるとは限りません。

実施者、承認者、判定基準、不合格時の扱いを決め、未解決事項がある場合は影響と対応予定を共有します。

テストの主な種類

テストの種類は、どの品質や目的を確かめるかによる分類です。

同じテスト工程の中でも、機能、非機能、修正確認、影響確認など複数の種類を組み合わせます。

機能テスト

機能テストは、システムが要求された処理を実行できるかを確認します。

ログイン、検索、登録、計算、通知などについて、入力や操作に対する出力と状態変化を仕様と比較します。

正常な操作だけではなく、不正な値、権限の不足、データが存在しない場合も対象です。

画面単位で確認を終えるのではなく、関連するAPIやデータ更新を含めた業務の流れで見る必要があります。

利用者の操作と内部の状態変化を対応させると、確認漏れを見つけやすくなります。

非機能テスト

非機能テストは、処理速度、安定性、セキュリティ、使用性など、機能の有無だけでは判断できない品質を評価します。

対象と目標値はシステムの用途やリスクによって異なるため、「性能を確認する」のような曖昧な条件では判定できません。

想定する利用者数、応答時間、稼働時間、復旧条件、利用環境などを事前に決めます。

本番に近い負荷や構成が必要な項目もあるため、環境差と未確認の範囲を結果に残してください。
Webアプリケーションのセキュリティテストでは、体系的な観点としてOWASPのガイドも参考になります。

出典：OWASP「Web Security Testing Guide」

確認テストと回帰テスト

確認テストは、見つかった不具合を修正した後に、同じ条件で問題が解消されたかを確かめるテストです。

修正対象の版、環境、入力、操作をそろえ、最初の不具合が再現しないことを確認します。

回帰テストは、変更によって既存機能へ予期しない影響が出ていないかを確認します。

すべてを毎回実行するとは限らず、変更箇所、依存関係、重要度を基に対象を選びます。

両者は目的が異なるため、修正箇所だけを再確認して回帰テストまで完了したと扱わないようにしましょう。

テスト設計の進め方

テスト設計では、要求や設計から確認条件を導き、実行できるテストケースへ具体化します。

根拠、期待結果、環境、担当、完了条件を結び付けると、実施者が変わっても判断をそろえやすくなります。

テストの根拠と条件を整理する

最初に、要件定義書、設計書、受入条件、法令や社内基準など、期待結果を判断する根拠をそろえます。

対象の版と変更範囲を確認し、重要な業務、失敗時の影響、過去の不具合から優先順位を決めます。

資料同士に矛盾がある場合は、テスト担当者の推測で正解を作らず、判断者へ確認してください。

どの設計がテストの根拠になるかは、システム開発の設計工程も参考になります。

仕様とテストケースを対応させ、未確認の要求を追える状態にすることが設計の土台です。

テストケースとデータを作る

テストケースには、前提条件、入力、操作、期待結果を記載し、実行後に合否を判断できる形にします。

代表値だけでなく、境界、無効な値、データの有無、権限、状態の組み合わせを検討してください。

テストデータは、本番の個人情報や機密情報を安易に複製せず、利用ルールに従って準備します。

ケースを増やすこと自体を目的にせず、どのリスクや条件を確認するための項目かを明確にします。

重複するケースはまとめ、重要な条件に抜けがないかをレビューします。

環境・担当・完了条件を決める

テスト計画では、対象の版、端末、OS、ブラウザ、ネットワーク、外部サービス、データなどの環境を決めます。

担当者、実施期間、不具合の連絡先、環境を変更できる権限も明確にしてください。

完了条件には、実施率だけでなく、重大な不具合の残数、未実施項目の影響、必要な承認などを含めます。

IPAのガイドでも、テスト見積りでは品質目標やテスト対象の特性を踏まえる必要性が示されています。

数字だけで完了を決めず、残るリスクを関係者が判断できる情報をそろえます。

出典：IPA「ソフトウェアテスト見積りガイドブック」

代表的なテスト手法

テスト手法は、確認条件やテストケースをどのように導くかを表します。

仕様を見る手法、コード構造を見る手法、経験を生かす手法を、対象とリスクに応じて組み合わせます。

ブラックボックステスト

ブラックボックステストは、内部のコード構造ではなく、仕様上の入力と出力に注目してテストケースを作る手法です。

同じ扱いになる値をグループに分ける同値分割や、境界の前後を確認する境界値分析などがあります。

条件の組み合わせを表にするデシジョンテーブルや、状態と遷移を整理する状態遷移テストも代表例です。

利用者から見える動作を確認しやすい一方、内部の未実行経路までは判断できません。

仕様の特徴に合う技法を選び、なぜその値を使うか説明できる状態にすることが大切です。

ホワイトボックステスト

ホワイトボックステストは、コードや制御の構造を基にテストケースを作る手法です。

命令や分岐など、どの構造を実行したかをカバレッジで確認し、通っていない経路を把握します。

カバレッジが高くても、要求の漏れや期待結果の誤りまで自動的に見つかるわけではありません。

数値を達成することだけを目的にせず、重要な処理、例外、到達しにくい条件を確認します。

ブラックボックスの観点と組み合わせることで、仕様と内部構造の両面を見られます。

経験ベースのテスト

経験ベースのテストは、担当者の知識、過去の不具合、似たシステムで起きた問題を基に確認箇所を考える手法です。

エラー推測や探索的テストなどがあり、文書だけでは表れにくい弱点を見つける助けになります。

一方で、個人の経験だけに頼ると観点が偏り、再現性も下がります。

チェックリスト、セッションの目的、実施記録を残し、仕様ベースや構造ベースの手法を補う形で使ってください。

ISTQBでは、ブラックボックス、ホワイトボックス、経験ベースを主要な技法の分類として整理しています。

出典：ISTQB「Certified Tester Foundation Level Syllabus v4.0.1」

結果を品質改善につなげる

テスト結果は、合否を記録するだけでなく、不具合の修正、残るリスク、次の開発で改善すべき点へつなげます。

再現可能な記録と影響確認を積み重ねることで、テスト経験を品質改善や案件選びにも生かせます。

不具合を再現できる形で記録する

不具合票には、対象の版、環境、前提条件、入力、操作、期待結果、実際の結果を記載します。

画面の画像やログを添える場合も、何が問題なのか、どの条件で起きたのかを文章で説明してください。

再現頻度、業務への影響、回避方法が分かれば、修正の優先順位を判断しやすくなります。

原因を推測で断定せず、確認できた事実と調査中の仮説を分けます。

再テストと影響確認を行う

修正版を受け取ったら、対象の版を確認し、不具合が起きた条件で確認テストを行います。

修正によって入力、データ、共通部品、外部連携へ影響が及ぶ場合は、関連機能の回帰テストも選びます。

再テストで別の問題が見つかったときは、元の不具合と同じ原因かを決めつけず、新しい事象として条件を整理します。

完了時には、実施した範囲、未実施の範囲、残る制約を共有してください。

修正確認と影響確認を分けて記録すると、リリース判断の根拠が明確になります。

テスト経験を案件選びに生かす

テスト経験は、「テストを担当した」だけでなく、工程、対象、種類、手法、成果物に分けて整理します。

たとえば、結合テストの設計、APIの確認、不具合分析、回帰テストの選定まで具体化すると、担当できる範囲が伝わります。

品質保証を専門にしたい場合は、QAエンジニアの役割と将来性も参考になります。

実際の募集で求められる工程やスキルを比べるなら、テスト・QAを含む案件一覧を確認してみてください。

自分の経験と次に広げたい範囲が合う案件を選ぶことが、キャリアをつなげる一歩になります。

工程・種類・手法を分けてテストを進めよう

システム開発のテストは、単体から受入までの工程、機能・非機能などの種類、テストケースを導く手法に分けると整理できます。

根拠、期待結果、環境、完了条件を明確にし、結果と残るリスクを関係者へ共有しましょう。