ソフトウェアテストを体系的に学びたい方へ
ソフトウェアテストと聞くと、完成した画面を操作してバグを探す作業を思い浮かべるかもしれません。もちろん不具合の発見は大切です。しかし、テストの役割はそれだけではありません。
要件や設計の矛盾に早い段階で気づくこと、確認できた品質の範囲を可視化すること、障害が起きたときの事業リスクを下げること、リリースしてよいかを関係者が判断できる情報を提供することも、ソフトウェアテストの重要な役割です。
そして、良いテストは思いついた操作を片端から試すことでもありません。仕様の区切り、値の境界、条件の組み合わせ、状態の変化、コードの分岐、過去の経験など、欠陥が潜みやすい場所に合わせてテスト技法を選びます。
この記事では、ソフトウェアテストの目的と全体像、代表的なテスト設計技法、技法の選び方を整理します。後半では、noteで公開している全10回の「ソフトウェアテスト技法」シリーズを、学びたい内容とおすすめの順序が分かる形で紹介します。
この記事は各テスト技法の地図にあたります。まず全体像をつかみ、実際のテスト対象に近い回へ進んでください。1つの技法ですべての欠陥を見つけられるわけではなく、目的とリスクに応じた組み合わせが必要です。
ソフトウェアテストとは、品質を評価してリスクを下げる活動
ISTQBのFoundation Levelシラバスでは、ソフトウェアテストを、欠陥を発見し、ソフトウェア成果物の品質を評価するための一連の活動として説明しています。対象は実行可能なプログラムだけではありません。要件、ユーザーストーリー、設計、コードなどもテスト対象になります。
テストには、実際にソフトウェアを動かす動的テストと、動かさずにレビューや静的解析を行う静的テストがあります。つまり「テスト＝完成後に操作する工程」と考えると、要件や設計の段階で防げた欠陥を見逃してしまいます。
代表的な目的を整理すると、次のようになります。
- 要件、設計、コードなどの成果物を評価する
- 失敗を発生させ、原因となる欠陥を見つける
- 必要な範囲を確認できているか把握する
- 品質不足によるリスクを減らす
- 指定された要件を満たしているか確認する
- 利用者や関係者のニーズを満たすか確認する
- 契約、法令、規制等への適合を確認する
- 品質と残存リスクを関係者へ伝え、意思決定を支える
テストレベルとテスト技法は別の軸で考える
テストを整理するときに混同しやすいのが、「どの範囲をテストするか」と「どうテストケースを作るか」です。
テストレベルは対象範囲を表す
一般的なテストレベルには、次のようなものがあります。
- コンポーネントテスト（単体テスト）：関数、クラス、モジュール等の小さな単位を確認する
- コンポーネント統合テスト：小さな構成要素同士の接続を確認する
- システムテスト：システム全体の機能・非機能要件を確認する
- システム統合テスト：外部システムやサービスとの連携を確認する
- 受入テスト：利用者や事業の要求を満たし、実際に受け入れられるか確認する
現場によって「結合テスト」の範囲や名称は異なります。言葉だけを合わせるのではなく、対象、目的、環境、責任者、開始・終了条件を明確にすることが大切です。
テスト技法はケースの導き方を表す
一方、テスト技法は、限られた時間で意味のあるテストケースを導くための考え方です。同値分割法や境界値分析は、単体テストでもシステムテストでも利用できます。
「単体テストだからホワイトボックス」「受入テストだからブラックボックス」と機械的に決めるのではなく、そのレベルでどのリスクを確認したいかに応じて技法を選びます。
ブラックボックステストとホワイトボックステストの違い
テスト技法を理解する入口になるのが、ブラックボックスとホワイトボックスという視点の違いです。
ブラックボックステストは外から見える振る舞いを確認する
ブラックボックステストは、内部のコード構造ではなく、仕様や利用者から見える入力・出力に基づいてテストケースを設計します。仕様ベーステストとも呼ばれます。
たとえば年齢が18歳以上なら申込みできる画面をテストするとき、実装コードを見なくても、17歳、18歳、19歳という値を試す意味を考えられます。利用者から見た正しさを確認しやすく、実装方法が変わっても再利用しやすい点が特徴です。
ホワイトボックステストは内部構造を確認する
ホワイトボックステストは、コードの命令、分岐、条件、経路などの内部構造に基づいてテストケースを設計します。構造ベーステストとも呼ばれます。
先ほどの申込み処理に、年齢だけでなく会員区分、地域、例外処理の分岐があれば、それぞれの経路が実行されたかを確認します。仕様書からは見えにくい実装上の抜けを発見しやすい一方、コードを網羅しても、そもそもの仕様漏れは検出できない場合があります。
この2つは競合する方法ではなく、補い合うものです。外から見た要求の正しさと、内側の構造の確認を組み合わせることで、異なる種類の見落としを減らせます。
「ブラックボックス」：仕様・入力・出力・利用者視点
「ホワイトボックス」：コード・分岐・条件・構造視点
代表的なソフトウェアテスト技法
ここからは、シリーズで扱う代表的な技法を短く整理します。
同値分割法：同じ扱いになるグループへ分ける
入力や出力の範囲を、システムが同じように扱うと考えられるグループ、つまり同値パーティションへ分けます。各グループから代表値を選ぶことで、すべての値を試さずに意味のある範囲を確認できます。
たとえば「1〜100文字を受け付ける入力欄」なら、0文字、1〜100文字、101文字以上というグループを考えます。有効な値だけでなく、無効な値のグループも忘れないことが重要です。
境界値分析：切り替わる直前と直後を狙う
欠陥は、範囲の中央よりも境界付近で生じやすい傾向があります。先ほどの1〜100文字なら、0、1、2、99、100、101文字のように、境界とその近くを確認します。
同値分割法でグループを作り、その境界を境界値分析で詳しく調べる、という組み合わせが基本です。
デシジョンテーブル：条件の組み合わせを整理する
複数の条件によって結果が変わる処理では、条件と期待結果を表にします。会員区分、購入金額、キャンペーン期間で割引が変わる、といった場面に向いています。
すべての組み合わせを実行できない場合でも、まずルールを表にすることで、仕様の矛盾、未定義の組み合わせ、不要な重複が見えやすくなります。
状態遷移テスト：現在の状態と出来事の組み合わせを見る
同じ操作でも、処理前の状態によって結果が変わる機能に使います。ログイン、注文、予約、申請、ワークフロー、アカウントロックなどが代表例です。
「未申請→申請中→承認済み」のような有効な遷移だけでなく、承認済みから未申請へ戻せるのか、といった無効な遷移もテスト対象になります。
カバレッジ：コードのどこを実行したか測る
ホワイトボックステストでは、命令、分岐、条件などがどの程度実行されたかをカバレッジとして確認します。高い数値は未実行の構造を減らす助けになりますが、アサーションが適切か、仕様を満たしているか、重要な入力を試したかまでは保証しません。
「カバレッジ100％だからバグがない」と判断せず、どの基準で100％なのか、期待結果が妥当かを確認します。
探索的テストとエラー推測：経験を仮説へ変える
探索的テストは、学習、設計、実行を並行して進めるアプローチです。エラー推測は、過去の欠陥や技術的な経験から、壊れやすい場所を予測してテストします。
体系的な技法では拾いにくい問題を見つけられる一方、思いつき任せにすると再現性と説明責任が弱くなります。目的、時間、着眼点、結果を記録し、他の技法を補う形で使います。
テスト技法の選び方
技法名から選ぶのではなく、テスト対象の特徴から考えると判断しやすくなります。
- 入力範囲が広い：同値分割法でグループを作る
- 上限、下限、期限、閾値がある：境界値分析を加える
- 複数条件で結果が変わる：デシジョンテーブルで組み合わせを整理する
- 処理履歴や現在状態で結果が変わる：状態遷移テストを使う
- コードの分岐や例外経路を確認したい：ホワイトボックステストとカバレッジを使う
- 仕様化しにくい使い勝手や未知の欠陥を探したい：探索的テストやエラー推測を加える
- 誰が実行しても同じ判断ができるようにしたい：テスト仕様書へ前提、操作、期待結果を明記する
実際の機能には複数の特徴があります。会員登録画面なら、年齢に境界値分析、会員種別と地域の組み合わせにデシジョンテーブル、メール認証前後の動作に状態遷移テストを使う、といった組み合わせが自然です。
テストケースには何を書けばよいか
技法で入力値を選んでも、テストケースの記述が曖昧では実行者によって結果が変わります。最低限、次の項目を整理します。
- テストケースID
- テストの目的・観点
- 対象機能・要件との対応
- 前提条件
- 使用する環境とデータ
- 操作手順
- 入力値
- 期待結果
- 実行結果
- 合否
- 証跡
- 不具合票との関連
期待結果は「正しく表示される」では不十分です。何が、どこに、どの値で、どの状態として表示されれば合格なのかを書きます。
ただし、すべての案件で巨大な表を作ればよいわけでもありません。自動テスト、チェックリスト、探索的テストのセッション記録など、目的に合う形式を選びます。重要なのは、要求とのつながり、再現性、判定可能性、保守しやすさです。
ソフトウェアテスト技法シリーズ全10記事の読み方
noteの「ソフトウェアテスト技法」シリーズは、テストの目的から始まり、技法を1つずつ学び、最後に実務で組み合わせる全10回の構成です。
各記事は前半無料・後半有料で公開されています。価格や公開範囲は、各note記事のページで最新情報をご確認ください。本記事では有料部分を転載せず、各回で学べるテーマと向いている読者を紹介します。
TEST-01：テストの目的と全体像をつかむ
【TEST-01】ソフトウェアテストの全体像——テストは「バグ探し」だけではない
テストが果たす役割、V字モデル、単体・結合・システム・受入テストの違いを整理する導入編です。「テストは開発の最後に行う作業」と考えていた方や、工程ごとの目的を見直したい方に向いています。
TEST-02：外側と内側の2つの視点を理解する
【TEST-02】ブラックボックステストとホワイトボックステストの違い——視点を変えると見えるテストケースが変わる
仕様や入出力から考えるブラックボックステストと、コード構造から考えるホワイトボックステストを比較します。TEST-03以降の個別技法を学ぶ前に、テストケースを導く視点の違いを整理したい方におすすめです。
TEST-03：同値分割法で入力を効率よく選ぶ
【TEST-03】同値分割法とは？入力パターンを効率よく絞り込むテスト設計技法
膨大な入力候補を、同じ扱いになると考えられるグループへ分け、代表値を選ぶ技法を学びます。正常値ばかり試してしまう方や、テスト件数を減らす根拠を説明したい方に適しています。
TEST-04：境界値分析で切り替わりを狙う
【TEST-04】境界値分析とは？同値分割法とセットで使う境界テストの技法
上限・下限・期限など、仕様が切り替わる境界とその前後を確認する技法を扱います。「以上」と「超える」、「未満」と「以下」の実装ミスや、配列・文字数の端で起こる欠陥を狙いたい方におすすめです。
TEST-05：デシジョンテーブルで複数条件を整理する
【TEST-05】デシジョンテーブルとは？複数条件の組み合わせを漏れなく整理する技法
複数条件と期待結果を表にして、未定義・矛盾・重複を見つけやすくします。料金、権限、割引、承認ルールなど、if文が増えやすい処理のテスト設計に向いています。
TEST-06：状態遷移テストで履歴のある処理を検証する
【TEST-06】状態遷移テストとは？「今どの状態か」で結果が変わる処理を漏れなく検証する
現在の状態とイベントによって、次の状態や結果が変わる処理を整理します。ログイン、注文、予約、申請、ワークフローなど、操作順序による不具合を見つけたい方に適しています。
TEST-07：コードカバレッジを正しく読む
【TEST-07】ホワイトボックステストとは？命令網羅・分岐網羅・条件網羅の違いとカバレッジの読み方
命令網羅、分岐網羅、条件網羅の違いと、カバレッジ数値の意味を学びます。自動テストのカバレッジを上げているものの、何を確認できたのか説明しにくい開発者におすすめです。
TEST-08：探索的テストとエラー推測を再現可能にする
【TEST-08】探索的テストとエラー推測とは？体系的な技法だけでは見つからないバグの探し方
テスト対象から学びながら次の仮説を立てる探索的テストと、経験から欠陥を予測するエラー推測を扱います。「自由に触って確認する」状態から、目的と記録のある調査へ変えたい方に向いています。
TEST-09：読み手が判定できるテスト仕様書を書く
【TEST-09】テスト仕様書の書き方とは？読み手に伝わる文書構成とテンプレート
テストケースID、前提条件、手順、入力、期待結果、証跡などを整理します。書いた本人しか実行できない仕様書や、「問題なく動くこと」のように判定できない期待結果を改善したい方におすすめです。
TEST-10：技法を組み合わせて実務へつなげる
【TEST-10】ソフトウェアテスト技法とは？全10回シリーズ完結・実践統合ガイド
シリーズ全体を振り返り、テスト対象の特徴から技法を選び、組み合わせる考え方を整理する完結編です。一通り学んだ後の復習や、実案件に適用する前の確認に向いています。
目的別に選ぶなら、どの記事から読むべきか
初めてテスト設計を担当する方
TEST-01で目的とテストレベルを確認し、TEST-02でブラックボックスとホワイトボックスの視点を整理します。その後、TEST-03の同値分割法、TEST-04の境界値分析へ進むと、入力値を選ぶ基本がつかみやすくなります。
仕様の条件が複雑で漏れが起きる方
TEST-05のデシジョンテーブルとTEST-06の状態遷移テストがおすすめです。条件の組み合わせと、操作前の状態を分けて整理すると、複雑さの正体が見えやすくなります。
自動テストを書いている開発者
TEST-07でカバレッジを確認しつつ、TEST-03〜06のブラックボックス技法も組み合わせます。コードを通ったことと、利用者の要求を確認したことは同じではありません。
テストが担当者の経験だけに依存している現場
TEST-08で経験を仮説として活かす方法を学び、TEST-09で目的、手順、期待結果、証跡を共有できる形にします。個人の感覚を捨てるのではなく、他の人が再現・評価できる状態へ変えます。
シリーズを実案件へ適用したい方
TEST-10で全体を統合し、対象機能のリスクから必要な技法を選びます。すべての技法を毎回使うのではなく、今回の機能で壊れやすい場所を説明できる組み合わせにします。
- ラベル①TEST-01で目的とレベル
- ラベル②TEST-02で視点
- ラベル③TEST-03〜06で仕様ベース技法
- ラベル④TEST-07〜08で構造・経験ベース技法
- ラベル⑤TEST-09で文書化
- ラベル⑥TEST-10で統合
ソフトウェアテストとテスト技法の要点
- ソフトウェアテストは、欠陥発見だけでなく品質評価とリスク低減、意思決定支援を行う活動
- テスト対象には、実行可能なソフトウェアだけでなく要件、設計、コード等も含まれる
- テストレベルは「どの範囲を確認するか」、テスト技法は「ケースをどう導くか」を表す
- ブラックボックステストは仕様と外部動作、ホワイトボックステストは内部構造に着目する
- 同値分割法は入力をグループ化し、境界値分析は切り替わりの前後を狙う
- デシジョンテーブルは条件の組み合わせ、状態遷移テストは状態とイベントを整理する
- カバレッジ100％でも、仕様漏れや期待結果の誤りがないとは限らない
- 探索的テストとエラー推測は、体系的な技法を補う形で目的と記録を持って使う
- テスト仕様書は、第三者が同じ条件で実行し、合否を判断できる内容にする
ソフトウェアテストに関するよくある質問
- Qテストケースは多いほど品質が上がりますか
- A
単純に件数を増やせばよいわけではありません。同じ意味のケースを繰り返すより、重要なリスク、境界、条件、状態、コード構造を根拠に選んだケースのほうが役立ちます。未確認の範囲も明示します。
- Q同値分割法と境界値分析はどちらを使いますか
- A
通常は組み合わせて使います。同値分割法で同じ扱いになるグループを整理し、境界値分析でグループが切り替わる値とその近くを詳しく確認します。
- Qブラックボックステストだけでは不十分ですか
- A
利用者から見た要求を確認するうえで重要ですが、仕様書に表れない内部分岐や例外経路を見逃す場合があります。リスクに応じてホワイトボックステスト、静的テスト、経験ベース技法等と組み合わせます。
- Qコードカバレッジ100％ならテストは十分ですか
- A
十分とは限りません。どのカバレッジ基準か、期待結果を正しく検証しているか、仕様や利用者ニーズを満たすかも確認が必要です。カバレッジはテストの十分性を考える材料の1つです。
- Q探索的テストはテスト仕様書が不要という意味ですか
- A
いいえ。詳細な手順を事前固定しない場合でも、目的、範囲、時間、着眼点、実施内容、発見事項を記録できます。再現性や説明責任が必要な部分は、適切な文書や自動テストで補います。
自分のテスト対象に近い1記事から始めよう
ソフトウェアテストの技法は、名前を覚えるためではなく、限られた時間の中で欠陥が潜みやすい場所を考え、説明できるテストケースへ変えるためにあります。
初めて学ぶ方はTEST-01から順に、すでに実務で困りごとがある方は、入力値ならTEST-03・04、複数条件ならTEST-05、状態を持つ処理ならTEST-06、カバレッジならTEST-07、仕様書ならTEST-09から始めてください。最後にTEST-10で技法を組み合わせると、それぞれの知識を実案件へつなげやすくなります。
参考情報
以下の情報を2026年9月12日に確認しました。
- ISTQB Certified Tester Foundation Level（CTFL）v4.0
- ISTQB Certified Tester Foundation Level Syllabus v4.0.1
- JSTQB Foundation Levelシラバス Version 4.0
- ISO/IEC/IEEE 29119 series
ISTQBはInternational Software Testing Qualifications Boardの登録商標です。
