最終更新日: 2024年3月15日

JSTQB（ソフトウェアテスト技術者資格認定組織）は、Foundation LevelシラバスVersion 2023V4.0 日本語翻訳版（以下、2023年版）を2023年9月に公開いたしました。ISTQB (国際ソフトウェアテスト資格認定委員会) が 2023年5月にリリースした Foundation Level シラバスVersion 2023V4.0を日本語訳したものです。この記事では、「1．テストの基礎」の章における2018年版からの具体的な変更点を解説いたします。なお、各章のタイトルや見出しは、2023年版のものに合わせております。

テストの基礎

2023年版では、次のキーワードが削除されています。

テスト実行スケジュール、テストオラクル、テスト手順、テストスイート、トレーサビリティ

1.1テストとは何か？

大きな変更点としては、2023年版では以下の文章が追加されています。

動的テストでは、さまざまな種類のテスト技法やテストアプローチを用いてテストケースを導出する（第 4 章 参照）。

テストは、技術的な活動だけではない。適切に計画、マネジメント、見積り、モニタリング、コントロ ールすることもまた必要となる（第 5 章参照）。

テスト担当者はツールを使用するが（第 6 章参照）、テストは大部分が知的活動であり、テスト担当者は専門知識を持ち、分析スキルを使い、批判的思考やシステム思考を適用することが求められることを忘れてはならない（Myers 2011, Roman 2018）。

標準である ISO/IEC/IEEE 29119-1 では、ソフトウェアテストの概念についてさらに詳しい情報を提供している。

・1.1.1 テスト目的

全体的に文言が変更されています。

※具体的な変更についてはこちらをご参照ください。

・1.1.2 テストとデバッグ

最新版では、全体的に言い回しが変更になっている他、以下の通り、典型的なデバッグの流れについても解説しています。

典型的なデバッグの流れは以下の通り：
⚫ 故障の再現
⚫ 診断（根本原因を発見すること）
⚫ 原因を修正すること

また、以下の一文が追加されています。

静的テストで欠陥を識別した場合、デバッグすることはその欠陥を取り除くことである。静的テストは 欠陥を直接発見するものであり、故障を引き起こすことはできないため、再現や診断の必要はない（第 3 章参照）。

・1.2.2 テストと品質保証（QA）

全体的に言い回し等が変更になっています。テストがQC（品質コントロール）の形式の1つだという内容に相違はありませんが、2018年版では説明されていた品質マネジメントという概念は、2023年版では省略されています。

2023年版では、QC(品質コントロール）とQA（品質保証）の役割の違いを次のように解説しています。

テスト結果は、QA と QC で使用する。QC では欠陥の修正に使い、QA では開発とテストプロセスがど の程度うまくいっているかについてのフィードバックに使う。

・1.2.3 エラー、欠陥、故障、および根本原因

2018年版では1.2.3 エラー、欠陥、および故障と、1.2.4 欠陥、根本原因、および影響の2つの項目に分かれていたものが2023年版では1つにまとめられ、よりコンパクトになっています。全体的に言い回しの変更はありますが、内容に相違はありません。

・1.3 テストの原則

2018年版「テストの7原則」から「テストの原則」に変更されています。

また、以下の原則が変更となっています。

2018年版2023年版
5.殺虫剤のパラドックスにご用心
同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなる。この 「殺虫剤のパラドックス」を回避するため、テストとテストデータを定期的に見直して、改定したり新 規にテストを作成したりする必要がある（殺虫剤を繰り返し使用すると効果が低減するのと同様に、テ ストにおいても欠陥を見つける能力は低減する）。ただし、自動化されたリグレッションテストの場合 は、同じテストを繰り返すことでリグレッションが低減しているという有益な結果を示すことができる。		5.テストの弱化
同じテストを何回も繰り返すと、新たな欠陥の検出に対する効果は薄れてくる（Beizer 1990）。この影響を克服するため、テストとテストデータを変更したり新規にテストを作成したりする ことが必要になる場合がある。しかし、例えば、自動化されたリグレッションテストのように、同じテ ストを繰り返すことが有益な結果を示すことができる場合がある（2.2.3 項参照）
6.テストは状況次第
状況が異なれば、テストの方法も変わる。例えば、安全性が重要な産業用制御ソフトウェアのテストは、 e コマースモバイルアプリケーションのテストとは異なる。また、アジャイルプロジェクトとシーケンシ ャルライフサイクルプロジェクトでは、テストの実行方法が異なる（2.1 節を参照）。		6.テストはコンテキスト次第
テストに唯一普遍的に適用できるアプローチは存在しない。テストは、 コンテキストによって異なる方法で行われる（Kaner 2011）。
7.「バグゼロ」の落とし穴
テスト担当者は可能なテストすべてを実行でき、可能性のある欠陥すべてを検出できると期待する組織 があるが、原則 2 と原則 1 により、これは不可能である。また、大量の欠陥を検出して修正するだけで システムを正しく構築できると期待することも誤った思い込みである。例えば、指定された要件すべて を徹底的にテストし、検出した欠陥すべてを修正しても、使いにくいシステム、ユーザーのニーズや期待を満たさないシステム、またはその他の競合システムに比べて劣るシステムが構築されることがある		7.「欠陥ゼロ」の落とし穴
ソフトウェアを検証するだけでシステムを正しく構築できると期待することは誤り（つまり、思い込み）である。例えば、指定された要件すべてを徹底的にテストし、検出した 欠陥すべてを修正しても、ユーザーのニーズや期待を満たさないシステム、顧客のビジネスゴールの達 成に役立たない、およびその他の競合システムに比べて劣るシステムが構築されることがある。検証に 加えて、妥当性確認も実施すべきである（Boehm 1981）。

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

2018年版では「テストプロセス」となっていますが、上記タイトルに変更されています。

・1.4.1 テスト活動とタスク

それぞれの活動の説明の言い回しは若干異なっています。2023年版ではよりコンパクトにまとめられています。

※具体的な変更については、こちらをご参照ください。

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

2018年版の「1.4.1 状況に応じたテストプロセス」から上記タイトルに変更になっています。

2018年版でのテストプロセスに影響する状況の例と、2023年版のコンテキストに応じた要因の例では、大きくは変わりませんが、2023年版では「考慮対象のテストレベルとテストタイプ」が削除されています。

※具体的な変更については、こちらをご参照ください。

・1.4.3 テストウェア

2018年版の「テスト作業成果物」から上記ワードに変更になっています。
内容に大きな相違はありませんが、2023年版では各テストウェアの解説がより簡潔にまとめられています。

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

大きな内容の変更はありません。”効果的なテストのモニタリングとコントロールを実装するためには、テストベースの各要素と関連する テストウェア、テスト結果、検出した欠陥との間のトレーサビリティを、テストプロセス全体を通して確立、および維持することが重要である”という内容は共通していますが、2023年版では、正確なトレーサビリティはカバレッジの評価を支援することがより強調されています。そして、”測定可能なカバレッジ基準がテストベースに定義してある場合、非常に有用となり、カバレッジ基準は、テスト目的がどの程度達成しているか示す活動を遂行するためのKPIとして機能する”とし、以下を例に挙げています。

・テストケースと要件のトレーサビリティにより、要件がテストケースでカバーされていることを検証することができる。
・テスト結果とリスクのトレーサビリティは、テスト対象にある残存リスクのレベルを評価するために利用できる。

・1.4.5 テストの役割

新規で追加された項目です。テストにおける2つの主要な役割である「テストする役割」と「テストマネジメントをする役割」について解説されています。

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

新規で追加された項目です。「1.5.1 テストに必要な汎用的スキル」、「1.5.2 チーム全体アプローチ」、「1.5.3 テストの独立性」について解説されています。

なお、2018年版の「1.5 テストの心理学」は、2023年版では削除されています。

【比較表】具体的な文言の変更

ここでは、比較可能な点において、具体的な文言の比較をしています。必要に応じてご参照ください。

・1.1.1 テスト目的

2018年版2023年版
•要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。
• 明確にしたすべての要件を満たしていることを検証する。
• テスト対象が完成し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥 当性確認をする。
• テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する。
• 欠陥の作りこみを防ぐ。
• 故障や欠陥を発見する。
• ステークホルダーが意志決定できる、特にテスト対象の品質レベルについての十分な情報を提供 する。
• （以前に検出されなかった故障が運用環境で発生するなどの）不適切なソフトウェア品質のリス クレベルを低減する。
• 契約上、法律上、または規制上の要件や標準を遵守する、そして／またはテスト対象がそのよう な要件や標準に準拠していることを検証する。		 •要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。
•故障を引き起こし、欠陥を発見する。
•求められるテスト対象のカバレッジを確保する。
•ソフトウェア品質が不十分な場合のリスクレベルを下げる。
•仕様化した要件が満たされているかどうかを検証する。
•テスト対象が契約、法律、規制の要件に適合していることを検証する。
•ステークホルダーに根拠ある判断をしてもらうための情報を提供する。
•テスト対象の品質に対する信頼を積み上げる。
•テスト対象が完成し、ステークホルダーの期待通りに動作するかどうかの妥当性確認をする。

・1.4.1 テスト活動とタスク

2018年版2023年版
テスト計画 テスト計画では、テストの目的と、状況により課せられる制約内でテストの目的を達成するためのアプローチを定義する（例えば、適切なテスト技法とタスクを指定し、納期に間に合うようにテストスケジ ュールを作成する）。テスト計画書は、モニタリングとコントロールの活動からのフィードバックに応じて更新をする。テスト計画については、5.2 節でさらに説明する。 テスト目的を定義することと、その後に全体のコンテキストにより課せられた制約下において目的を最も効果的に達成するアプローチを選択することから構成される。テスト計画については、5.1 節でさらに説明する。
テストのモニタリングとコントロール テストモニタリングは、テスト計画書で定義したテストモニタリングのメトリクスを使用して、テスト計画書の内容と実際の進捗を継続的に比較する活動である。テストコントロールは、テスト計画書の目 的に合致させるために対策を講じる活動で、テスト計画書の継続的な更新活動も含む。テストのモニタ リングとコントロールは、終了基準の評価により支援される。終了基準は、ライフサイクルによっては 「完了（done）の定義」とも呼ばれる（『ISTQB テスト技術者資格制度 Foundation Level Extension シラバス アジャイルテスト担当者 日本語版 Version 2014.J01』を参照）。例えば、テストレベルによっては、テスト実行の終了基準を評価する際に、以下の活動を行う。
•特定のカバレッジ基準に対してテスト結果とログをチェックする。
•テスト結果とログに基づいて、コンポーネントまたはシステムの品質のレベルを評価する。
•さらなるテストが必要かどうかを判断する（例えば、プロダクトリスクカバレッジで目標とした 特定のレベルを当初予定したテストで達成できない場合、さらなるテストの作成および実行が必 要になる）。

計画に対するテスト進捗は、テスト進捗レポートを使用してステークホルダーへ伝える。このレポート で伝える内容には、計画からの逸脱や、テストの中止を決定するために必要な情報を含む。 テストのモニタリングとコントロールについては、5.3 節でさらに説明する。

 テストモニタリングは、すべてのテスト活動を継続的にチェックし、実際の進捗をテスト計画と比較することを含む。テストコントロールは、テストの目的を達成す るために必要な行動をとることを含む。テストのモニタリングとコントロールについては、5.3 節でさらに説明する。
テスト分析 テスト分析では、テスト可能なフィーチャーを識別し、テスト条件を決めるためにテストベースを分析 する。言い換えると、テスト分析では計測可能なカバレッジ基準から見た「何をテストするか」を決定 する。 テスト分析の主な活動は以下の通りである。
•テストレベルごとに適切なテストベースを分析する。
　o 要件仕様。ビジネス要件、機能要件、システム要件、ユーザーストーリー、エピック、ユースケー スの他、コンポーネントやシステムに期待される機能および非機能の動作を指定する類似の作業成 果物などがある。
　o 設計および実装情報。システムやソフトウェアに関するアーキテクチャー図もしくはドキュメント、 設計仕様、コールフロー、モデル図（UML や ER 図など）、インターフェース仕様、コンポーネ ントもしくはシステムの構造を指定する類似の作業成果物などがある。
　o コンポーネントまたはシステム実装そのもの。コード、データベースのメタデータやクエリー、イ ンターフェースなどがある。
　o リスク分析レポート。コンポーネントやシステムの機能、非機能、構造の各側面を考慮する。
•テストベースとテストアイテムを評価して、以下のようなさまざまな種類の欠陥を識別する。
　o 曖昧
　o 欠落
　o 不整合
　o 不正確
　o 矛盾
　o 冗長なステートメント
•テストすべきフィーチャーとフィーチャーのセットを識別する。
•テストベースの分析に基づいて、各フィーチャーのテスト条件を決めて優先度を割り当てる。こ の際には、機能/非機能/構造の特性、他のビジネス/技術的要因、リスクのレベルを考慮する。
•テストベースの各要素と関連するテスト条件の間に双方向のトレーサビリティを確立する（1.4.3 節と 1.4.4 節を参照）。

テスト分析プロセスにてブラックボックス、ホワイトボックス、および経験ベースのテスト技法を適用 することは（第 4 章を参照）、重要なテスト条件の欠落を防止し、精度と正確性が高いテスト条件の特 定に役立つ。

テスト分析では、テストチャーターのテスト目的として使用するテスト条件を作り出す場合がある。経 験ベースのテストの種類によっては、テストチャーターが典型的な作業成果物となる（4.4.2 節を参照）。 これらのテスト目的がテストベースに対して追跡可能な場合、経験ベースのテストにおけるカバレッジ の達成度を計測できる。

テスト分析で欠陥を検出できることは大きな利点だといえる。特に他のレビュープロセスが使用されて いない場合、および／またはテストプロセスがレビュープロセスと密接に関連付けられている場合に利 点となる。この場合、テスト分析では、要件に一貫性があり、適切に表現され、完全であることを検証 できるだけでなく、顧客、ユーザー、およびその他のステークホルダーのニーズが適切に要件に反映さ れていることの妥当性確認ができる。例えば、コーディングの前にユーザーストーリーや受け入れ基準 からテスト条件やテストケースを作成する振る舞い駆動開発（BDD）や受け入れテスト駆動開発 （ATDD）などの技法は、ユーザーストーリーや受け入れ基準を検証および妥当性確認をして、欠陥を検 出する（『ISTQB テスト技術者資格制度 Foundation Level Extension シラバス アジャイルテスト担当者 日本語版』を参照）。

 テストベースを分析して、テスト可能なフィーチャーを識別し、関連するテスト条件を定義して優先順位を付けるとともに、関連するリスクとリスクレベルを分析することを含む（5.2 節を参 照）。テストベースとテスト対象を評価し、それらに含まれている可能性のある欠陥を識別したり、試 験性のアセスメントをしたりする。テスト分析では、多くの場合、この活動を支援するためにテスト技 法を使用する(第 4 章を参照)。テスト分析では、計測可能なカバレッジ基準から見て「何をテストするか？」という問いに答えている。

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

2018年版2023年版
組織のテストプロセスに影響する状況のいくつかを次に示す（すべてが示されているわけではない）。
• 使用するソフトウェア開発ライフサイクルモデルとプロジェクト方法論
• 考慮対象のテストレベルとテストタイプ
• プロダクトとプロジェクトのリスク
• ビジネスドメイン
• 次を含む運用上の制約：
o 予算とリソース
o 期間
o 複雑さ
o 契約上および規制上の要件
• 組織のポリシーと実践例
• 要求される組織内の標準と組織外の標準		 テストは、単独で行うことはない。テスト活動は、組織内で行われる開発プロセスに不可欠な要素である。また、テストはステークホルダーによって資金提供され、その最終ゴールは、ステークホルダーのビジネスニーズの充足を支援することである。したがって、テストを行う方法は、以下のようないくつかのコンテキストに応じた要因に依存する：
•ステークホルダー（ニーズ、期待、要件、協力の意思など）。
•チームメンバー（スキル、知識、経験レベル、空き状況、トレーニングの必要性など）。
•ビジネスドメイン（テスト対象の重要性、識別したリスク、市場ニーズ、特定の法的規制な ど）。
•技術的要因（ソフトウェアの種類、プロダクトのアーキテクチャー、利用技術など）。
•プロジェクトの制約（スコープ、時間、予算、リソースなど）。
•組織的要因（組織構造、現行のポリシー、使用する実践例など）。
•ソフトウェア開発ライフサイクル（エンジニアリングの実践例、開発手法など）。
•ツール（利用可能な状況、使用性、標準適合性など）。

2018年版シラバスはこちら
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf

2018年版シラバスはこちら
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf