【JSTQB】1章 テストの基礎｜解説

（※当記事は、2024年12月10日時点での最新版(2023V4.0.J02)のシラバスを元に作成しています。）

この記事では、JSQTB (Japan Software Testing Qualifications Board) の Foundation Level のシラバスを分かりやすくかみ砕いて解説していきます。
6記事に分けて、全ての章を解説していきますので、シラバスのなかの要点を押さえたい、ここが分からないという際に参考にしてください。

この記事では、1章 テストの基礎 を解説していきます。
その他の章の解説は下記よりご参照ください。

各章	リンク
1章	【JSTQB】1章 テストの基礎｜解説
2章	【JSTQB】2章 ソフトウェア開発ライフサイクル全体を通してのテスト｜解説
3章	【JSTQB】3章 静的テスト｜解説
4章	【JSTQB】4章 テスト分析と設計｜解説
5章	【JSTQB】5章 テスト活動のマネジメント｜解説
6章	【JSTQB】6章 テストツール｜解説

1.1 テストとは何か？

JSTQBにおけるテストとはソフトウェアテストを指します。

ソフトウェアテストとは…
ソフトウェアの品質を評価し、故障リスクを低減する重要な活動。
欠陥を発見し、品質を評価する一連の活動を指す。

ソフトウェアシステムは現代社会において不可欠な要素であり、ソフトウェアが正常に動作しない場合、経済的損失や信用失墜、さらには重大な事故につながる可能性があります。
これらを減らす(低減する)ための手助けとなる活動です。

ソフトウェアテストの概要

• テストは欠陥を発見し、品質を評価する一連の活動を指す。
  （単なる実行検証に留まらず、計画や管理など付随する工程も含まれる。）
• 検証（要件が満たされているか）だけでなく、妥当性確認（ユーザーやステークホルダーのニーズを満たすか）が重要。
• 動的テスト（実行を伴う）と静的テスト（実行を伴わない）があり、それぞれ異なる手法が用いられる。

テストの目的

• 欠陥を発見し、品質に対する信頼を向上させる。
• 要件や規制への適合性を検証する。
• リスクを軽減し、関係者が判断できる情報を提供する。

テストとデバッグの違い

JSTQB では、テストと似たような言葉で「デバッグ」が挙げられます。
「テスト」と「デバッグ」の大きな違いは行う担当者・作業内容の違いであることを覚えましょう。

用語	作業内容	担当者
テスト	欠陥や故障の発見に焦点を当てる活動	テスト担当者
デバッグ	発見された欠陥の原因を診断し、修正する活動	開発者

また、デバッグのプロセスには「故障の再現」「原因の診断」「修正」が含まれ、修正後には確認テストやリグレッションテストが行われます。

リグレッションテストとは…
ソフトウェアの機能やプログラムを変更した後に、他の部分に意図しない不具合が発生していないかどうかを確認するためのテストのこと。

1.2 なぜテストが必要か？

テストはあくまで品質コントロールの手段の1つです。
ソフトウェアの欠落を発見するために役立ち、設定された範囲、時間、品質、予算の制約の中で合意されたゴールを達成するために行われることを覚えておきましょう。

1.2.1 テストの成功への貢献

成功への貢献というと分かりにくいですが、こちらはテストの役割を指します。
テストの役割は大きく下記の通りです。

• コスト効果のある手段としてソフトウェアの品質向上に貢献する
• SDLCの各段階に品質評価基準を設けられる
• ユーザー視点での使用状況を反映し開発プロセスを補完する
• 契約や法的要件、規制基準の遵守に対応する

コスト効果のある手段としてソフトウェアの品質向上に貢献する

コスト効果とは…
コスト(費用)に対する成果を指す。
今回は、コスト(費用)をかける価値のある手段

テストで欠陥を発見→修正（デバッグ）のサイクルを通じてソフトウェアの品質向上が期待できます。

テストはやらないよりもやった方が品質の高いソフトウェアができるという当然の考えです。

SDLCの各段階に品質評価基準を設けられる

SDLC（Software Development Life Cycle）とは…
ソフトウェア開発ライフサイクルのこと。

サイクルの各段階でテストを実行することで、サイクル移行時の抜け漏れを発見することができます。
これにより、各段階の品質を評価し、次のステージへの移行判断を行うためにに役立ちます。

開発フェーズに移行後、計画フェーズの計画漏れが発生し巻き戻るなどの手間を減らすことができます。

ユーザー視点での使用状況を反映し開発プロセスを補完する

ユーザーのニーズを反映させたソフトウェアにするために、ユーザーをテストに関与させることも可能です。しかし、ユーザーを関与させるのはコストが高くなるため、基本的には行われません。
（※αテストやβテストなどがこれに当たります。）

契約や法的要件、規制基準の遵守に対応する

成果物の守るべき要件や制限（契約・法律）を漏れなくチェックするために必要な場合があります。契約や法律により、何かしらの確認・テストが必須となっている場合がこれに当たります。
（※法的規制基準に抵触している可能性のあるソフトウェアなど）

1.2.2 テストと品質保証（QA）の違い

テストは品質コントロール（QC）の手法の一部であり、品質保証（QA）とは別物であるということを押さえましょう。
なお、品質コントロール（QC）は欠陥修正に、品質保証（QA）はプロセス改善に使用されます。

テスト

• 品質コントロール（QC）の一部
• 欠陥の発見や修正に焦点を当てるプロダクト指向の是正的アプローチ。
• 品質コントロール（QC）にはテストのほか、形式的手法（モデル検査、定理証明）、シミュレーション、プロトタイピングなどがある。

品質コントロール(QC)とは…
成果物の適切な品質の達成を目標としたプロダクト思考の是正アプローチのこと。
(成果物をいいものにすればOKの思考 ＝ お客様目線)

品質保証（QA）

• プロセスの実装や改善を重視した予防的アプローチ。
  プロセスが正しく行われることで良いプロダクトが生まれるという考え。
• 開発およびテストプロセス全体を対象とし、プロジェクト参加者全員が責任を共有する。

品質保証(QA)とは…
成果物制作の適切なプロセス実行と改善を目標としたプロセス思考の予防的アプローチのこと。
（製作手法が誤らなければいいものができるのでOKの思考 ＝ 開発者目線）

1.2.3 エラー、欠陥、故障、根本原因

エラー・欠陥・故障の関係は下記表の通りです。

エラー	人間のミス
欠陥	エラーにより生み出されたバグ
故障	エラー欠陥のほか、環境条件により生じるシステムの不具合

根本原因とは…
問題（エラーにつながる状態）が発生する根本的な理由のこと。
分析することを根本原因分析と呼ぶ。（KYTなどが当たる）

エラー原因の代表例

以下の作業ミスの原因が代表として挙げられています。

• 時間的なプレッシャー
• 作業成果物、プロセス、インフラ、相互作用の複雑度
• 疲労
• トレーニング不足

欠陥の発見時期による影響度

欠陥は、ドキュメント（要件仕様書やテストスクリプト）やソースコード、ビルドファイルなど様々なアーティファクトで発見されます。

SDLCの初期段階で早期発見できれば影響は少ないですが、後半になるにつれ大きな影響を及ぼすことがあることを覚えておきましょう。
(早期のテストは欠落残置による影響を減らす役割を持つということ)

環境要因による故障

エラーや欠陥だけではなく、放射線や電磁波など外的要因も故障の原因になる場合があります。
そのことを環境要因による故障と呼びます。

1.3 テストの原則

テストの基本的な7つの原則は下記の通りです。
この7つの原則は、効果的なテストを行うための指針を表しています。

1. 欠陥の存在を示すが、欠陥の不在は証明できない
   • テストは欠陥を見つける手段であり、完全な正しさの証明は不可能。
2. 全数テストは不可能
   • 全てのテストケースを網羅することは現実的ではなく、リスクベースドテストやテストケースの優先順位付けで効率化する必要がある。
3. 早期テストがコスト削減に貢献
   • SDLC初期にテストを開始することで、後半の欠陥修正コストを削減。静的テストと動的テストを早期に行うべき。
4. 欠陥の偏在
   • 多くの欠陥や故障は特定の少数のコンポーネントに集中する（パレートの法則）。
   • リスクベースドテストに活用可能。
5. テストの弱化
   • 同じテストを繰り返すと新しい欠陥発見の効果が低下するため、新しいテストデータやテストを導入する必要がある。ただし、自動化テストのように繰り返しが有益な場合もある。
     （殺虫剤のパラドクスとしても有名で何度も使うと効果が薄れることを指す）
6. テストはコンテキスト次第
   • 全ての状況に適用できる普遍的なテスト方法は存在せず、テストアプローチはコンテキストに応じて調整される。
7. 「欠陥ゼロ」の落とし穴
   • 全ての欠陥を修正しても、ユーザーの期待やビジネスゴールに適合しないシステムになる場合がある。検証（Verification）に加え、妥当性確認（Validation）が必要。

1.4 テスト活動、テストウェア、そして役割

実行するテストプロセスはコンテキスト次第で調整する必要があります。

コンテキストとは…
プログラムの実行に必要な各種情報のこと。
（データ関係・仕様・開発チームの背景などがこれに当たる）

基本的に上記で述べたようにテストプロセスは状況に応じて調整が必要となりますが、汎用的なテスト活動のセットが存在します。
(毎回白紙から計画するわけではなく、ベースとなるテストフローは存在するということ)

また、これらのテスト活動の実行可否やタイミングなどの詳細は「テスト計画」のフェーズで作成・定義されます。

1.4.1 テスト活動とタスク

テストは一連の活動であると1節で解説しましたが、具体的には下記のフローを通した活動です。

1. テスト計画
   • テスト目的を定義し、制約内で効果的なアプローチを決定する。
2. テストのモニタリングとコントロール
   • テスト進捗を監視し、計画との差異に基づいて調整を行う。
3. テスト分析
   • テスト可能な条件を定義し、優先順位付けやリスク分析を行う。
4. テスト設計
   • テスト条件から具体的なテストケースを作成し、必要なテストデータや環境を設計する。
5. テスト実装
   • テスト実行に必要な資材（データ、スクリプトなど）を準備し、テスト環境を構築する。
6. テスト実行
   • テストスケジュールに従い実行し、結果を記録・分析し、欠陥を報告する。
7. テスト完了
   • 作成した成果物を保管・引き渡し、学びや改善点を記録する。

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

前述した通り、テスト活動はプロジェクトの状況や以下の要因に依存します。
コンテキストの例としては下記が挙げられます。

• ステークホルダーのニーズ
• チームメンバーのスキル
• ビジネスや技術の要件
• プロジェクトの制約（時間、予算など）
• 使用する開発手法やツール

1.4.3 テストウェア

テストウェアとは…
テスト活動で生成される成果物（テスト計画書、スケジュール、リスクレジスター、テストケース、テストデータなど）の総称のこと。

これらは構成管理により一貫性を保つ必要があります。

テストウェア一覧表

テスト段階	作業成果物一覧
テスト計画	・テスト計画書 ・テストスケジュール ・リスクレジスター ・開始基準・終了基準
テストのモニタリングとコントロール	・テスト進捗レポート ・コントロールのための指示書 ・リスク情報
テスト分析	・テスト条件 ・テストベース内の欠陥についての欠陥レポート
テスト設計	・テストケース ・テストチャーター ・カバレッジアイテム ・テストデータ要件 ・テスト環境要件
テスト実装	・テストプロシジャー ・自動テストスクリプト ・テストスイート ・テストデータ ・テスト実行スケジュール ・テスト環境（スタブ・ドライバー・シミュレータ・サービス仮想化）
テスト実行	・テスト結果記録 ・欠陥レポート
テスト完了	・テスト完了レポート ・アクションアイテム ・バックログアイテム

※○○の作業成果物で正しいものを選ぶ問題が出る可能性があるため覚えるべき

カバレッジとは…
対象範囲に対して全体の内どれくらい網羅しているかを示す指標のこと。
（JSTQBでは、測定可能なテスト目的を基準としてどれだけ網羅されているテストかという意で使われている。）

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

効果的なテストプロセスを実行するにあたり、テストベース（要件やリスクなど）とテストウェア（テストケースや結果など）との間のトレーサビリティを確立・維持することが重要となります。

トレーサビリティとは…
設計過程を可視化すること。

トレーサビリティの指標や役割としては下記の通りです。

• カバレッジ(網羅率)基準をKPIとして評価することができる
• テスト内容変更の影響範囲を判断できる
• ガバナンス基準の順守していることを明確化できる
• ステークホルダーへの説明に用いることができる

1.4.5 テストの役割

テストプロセスにおいて大きな2つの役割を解説していきます。

• テストをする役割
• テストマネジメントをする役割

これらの役割は固定化されることは無く、経験や状況によって変化するものであることを押さえておきましょう。
（「○○さんは最初テスト担当だったため、今後はテストマネジメントの役割をもつべきではない」とはなりません。）

テストをする役割

テストの分析、設計、実装、実行を担当するサイドです。
テストにおけるエンジニアリング(技術的)面において責任を求められます。

テスト実行だけが役割ではないため注意！

テストマネジメントをする役割

テスト計画、進捗管理、完了活動を担当します。
テスト活動全体に置いてリーダーシップを取る責任を持ちます。

1.5 テストに必要不可欠なスキルとよい実践例

テストにおけるスキルとアプローチは、効果的なチーム連携や独立性のバランスが重要であり、プロジェクトの特性に応じて柔軟に適用する必要がある点を押さえておきましょう。

1.5.1 テストに必要な汎用的スキル

テスト担当者が持つべき主なスキルは下記の5種類です。

• 徹底さ・慎重さ: 隠れた欠陥を発見する能力。
• 優れたコミュニケーションスキル: チームや関係者との効果的な情報共有、欠陥報告。
• 分析的・批判的思考と創造性: テストの効果性向上のため。
• 技術的知識: テストツールや技術の活用。
• ドメイン知識: ユーザーやビジネスの視点を理解する能力。

注意点
テスト担当者は「悪い知らせ」を伝える役割となりやすく、確証バイアスや批判と捉えられるリスクがあるため、建設的な伝え方が重要。

1.5.2 チーム全体アプローチ

チーム全体アプローチの概念としては、テスト担当者・実装作業者と分けて専門的に行うのではなく、全員が全員同等の知識を持つ環境であれば、よりスムーズに開発が進行するという考えを示します。

チーム全体アプローチのポイント

• チームメンバー全員が品質に責任を持ち、相互に連携して作業する
  ※実装作業者目線：テストがあるからいいやという考えは捨てる
  ※テスト担当者目線：実装がすべて悪いという考えは捨てる
• 同じワークスペース（物理的または仮想的）を共有することで情報伝達と相互作用を強化
  ※全体が同じ環境に触れられることで共通言語での会話が可能となる

チーム全体アプローチのなかのテスト担当者の役割

• 他のメンバーと協力してテスト戦略や自動化アプローチを決定する
• テスト知識を共有することで、全体の意識を高めプロダクト品質向上に寄与する

チーム全体アプローチの制約
高度な独立性が必要な場合（例: 安全性が重要なプロジェクト）には適用が難しい。

1.5.3 テストの独立性

テストにおける独立性とは、テスト担当者と実装作業者の関係を表します。

独立性のレベル

独立性	テスト担当者
独立性なし	作成者が自身でテスト
一定の独立性	チーム内の他者がテスト
高い独立性	チーム外の組織内テスト担当者
非常に高い独立性	組織外のテスト担当者

独立性におけるメリット・デメリットは押さえておきましょう。

独立性のメリット
・作成者とは異なる視点やバイアスで欠陥を発見しやすい。
・仕様や実装の仮定を検証・反証できる。

独立性のデメリット
・開発チームとの連携不足や対立が生じる可能性。
・開発者の品質責任感が低下するリスク。
・独立したテスト担当者がボトルネックとされる場合がある。

他の章を確認する

各章	リンク
1章	【JSTQB】1章 テストの基礎｜解説
2章	【JSTQB】2章 ソフトウェア開発ライフサイクル全体を通してのテスト｜解説
3章	【JSTQB】3章 静的テスト｜解説
4章	【JSTQB】4章 テスト分析と設計｜解説
5章	【JSTQB】5章 テスト活動のマネジメント｜解説
6章	【JSTQB】6章 テストツール｜解説