Tsuzura

テストの種類と選び方

単体・結合・E2E・受入テストの違いを整理し、変更範囲とリスクから必要なテストを選ぶ方法を解説します。

公開日
更新日

AIに「テストも書いて」と頼むだけでは、何を確かめ、何を未確認のままにするかは決まりません。単体テスト（一つの部品を切り出して行うテスト）が通っても、データを保存する仕組みや別サービスとの接続は未確認かもしれません。E2Eテスト（操作の開始から完了まで一連の経路を通すテスト）が通っても、すべての入力条件、性能、安全性まで確認できたとは限りません。

先に決めるのはテストコードではなく、確認する範囲、目的、条件、期待する結果です。そのうえで、一つの変更に必要なテストを組み合わせます。

この記事は、要件と受入条件を決め、一件分の実装タスクを用意した人を対象にしています。読み終えると、テストの名称を五つの判断軸で区別し、一つの機能についてのテスト計画と、AIへ渡す確認事項を作れます。特定のテストツールの操作、テストコードの書き方、変更のたびに自動で確認する仕組みの設定、公開手順は扱いません。

テストで分かること、分からないこと

ソフトウェアテストは、要件、設計、コード、動作などを確認し、欠陥を見つけ、品質を評価する活動です。実際の結果を期待する結果と比べる動的なテストだけでなく、要件やコードを実行せずに確認するレビューや静的解析も含まれます。

ISTQB Foundation Level Syllabus v4.0.1は、テストによって欠陥の存在は示せても、欠陥がないことは証明できないと説明しています。入力、状態、環境のすべての組み合わせを試すことも、単純な対象を除けば現実的ではありません。

したがって、テストが通ったときに言えるのは、実行した条件では実際の結果が期待する結果と一致した、ということです。次のことまで自動的に保証するわけではありません。

  • テストしていない条件にも欠陥がない
  • 期待する結果そのものが正しい
  • テストコードが意図した条件を正しく確認している
  • テスト環境と実際に使う環境が同じである
  • 性能、セキュリティ、アクセシビリティ、使いやすさなども確認済みである
  • 利用者や責任者が要件を満たしたと判断した

「テスト済み」とだけ記録せず、何を、どの条件で、どの方法で確認したのかを残します。未実行の確認と未確認の範囲も、合格した結果から分けて記録します。

テストの種類を五つの判断軸で整理する

テストの名称が分かりにくい理由は、異なる分類軸の言葉が一緒に並べられやすいからです。単体テストは確認する範囲を、回帰テストは確認する目的を、自動テストは実行手段を表します。この三つから一つだけを選ぶわけではありません。

軸 決める問い 主な区分
対象範囲 どこまでを一緒に確認するか 単体・コンポーネント（独立して確認する部品）、コンポーネント結合、システム、システム結合、受入。E2Eは広い利用経路を表す呼称として扱う
確認目的 何を確かめるか 機能、非機能、修正確認、回帰
テスト技法 どの条件や入力を選ぶか 仕様を基にする方法、コード構造を基にする方法、経験を基にする方法
確認形態 対象を実行して確かめるか 静的、動的
実行手段 人が行うか、決めた手順をツールが行うか 手動、自動

ISTQB Foundation Level Syllabus v4.0.1も、対象範囲を表すテストレベルと、品質上の目的を表すテストタイプを分けています。多くのテストタイプは、複数のテストレベルで実施できます。この記事では、実際の計画へ使えるよう、技法、確認形態、実行手段を加えた五つの判断軸で整理します。

一つのテストは、五つの判断軸を組み合わせて表せます。名称だけで判断せず、「どの範囲で」「何を」「どの条件で」「対象を動かすか」「人とツールのどちらが行うか」を確認します。この記事では、各軸の意味を確認した後、必要な組み合わせと記録方法を決めます。

確認する範囲を選ぶ

対象範囲は、どこまでの部品やシステムを一緒に動かすかを表します。広いテストほど優れているわけではありません。範囲が変われば、見つけやすい問題、実行時間、問題箇所の絞りやすさも変わります。

ISTQB CTFL v4.0.1は、コンポーネント、コンポーネント結合、システム、システム結合、受入の五つをテストレベルとして示しています。

対象範囲 主に確認すること それだけでは分からないこと
単体・コンポーネント 一つの関数、クラス、モジュールなどのロジックと状態変化 実際の依存先との接続、構成済みシステム全体の動作
コンポーネント結合 同じシステム内にある部品間の接続とデータの受け渡し 外部システムとの接続、利用経路全体、受入可否
システム 構成済みシステム全体の機能と、対象に含めた品質特性 対象外の外部システム、未実行の経路、利用者の受入判断
システム結合 別システムや外部サービスとのインターフェース 接続していない部分、すべての障害条件、品質全体
受入 利用者や関係者の要求、業務上の必要、利用開始の準備 内部の全分岐、要件にない条件、別目的の品質確認
E2E 開始から目的の完了まで、複数の層や依存先を通る重要な経路 全経路の網羅、内部の細かな分岐、問題箇所の特定

単体・コンポーネントテスト

一つの関数、クラス、モジュールなど、単独で扱える部分を確認します。条件分岐、計算、状態変化、異常時の処理を小さい範囲で確かめやすく、問題が起きた場所も絞りやすい方法です。

依存先（その部品が利用するデータ保存先や別サービス）を置き換えて確認する場合、実際の接続先や設定との食い違いは検出できません。単体テストだけでは、接続後の動作は確認済みになりません。

結合テストとシステムテスト

結合テストは、境界を越えたときの呼び出し、データ形式、エラー、状態の受け渡しを確認します。「結合テストをする」とだけ書かず、同じシステム内のどの部品間か、どの外部システムとの間かを記録します。

システムテストは、構成済みのシステム全体を対象にします。個々の部品ではなく、システムとして要求された機能や品質を確かめます。使用する環境、データ、外部依存を明記しなければ、「システム全体」の範囲は曖昧なままです。

既存コードのどこが一つの部品で、どこが依存境界か分からない場合は、先にコードアーキテクチャを確認します。フォルダ名だけで境界を決めず、実際の責務と依存関係を追います。

E2Eテストと受入テスト

E2Eは、開始から目的の完了までの一連の経路を、複数の層や依存先にまたがって確認する実務上の呼称です。ISTQB CTFL v4.0.1が列挙する正式な五つのテストレベルに、E2Eという第六のレベルはありません。本記事では、広いテスト範囲を表す呼称として扱います。

Google Testing Blogの「How Much Testing is Enough?」は、複数の機能を通る重要な利用経路へE2Eテストを使う考え方を示しています。実際の利用条件に近づけやすい一方、依存先が増えるほど実行時間、保守負担、不安定さも増えます。すべての組み合わせをE2Eで確認するのではなく、失敗した場合の影響が大きい経路を選びます。

受入テストは、利用者や関係者の要求を満たし、利用開始へ進める状態かを確認します。E2Eは経路の広さ、受入は要求を満たしたかという判断の目的を表すため、同じ意味ではありません。E2E形式で受入条件を確認する場合もあれば、人の確認やE2E以外のテストを受入判断に使う場合もあります。

確認目的とテスト技法を選ぶ

確認目的は何を確かめるか、テスト技法はどの条件を選ぶかを表します。同じ対象範囲でも、この二つによってテストは変わります。

機能テストと非機能テスト

機能テストは、指定された動作をするかを確認します。入力に対する出力、状態の変化、処理の可否などが対象です。

非機能テストは、どの程度の品質で動くかを確認します。性能、互換性、使いやすさ、信頼性、セキュリティ、保守性などが含まれます。機能と非機能は、単体、結合、システムなど複数の範囲へ適用できます。非機能テストは、実装後にシステム全体で一度だけ行う確認に限りません。

非機能品質には、先に測定条件と合格基準が必要です。「速い」「安全」といった言葉だけでは合否を決められません。性能、セキュリティ、アクセシビリティなどの詳しい基準と実施方法は、それぞれの専門的な確認へ分けます。

Web実装でSSRF、CSRF、インジェクションなどの防御を確認する場合は、Web脆弱性の防ぎ方を使います。許可範囲を決め、診断結果を修正と再診断へつなぐ場合は、脆弱性診断の進め方へ進みます。

修正確認テストと回帰テスト

不具合を修正した後には、二つの目的を分けます。

目的 確認する問い
修正確認 見つかった不具合は直ったか
回帰 変更によって既存の動作を壊していないか

修正確認では、元の不具合を再現した条件をもう一度確かめます。回帰では、変更の影響が及ぶ可能性のある同じ部品、別の部品、接続先を確認します。回帰テストは繰り返し実行するため自動化の候補になりますが、「回帰」という名称自体が自動実行を意味するわけではありません。常にすべての既存テストを実行するという意味でもなく、変更影響とリスクから範囲を決めます。

テスト条件を作る三つの技法

テスト技法は、どの入力、状態、処理経路を選ぶかを決める方法です。ISTQB CTFL v4.0.1のテスト技法は、外から見える仕様を基にする方法、コード内部の構造を基にする方法、経験を基にする方法へ整理しています。

技法 条件を作る基準 主な使い方
仕様を基にする 要件、受入条件、外から見える動作 入力の分類、最小値・最大値等の境界、条件の組み合わせ、状態変化を確認する
コード構造を基にする 文、分岐、処理経路 実装内の文や分岐が実行されたかを確認する
経験を基にする 過去の不具合、利用場面、確認中に得た情報 仕様と構造だけでは見つけにくい問題を探す

探索的テストは、対象を学びながら、テストの設計、実行、結果の評価を進める経験ベースの技法です。仕様が少ない場合や、ほかの技法で作ったテストを補う場合に使えます。無計画な操作とは区別し、確認する目的、時間、対象範囲と結果を記録します。

コードを通った割合が高くても、期待結果が正しいことや、実行した箇所に欠陥がないことまでは証明しません。カバレッジは未実行の構造を見つける材料として使い、単独の品質判定にはしません。

実行方法を選ぶ

静的か動的かと、手動か自動かは別の判断です。

静的テストと動的テスト

ISTQB CTFL v4.0.1の静的テストでは、対象を実行せずに確認します。要件、設計、コードのレビューや、ツールによる型検査、Lint（記述ルールや問題の候補を調べる検査）、静的解析などが含まれます。矛盾、不足、未定義の参照、到達しない処理、規約違反、インターフェースの不整合などを、実行前に見つけられる場合があります。

動的テストは、対象を実行し、実際の結果と期待する結果を比べます。実行時の振る舞い、部品間の接続、環境に依存する問題を確認します。静的テストと動的テストは、どちらか一方を選んで置き換えるものではありません。

手動 自動
静的 要件・設計・コードのレビュー 型検査、Lint、静的解析
動的 操作による受入確認、探索的テスト 自動化した単体、結合、システム、E2Eテスト

手動テストと自動テスト

自動化は、同じ確認を繰り返す、結果を機械的に判定する、変更後に早く結果を得る場合に向いています。一方で、テストコードと実行環境の作成・保守が必要です。要件が変わればテストも更新しなければなりません。不安定なテストを増やすと、失敗が製品の問題かテストの問題かを調べる負担も増えます。

人による判断、見た目、使いやすさ、未知の挙動の探索を含む確認は、手動で行う意味があります。自動化率の高さを品質の指標にはせず、反復頻度、判定の明確さ、保守負担、人の判断が必要かを見て選びます。

必要なテストを組み合わせる

すべての変更へ同じ種類と数のテストを付ける必要はありません。テスト名から選ぶのではなく、次の順で決めます。

選択の順序

  1. 期待する結果を決める。 要件と受入条件から、何が起きれば合格かを記録します。現在の実装結果を、そのまま期待結果として写しません。
  2. リスクを決める。 問題が起こる可能性と、起きた場合の利用者、データ、費用、業務への影響を確認します。法令、契約、組織規則で必須の確認は、この評価だけで外しません。
  3. 問題が現れる範囲を選ぶ。 一つの部品内部、部品間、外部サービスとの間、構成済みシステム、重要な利用経路、受入判断のどこで確認すべきかを決めます。
  4. 確認目的を加える。 新しい機能、非機能品質、不具合の修正確認、周辺への回帰のうち、必要な目的を選びます。
  5. 条件を作る技法を選ぶ。 仕様、コード構造、経験のどれから条件を作るかを決めます。一つに限定する必要はありません。
  6. 各テストの条件を書く。 前提条件、入力、操作、そのテストで期待する結果を記録します。機能全体の受入条件と、各テストで確認する期待結果を区別します。
  7. 確認形態、実行手段、証拠を決める。 静的・動的、手動・自動を別々に選び、実行環境、コマンド、実結果、記録の場所を決めます。

ISTQBのリスクベースドテストは、問題の発生可能性と影響を評価し、その結果をテスト範囲、レベル、タイプ、技法、網羅度、工数、優先順位へ反映します。リスクが高い箇所ほど、範囲、条件、確認方法を増やす候補になります。ただし、テスト以外の設計変更、権限制御、監視、専門家の確認が必要になる場合もあります。

テストピラミッドを固定比率にしない

テストピラミッドは、一般に小さく速いテストを多くし、広いE2Eテストを絞る考え方を示します。ただし、層の数と名称は一定ではなく、すべてのシステムに共通する比率も決まりません。

Googleの「SMURF: Beyond the Test Pyramid」は、テスト構成を次の五点で比較する方法を示しています。

  • 速度：結果を得るまでの時間
  • 保守性：原因調査と更新にかかる負担
  • 資源利用：CPU、メモリ、保存領域などの使用量
  • 信頼性：製品に実際の問題があるときだけ失敗し、同じ状態なら結果が安定するか
  • 忠実度：実際に使う環境と条件へどこまで近いか

単体テストは速度と問題箇所の絞りやすさを得やすく、結合やE2Eは実際の接続と環境へ近づけやすい一方、実行と保守の負担が増えます。五点のどれを優先するかは、システムとリスクによって変わります。70対20対10などの数字を、そのまま合格基準にはしません。

一つの機能についてテスト計画と結果を分けて記録する

実行前の計画と、実行後に分かる結果を同じ欄へ混ぜません。最初に、元の要件とリスク、各テストの条件、実行方法を記録します。複数のテストが必要なら、テスト1のまとまりを繰り返します。

# 実行前のテスト計画

## 元の判断
- 実装タスク:
- 対応する要件・受入条件:
- 確認するリスクと、問題が起きた場合の影響:

## テスト1
- ID:
- 対象範囲:
- 確認目的:
- 使用する技法:
- 確認形態（静的・動的）:
- 実行手段（手動・自動）:
- 前提条件:
- 入力・操作:
- このテストで期待する結果:
- 使用する環境、データ、接続先:
- 実行するコマンドまたは手順:
- 証拠を保存する場所:
- 結果を確認する人:

実行後は、計画を書き換えず、結果を別に記録します。未実行は合格と分け、理由と残る範囲を残します。

# 実行後の記録

## テスト1
- 実行日時と実行した人・ツール:
- 実際に使った環境、データ、接続先:
- 実行したコマンドまたは手順:
- 実際の結果:
- 判定（合格・不合格・未実行）:
- ログ、画面、記録の場所:
- 未実行または未確認の範囲と理由:
- 残るリスク:
- 確認者と確認日:

この記録は、一つの機能向けに簡略化した本記事の書式です。規格に準拠したテスト計画書を置き換えるものではありません。

AIへ渡して結果を確認する

テスト生成とコマンド実行の機能を備え、コード一式、実行環境、必要な権限へアクセスできるコーディングAIは、テストケースやテストコードの候補を作り、テストを実行できます。しかし、「テストを提案した」「テストコードを書いた」「実行した」「合格した」「受入条件を満たした」は別の状態です。

状態 確認する証拠
テストを提案した 前提、入力、操作、期待結果が書かれている
テストコードを書いた 意図した条件で失敗と成功を判定する内容になっている
テストを実行した 実行した環境、コマンド、対象、ログがある
テストが合格した 実結果が期待結果と一致し、無効化や除外がない
受入条件を満たした 要件に対応する結果を、決めた担当者が確認している

OpenAIのCodex Prompting Guidanceは、期待する結果、前提情報、境界、出力、検証方法を必要に応じて伝えるよう案内しています。AnthropicのClaude Code Best Practicesも、テスト、ビルド、Lintなど、合否を確認できる方法を与え、成功したという説明ではなく証拠を示させることを勧めています。どちらも各製品の案内であり、すべてのAIが同じ機能と権限を持つという意味ではありません。

次の空欄を、一件分のテスト計画からAIへ渡せます。

# テスト依頼

## 対象
- 実装タスク:
- 要件・受入条件:
- 変更された範囲:
- 変更してはいけない範囲:

## 確認する内容
- 対象範囲:
- 確認目的:
- 使用する技法:
- 前提条件、入力、操作:
- 期待する結果:
- 未確認にする範囲:

## 実行
- 静的・動的:
- 手動・自動:
- 使用する環境とデータ:
- 実行するコマンドまたは手順:
- 結果を保存する場所:

## 返答に含める内容
- 追加・変更したテストと、その理由:
- 実行したコマンド、対象、実結果:
- 失敗した確認:
- 実行できなかった確認と理由:
- 追加した仮定と、残るリスク:

AIが返した後、人は次を確認します。

  • 期待結果が、現在の実装ではなく要件と受入条件に対応している
  • 期待する条件を満たさない場合に、そのテストが失敗を報告する
  • テストが無効化、除外、途中終了されていない
  • 依存先の置き換えによって、重要な境界が未確認になっていない
  • 実行した環境、コマンド、結果が記録されている
  • 実行できなかった確認と未確認の条件が分かる

テスト結果とは別に、AIが作ったコードとテストが要件、意図、既存の設計に合うかを人が確認します。GitHubのAI生成コード・レビューガイドも、機能確認の後に、正しい問題を解いているか、既存の設計へ合うかを確認するよう案内しています。対象版、差分、検証結果、依存関係をまとめて確認する手順は、AI生成コードをレビューするで扱います。

次へ進むか判断する

テスト工程の完了は、「すべて安全」と言える状態ではありません。確認した範囲、結果、未確認の範囲を説明し、次の判断へ渡せる状態です。

状態 次の行動
期待結果や受入条件が決まっていない 要件へ戻る
変更境界が分からない コード構成と依存関係を調査する
必要な環境や権限がなく実行できない 未実行として記録し、実行できる担当者または環境へ渡す
テストが不具合を検出できない、または不安定である テスト条件、実装、環境を見直す
性能、セキュリティ、アクセシビリティ、復旧等の影響がある 数値基準と専門的な確認を追加する
計画した確認が合格し、未確認範囲と残るリスクを担当者が把握した 受入結果を記録し、公開前の確認へ進む

次へ進む前に、少なくとも次の五点を説明できるか確認します。

  • 各テストが、どの要件またはリスクを確認しているか
  • 対象範囲、確認目的、技法、確認形態、実行手段を区別して選んだか
  • 実行した環境、条件、期待結果、実結果が残っているか
  • 実行できなかった確認と未確認の範囲が残っているか
  • 誰が結果を確認し、受け入れたか

説明できない項目があれば、次へ進む判断に必要な情報が不足しています。必要なテストを増やす、条件を直す、要件へ戻る、専門的な確認へ渡す、のいずれかを選びます。

出典