🗂

【JSTQB Foundation Level 対策】第1章「テストの基礎」解説！

に公開
JSTQB
idea

こんにちは！今回はJSTQB Foundation Level シラバスV4.0の第1章「テストの基礎」を、シラバスを丸ごと網羅しながら、できるだけわかりやすく解説していきます(^^)

第1章はすべての土台となる章なので、ここをしっかり理解しておくと後の章もグッとスムーズになります。ぜひ最後まで読んでみてください！

📋 この記事でわかること

  • ソフトウェアテストとは何か、なぜ必要なのか
  • テストとデバッグの違い
  • QA（品質保証）とQC（品質コントロール）の違い
  • エラー・欠陥・故障・根本原因の関係
  • テストの7原則
  • テスト活動の流れとテストウェア
  • テスト担当者に求められるスキルと独立性

1. ソフトウェアテストとは何か？

テストの定義

ソフトウェアテストとは、一言でいうと「欠陥を発見し、ソフトウェアアーティファクトの品質を評価するための一連の活動」です。

ここで「アーティファクト」という言葉が出てきましたが、これは要件定義書・設計書・ソースコードなど、開発の過程で生み出される成果物のことです。テストの対象はコードだけではありません！

よくある誤解その① 「テスト＝テスト実行だけ」ではない！

テストというと「プログラムを動かして確認する」というイメージが強いですよね。でも実際には、テスト計画を立てたり、テスト設計をしたり、結果を分析したりと、もっと幅広い活動が含まれます。

よくある誤解その② 「テスト＝検証（Verification）だけ」ではない！

テストには2種類の確認があります。

💡 具体例で理解しよう！

要件定義書に「ボタンを押したら3秒以内に画面遷移する」と書いてあって、実際に3秒以内に遷移したとします。

  • 検証（Verification）：「仕様書通りに3秒以内で動いた、OK！」
  • 妥当性確認（Validation）：「でも、ユーザーは3秒でもストレスを感じている…本当にこれで満足している？」

仕様を満たしていても、ユーザーが満足しないことがあります。だからこそ、両方の視点でテストすることが大切なんです。

動的テストと静的テスト

テストには実行を伴うかどうかで2つに分かれます。

種類 内容 例
動的テスト ソフトウェアを実際に動かして確認する 機能テスト、負荷テストなど
静的テスト ソフトウェアを動かさずに確認する コードレビュー、静的解析ツールの活用など

🧩 理解度チェック①

Q. ソフトウェアテストの説明として正しいものはどれか？

  • a) テストとはソフトウェアを実行して結果を確認する活動のみを指す
  • b) テストとは欠陥を発見し、ソフトウェアアーティファクトの品質を評価するための一連の活動である
  • c) テストでは検証のみを行い、妥当性確認は含まれない
  • d) テストの対象はソースコードのみである
答えを見る

答え：b)

a) は誤り：テストはテスト実行だけでなく、計画・設計・分析なども含む幅広い活動です。
c) は誤り：テストには検証（仕様通りか）だけでなく、妥当性確認（ユーザーニーズを満たすか）も含まれます。
d) は誤り：テストの対象はソースコードだけでなく、要件定義書や設計書などのアーティファクト全般です。

2. テストの目的

シラバスには典型的なテスト目的として以下が挙げられています。これは重要なので、ざっくりと頭に入れておきましょう。

  1. 要件・設計・コードなどの作業成果物を評価する
    → コードを動かす前の段階でも、設計書や要件定義書自体に矛盾や抜け漏れがないかレビューするのもテストの目的のひとつです。

  2. 故障を引き起こし、欠陥を発見する
    → 実際にソフトウェアを動かして「この操作をするとエラーになる」という故障を意図的に引き起こし、裏側にある欠陥を見つけ出します。

  3. 求められるカバレッジを確保する
    → 「すべての機能を少なくとも1回はテストした」「すべての条件分岐を通った」など、テストが十分な範囲をカバーしているかを確認します。

  4. ソフトウェア品質が不十分な場合のリスクレベルを下げる
    → 「この機能にバグが残っていたら、どれくらい大きな損害になるか？」というリスクを早めに見つけて対処することで、リリース後の事故を防ぎます。

  5. 仕様化した要件が満たされているかどうかを検証する
    → 「ログインボタンを押したらトップページへ遷移する」という要件通りに動くかを確認します。いわゆる「仕様通りに作れているか？」のチェックです。

  6. 契約・法律・規制の要件への適合を検証する
    → 医療機器や金融システムなど、法律や業界規制で「このテストをパスしなければリリース不可」と決まっている場合に、その基準を満たしているかを確認します。

  7. ステークホルダーへ根拠ある判断のための情報を提供する
    → 「テスト結果として、重大なバグが3件残っています」という情報を提供することで、リリースするかどうかをマネージャーや顧客が正しく判断できるようにします。

  8. テスト対象の品質に対する信頼を積み上げる
    → テストを重ねることで「ここまで確認した、問題なかった」という積み重ねが生まれ、リリース前の自信や顧客への安心感につながります。

  9. テスト対象がステークホルダーの期待通りに動作するかどうか妥当性確認をする
    → 仕様通りに動いていても、「実際に使ってみたら使いにくい」「こういう動きを想定していなかった」となれば失敗です。ユーザーや顧客が本当に求めているものと合っているかを確認します。

⚠️ ここがポイント！
テストの目的は「コンテキスト（状況）によって異なる」ということを覚えておいてください。同じテストでも、プロジェクトの種類・フェーズ・ビジネス状況によって、何を重視するかが変わります。

🧩 理解度チェック②

Q. テストの目的として、正しくないものはどれか？

  • a) ステークホルダーに根拠ある判断をしてもらうための情報を提供する
  • b) すべての欠陥を発見し、完全なソフトウェアを証明する
  • c) ソフトウェア品質が不十分な場合のリスクレベルを下げる
  • d) テスト対象の品質に対する信頼を積み上げる
答えを見る

答え：b)

テストは「欠陥がないことを証明する」ことはできません（テストの7原則・原則1）。テストは欠陥を見つけてリスクを下げることができますが、「完全なソフトウェアの証明」はテストの目的ではありません。a)・c)・d) はいずれもシラバスに挙げられた正しいテストの目的です。

3. テストとデバッグの違い

🔥 超重要！ここは絶対に理解するべし！

テストとデバッグはよく混同されますが、明確に異なる活動です。

デバッグの典型的な流れ

① 故障の再現
      ↓
② 診断（根本原因を発見する）
      ↓
③ 原因を修正する
      ↓
④ 確認テスト（修正で直ったかチェック）
      ↓
⑤ リグレッションテスト（修正で別の部分が壊れていないかチェック）

💡 具体例で理解しよう！

通販サイトの「カートに追加」ボタンを押しても、何も起きないという現象が発生したとします。

  • テスト担当者：「カートに追加ボタンを押しても反応がない！」とバグ報告書を書いて報告する
  • 開発担当者：なぜボタンが反応しないかコードを調べ（デバッグ）、「JavaScriptのイベントハンドラーが正しく設定されていなかった」という原因を突き止めて修正する
  • 確認テスト：修正後、同じ手順でもう一度テストして「ちゃんと追加できた！」を確認する
  • リグレッションテスト：修正の影響で他のボタンが壊れていないかも確認する

⚠️ 静的テストの場合は少し違います
静的テストで欠陥を発見した場合は、ソフトウェアを実行していないので「故障を再現する」ステップは不要です。欠陥を直接発見するため、そのまま修正（デバッグ）に移ります。

🧩 理解度チェック③

Q. テストとデバッグの違いについて、正しいものはどれか？

  • a) テストはバグを修正し、デバッグはバグを発見する
  • b) テストはバグを発見・報告し、デバッグはバグの原因を特定・修正する
  • c) テストとデバッグは同じ活動である
  • d) デバッグはテスト担当者が行う活動である
答えを見る

答え：b)

テストは欠陥を発見・報告する活動、デバッグは欠陥の原因を特定して修正する活動です。通常、テストはテスト担当者が、デバッグは開発担当者が行います。a)・c)・d) はそれぞれ担当者や役割が逆になっており誤りです。

4. なぜテストが必要なの？

テストの成功への貢献

テストには大きく3つの貢献があります。

  1. 欠陥を見つけるコスト効果の高い手段を提供する
    → バグを早期に発見することで、後工程での修正コストを大幅に削減できます

  2. 品質を直接評価する手段を提供する
    → 「次のフェーズへ進んでいいか」の判断材料になります（リリース判定など）

  3. ユーザー視点を間接的に提供する
    → テスト担当者はユーザーのニーズが考慮されているかを開発ライフサイクルを通じて確認し続けます

契約・法的な必要性

テストは単に品質のためだけでなく、法律・規制・契約上の義務から必要になる場合もあります（例：医療機器ソフトウェア、航空システムなど）。

🧩 理解度チェック④

Q. テストが成功に貢献する内容として、適切でないものはどれか？

  • a) 欠陥を検出するためのコスト効果のある手段を提供する
  • b) 開発担当者の代わりにすべてのバグを修正する
  • c) SDLCのさまざまな段階において品質を直接評価する手段を提供する
  • d) 間接的にユーザーが利用した場合の状況を提供する
答えを見る

答え：b)

バグを修正するのはデバッグの役割（開発担当者）であり、テストの役割ではありません。テストは欠陥を「発見・報告」することで間接的に品質向上に貢献しますが、修正は行いません。

5. テストとQA・QCの違い

🔥 重要ポイント！用語の混同に注意！

「テスト」「品質保証（QA）」「品質コントロール（QC）」は似て非なるものです。

品質マネジメント
├── 品質保証（QA）：プロセス指向・予防的アプローチ
│     → 「よいプロセスがあれば、よいプロダクトが生まれる」という考え方
│     → 開発プロセス・テストプロセスの両方に適用
│     → プロジェクト参加者全員が責任を持つ
│
└── 品質コントロール（QC）：プロダクト指向・是正アプローチ
      → 実際に作られたプロダクトの品質を確認・是正する
      → テストはQCの主要な形式
      → その他：形式的手法、シミュレーション、プロトタイピングなど

💡 さらに別の具体例で理解しよう！

プログラミングスクールの運営で考えてみましょう。

  • 品質保証（QA）：「生徒が確実に理解できるよう、カリキュラムレビューの仕組みや質問サポート体制のルールを整備する」（仕組みづくり・プロセス改善）
  • 品質コントロール（QC）：「次回の授業で使う教材を事前にチェックして、ミスがないか確認する」（実際の成果物の確認）

テスト結果の使い道

使う場所 何に使うか
QC 欠陥の修正に使う
QA 開発プロセス・テストプロセスの改善フィードバックに使う

🧩 理解度チェック⑤

Q. QA（品質保証）とQC（品質コントロール）の説明として正しいものはどれか？

  • a) QAはプロダクト指向の是正アプローチ、QCはプロセス指向の予防的アプローチである
  • b) QAはプロセス指向の予防的アプローチ、QCはプロダクト指向の是正アプローチである
  • c) テストはQAの主要な形式である
  • d) QAとQCは同じ意味で使われる
答えを見る

答え：b)

QAはプロセスの実装と改善に焦点を当てた「プロセス指向の予防的アプローチ」、QCは適切な品質の達成を支援する「プロダクト指向の是正アプローチ」です。テストはQCの主要な形式であるため、c) は誤りです。

6. エラー・欠陥・故障・根本原因

🔥 超重要！この4つの違いは必ず覚えよう！

人間がエラーを起こす
      ↓
欠陥（バグ）が生まれる
      ↓
欠陥が実行される
      ↓
故障が発生する（場合がある）
用語 別名 意味
エラー（誤り） ミス 人間が起こす間違い
欠陥 フォールト、バグ エラーによってコードや文書に生まれたおかしな部分
故障 — 欠陥が実行されてシステムが期待通りに動かなくなること
根本原因 — 問題が発生した根底の理由

💡 具体例で理解しよう！

ネットショッピングの割引機能を例に考えてみましょう。

  1. エラー：開発者が夜遅くまで作業していて疲れており、割引計算の「-（マイナス）」を「+（プラス）」と打ち間違えた
  2. 欠陥：コードの中に「割引のはずが加算してしまう」という間違ったロジックが存在している状態
  3. 故障：ユーザーが「10%OFF」のクーポンを使ったら、逆に10%高い金額を請求されてしまった！
  4. 根本原因：「深夜作業でのレビューなし」という状況や「疲労による注意力低下」が根本的な原因

覚えておきたい重要ポイント

  • 欠陥があっても、必ずしも故障にはならない → 特定の条件下でしか故障しない欠陥もある
  • 故障の原因は人間のエラーだけではない → 放射線・電磁波などの環境条件でも故障が発生することがある
  • 根本原因を取り除くことで、将来の同様の故障を防げる

⚠️ ここがポイント！
「欠陥があれば必ず故障する」はバツ！欠陥があっても、その部分のコードが実行されなければ故障は発生しません。

🧩 理解度チェック⑥

Q. エラー、欠陥、故障の関係について正しいものはどれか？

  • a) 欠陥があれば必ず故障が発生する
  • b) 故障が発生するには、必ず人間のエラーが原因である
  • c) 人間のエラーによって欠陥が生まれ、欠陥が実行されることで故障が発生する場合がある
  • d) 故障を修正する活動をテストという
答えを見る

答え：c)

a) は誤り：欠陥があっても、特定の条件下でしか故障しない場合や、絶対に故障しない場合もあります。
b) は誤り：放射線や電磁波などの環境条件によっても故障が発生することがあります。
d) は誤り：欠陥を修正する活動は「デバッグ」です。

7. テストの7原則

🔥 重要ポイント！7つ全部覚えましょう！

長年にわたって提唱されてきた、あらゆるテストに適用できる7つの原則があります。

原則1：テストは欠陥があることは示せるが、欠陥がないことは示せない

テストによって欠陥を見つけることはできますが、「テストをして問題なかった＝バグがない」とは言えません。テストは残っている未検出の欠陥の数を減らしますが、ゼロだとは証明できないんです。

💡 「全部テストして問題なかったから完璧！」は言えない、ということですね。

原則2：全数テストは不可能

入力値・条件・手順の組み合わせは膨大すぎて、単純なソフトウェア以外ではすべてをテストすることは現実的ではありません。だからこそ、リスクベースドテストやテストケースの優先順位付けによって、重要なところにテスト労力を集中させることが大切です。

原則3：早期テストで時間とコストを節約

「シフトレフト」 とも呼ばれる考え方です。早い段階で欠陥を見つけるほど、修正コストが小さくなります。

欠陥発見が早いほどコストが低い
要件定義 → 設計 → 実装 → テスト → 本番
  ↑安い                      ↑高い

💡 家を建てるとき、設計図の段階で間違いを見つけるのと、家が完成してから見つけるのでは、修正コストが全然違いますよね。ソフトウェア開発も同じです。

原則4：欠陥の偏在

見つかる欠陥の大部分は、少数のシステムコンポーネントに集中する傾向があります。これは「パレートの法則（80:20の法則）」とも呼ばれ、全体の20%のコンポーネントに80%の欠陥が集まることが多いです。

💡 「よく変更されるモジュール」「複雑な処理のある箇所」に欠陥が集まりやすい、というイメージです。

原則5：テストの弱化（殺虫剤のパラドックス）

同じテストを繰り返し実施すると、新たな欠陥を見つける効果が薄れてきます。殺虫剤を使い続けると虫に耐性ができるのと同じイメージですね。

対策：テスト内容やテストデータを定期的に見直し、新しいテストを追加していく必要があります。

⚠️ ただし、自動化されたリグレッションテストのように「既存の機能が壊れていないことを確認するための繰り返しテスト」は有益です。すべての繰り返しが無意味なわけではありません。

原則6：テストはコンテキスト次第

医療機器のソフトウェアと、ゲームアプリのテストは違って当然ですよね。テストはコンテキスト（状況・背景）によって異なる方法で行われます。唯一の「正解のテスト方法」というものは存在しません。

原則7：「欠陥ゼロ」の落とし穴

すべての欠陥を修正したとしても、ユーザーのニーズや期待を満たしていなければ意味がありません。テストは検証（Verification）だけでなく、妥当性確認（Validation）も忘れずに行う必要があります。

💡 「バグを全部直した完璧なシステム」でも、「そもそも誰も使いたくないシステム」だったら意味がないですよね。

7原則まとめ表

# 原則名 キーポイント
1 欠陥があることは示せるが、欠陥がないことは示せない テストはゼロを証明できない
2 全数テストは不可能 優先順位づけが大切
3 早期テストで時間とコストを節約 シフトレフトの考え方
4 欠陥の偏在 欠陥は少数のコンポーネントに集中する
5 テストの弱化 同じテストを繰り返しても新しいバグは見つからない
6 テストはコンテキスト次第 唯一の正解はない
7 「欠陥ゼロ」の落とし穴 検証だけでなく妥当性確認も大事

🧩 理解度チェック⑦

Q. テストの7原則に関する説明として、正しいものはどれか？

  • a) 同じテストを何度も繰り返すほど、新しい欠陥をより多く見つけられる
  • b) 欠陥は全体のコンポーネントにまんべんなく分布する傾向がある
  • c) すべての欠陥を修正すれば、ユーザーのニーズを満たしたシステムといえる
  • d) テストで欠陥がないことを証明することはできない
答えを見る

答え：d)

a) は誤り：原則5「テストの弱化」より、同じテストの繰り返しは新たな欠陥発見の効果が薄れます。
b) は誤り：原則4「欠陥の偏在」より、欠陥は少数のコンポーネントに集中する傾向があります。
c) は誤り：原則7「欠陥ゼロの落とし穴」より、欠陥をゼロにしてもユーザーニーズを満たさないシステムになることがあります。
d) が正解：原則1より、テストは欠陥がないことを証明できません。

8. テスト活動とテストウェア

テストプロセスの主な活動

テストは以下のような活動で構成されています。実際にはシーケンシャルではなく、反復的・並行して行われることが多いです。

┌─────────────────────────────────────────────────┐
│                  テストプロセス                    │
│                                                 │
│  テスト計画                                       │
│   → テスト目的を定義し、アプローチを選択する        　　│
│                   ↓                             │
│  テストのモニタリングとコントロール                 　│
│   → 進捗をテスト計画と比較し、必要な行動をとる     　　　│
│                   ↓                             │
│  テスト分析（何をテストするか？）                  　　│
│   → テストベースを分析し、テスト条件を定義する     　　　│
│                   ↓                             │
│  テスト設計（どのようにテストするか？）             　　│
│   → テスト条件をテストケースに落とし込む          　　　│
│                   ↓                             │
│  テスト実装                                       │
│   → テスト実行に必要なテストウェアを作成・整備する 　　　│
│                   ↓                              │
│  テスト実行                                        │
│   → テストを実行し、結果を記録・分析する           　　　│
│                   ↓                               │
│  テスト完了                                        │
│   → 教訓の整理・テストウェアの保管・レポート作成  　　　　│
└─────────────────────────────────────────────────┘

各活動のポイント

活動 問いかけ 主な成果物
テスト計画 — テスト計画書、リスクレジスター、開始・終了基準
テスト分析 何をテストするか？ テスト条件、欠陥レポート（直接修正しない場合）
テスト設計 どのようにテストするか？ テストケース、テストチャーター、テストデータ要件
テスト実装 — テストプロシジャー、テストスイート、自動テストスクリプト
テスト実行 — テスト結果記録、欠陥レポート
テスト完了 — テスト完了レポート、教訓ドキュメント

💡 テストウェアとは、テスト活動の中で作成される成果物（テスト計画書・テストケース・テストスクリプトなど）の総称です。

テストベースとテストウェアのトレーサビリティ

トレーサビリティとは、「要件とテストケースがちゃんと対応しているか追跡できる状態」のことです。

なぜ重要かというと、、

  • 要件がテストケースでカバーされているかを検証できる
  • 残っているリスクのレベルを評価できる
  • 変更の影響範囲を判断できる
  • テストの監査を容易にできる
  • ステークホルダーへの説明がしやすい

🧩 理解度チェック⑧

Q. テスト活動に関する説明として、正しいものはどれか？

  • a) テスト分析では「どのようにテストするか？」という問いに答える
  • b) テスト設計では「何をテストするか？」という問いに答える
  • c) テスト分析では「何をテストするか？」、テスト設計では「どのようにテストするか？」という問いにそれぞれ答える
  • d) テスト実装はテスト計画の前に行われる
答えを見る

答え：c)

テスト分析は「何をテストするか（テスト条件の定義）」、テスト設計は「どのようにテストするか（テストケースへの落とし込み）」という問いにそれぞれ答える活動です。a)・b) は分析と設計の役割が逆になっており誤り、d) はテスト実装はテスト計画より後の工程のため誤りです。

9. コンテキストに応じたテストプロセス

テストは以下の様々なコンテキスト要因に影響されます。

  • ステークホルダー（ニーズ・期待・協力の意思など）
  • チームメンバー（スキル・経験・空き状況など）
  • ビジネスドメイン（対象の重要性・リスク・法的規制など）
  • 技術的要因（ソフトウェアの種類・アーキテクチャーなど）
  • プロジェクトの制約（スコープ・時間・予算・リソースなど）
  • 組織的要因（組織構造・ポリシーなど）
  • ソフトウェア開発ライフサイクル（SDLC）
  • ツール（利用可能性・使用性など）

これらの要因によって、テスト戦略・テスト技法・自動化の度合い・ドキュメントの詳細度などが変わってきます。

10. テストの役割

シラバスでは2つの主要な役割が定義されています。

役割 主な責任 重点を置く活動
テストマネジメントをする役割 テストプロセス・チーム・活動のリーダーシップ全体 テスト計画、モニタリングとコントロール、テスト完了
テストをする役割 テストのエンジニアリング（技術的）側面全体 テスト分析、テスト設計、テスト実装、テスト実行

💡 一人が両方の役割を兼務することも可能です。また、アジャイル開発ではテストマネジメントのタスクをチーム全体で分担することもあります。

🧩 理解度チェック⑨

Q. テストの役割に関する説明として、正しいものはどれか？

  • a) テストマネジメントをする役割は、テスト分析・テスト設計・テスト実行に重点を置く
  • b) テストをする役割は、テスト計画とテスト完了に重点を置く
  • c) テストマネジメントをする役割とテストをする役割は、必ず別々の人が担当しなければならない
  • d) テストをする役割は、テストのエンジニアリング（技術的）側面に対する責任を負う
答えを見る

答え：d)

a) は誤り：テスト分析・設計・実行に重点を置くのは「テストをする役割」です。
b) は誤り：テスト計画・完了に重点を置くのは「テストマネジメントをする役割」です。
c) は誤り：一人が両方の役割を兼務することも可能です。
d) が正解：テストをする役割はテストのエンジニアリング（技術的）側面全体に責任を負います。

11. テスト担当者に必要なスキル

汎用的なスキル

よいテスト担当者には以下のスキルが求められます。

  • 🧠 テスト知識（テスト技法を活用してテストの有効性を高めるため）
  • 🔍 徹底さ・慎重さ・好奇心・細部へのこだわり・理路整然さ（発見しにくい欠陥を識別するため）
  • 💬 優れたコミュニケーションスキル・傾聴力・チームワーク（ステークホルダーと効果的にやりとりするため）
  • 💡 分析的思考・批判的思考・創造性（テストの有効性を高めるため）
  • 🛠️ 技術的な知識（テストツールを適切に使いこなすため）
  • 📦 ドメイン知識（エンドユーザー/ビジネス側を理解するため）

テスト担当者と心理学

テスト担当者は「悪い知らせの運び手」になりやすく、開発者から反感を買いがちです。なぜかというと、開発者には「確証バイアス」（自分のコードは正しいはずだという思い込み）があるからです。

上手な伝え方のポイント：

❌ 「あなたのコードに問題があります！」（責めるような言い方）

✅ 「○○の画面で、○○の手順を実行したとき、△△という結果になりました。期待値は□□です」（事実に焦点を当てた言い方）

欠陥や故障に関する情報は建設的な方法で伝えることが重要です。

12. チーム全体アプローチとテストの独立性

チーム全体アプローチ

エクストリームプログラミング（XP）に由来する考え方で、「必要な知識とスキルを持つチームメンバーであれば誰でもどの仕事を行ってもよく、全員が品質に対して責任を持つ」というアプローチです。

メリット：

  • チームダイナミクスの向上
  • 情報伝達とコラボレーションの強化
  • さまざまなスキルセットを活用できる

⚠️ ただし、セーフティクリティカルなシステムなど、高いレベルのテスト独立性が必要な場合は、このアプローチが常に適切とは限りません。

テストの独立性

独立性のレベル 説明
独立性なし 作成者自身がテストする
ある程度の独立性あり 同じチームのメンバーがテストする
独立性が高い チーム外・組織内のテスト担当者がテストする
独立性がとても高い 組織外のテスト担当者がテストする

独立性が高いことのメリット：

  • 異なる視点・バイアスを持つため、開発担当者が見落とした欠陥を発見しやすい
  • ステークホルダーが設定した仮定を客観的に検証・反証できる

独立性が高いことのデメリット：

  • 開発チームとの孤立・敵対関係に陥る可能性がある
  • 開発担当者が品質に対する責任感を失う可能性がある
  • ボトルネックとみなされたり、リリース遅延の原因と見られたりすることがある

💡 ほとんどのプロジェクトでは、複数の独立性レベルを組み合わせるのが最善とされています（例：開発者がコンポーネントテスト、テストチームがシステムテスト、ビジネス代表者が受け入れテスト）。

🧩 理解度チェック⑩

Q. テストの独立性に関する説明として、正しいものはどれか？

  • a) テストの独立性が高いほど常によい結果が得られるため、すべてのプロジェクトで最高レベルの独立性を目指すべきである
  • b) 独立したテスト担当者が存在すると、開発担当者は品質に対する責任を持たなくてよくなる
  • c) 独立したテスト担当者は、開発担当者と異なる視点を持つため、異なる種類の欠陥を発見しやすい
  • d) チーム全体アプローチはすべてのコンテキストで適切である
答えを見る

答え：c)

a) は誤り：独立性が高すぎると孤立や敵対関係などのデメリットも生じるため、プロジェクトに応じた適切なレベルを選ぶことが大切です。
b) は誤り：独立したテスト担当者の存在は開発担当者が品質責任を感じにくくなるリスクはありますが、「責任を持たなくてよい」わけではありません。
c) が正解：独立したテスト担当者は異なる経歴・視点・バイアスを持つため、開発担当者が見落とした欠陥を発見しやすいというメリットがあります。
d) は誤り：セーフティクリティカルなシステムなど、高い独立性が必要な場合はチーム全体アプローチが適切でない場合があります。

📌 第1章まとめ

トピック 覚えるべきポイント
テストの定義 欠陥発見＋品質評価のための活動。実行だけではない！
検証 vs 妥当性確認 検証＝仕様通りか、妥当性確認＝ユーザーニーズを満たすか
テストとデバッグ テスト＝発見・報告、デバッグ＝原因特定・修正
QA vs QC QA＝プロセス指向・予防的、QC＝プロダクト指向・是正的
エラー→欠陥→故障 欠陥があっても必ずしも故障するわけではない
テストの7原則 7つ全部、内容と名前をセットで覚えよう
テスト活動 計画→分析（何を）→設計（どのように）→実装→実行→完了
テストの独立性 独立性が高いほど異なる視点で欠陥を発見しやすい

お疲れ様でした！第1章の内容は、JSTQB試験全体の「共通言語」となる基礎です。ここで登場した用語や概念は第2章以降でも繰り返し出てきますので、ぼんやりとでもいいので「なんとなくわかる」状態を作っておくことが大切だと思います(^^)

第2章「ソフトウェア開発ライフサイクルにおけるテスト」の解説もお楽しみに！ 🎉

Discussion