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

4．テスト活動のマネジメント（2018年版：テストマネジメント）

学習時間が225分から335分に変更になっています。

2023年版では、2018年版から以下のようにキーワードが追加・削除されています。

共通のキーワード	2023年版において削除された キーワード	2023年版において追加された キーワード
•欠陥マネジメント •欠陥レポート •開始基準 •終了基準 •プロダクトリスク •プロジェクトリスク •リスク •リスクレベル •リスクベースドテスト •テストアプローチ •テストコントロール •テストモニタリング •テスト計画書 •テスト計画 •テスト進捗レポート	•構成管理 •テスト見積り •テストマネージャー •テスト戦略 •テストサマリーレポート •テスト担当者	•リスク分析 •リスクアセスメント •リスクコントロール •リスク識別 •リスクマネジメント •リスク軽減 •テスト完了レポート •テストピラミッド •テストの四象限

構成の比較は以下の通りです。

2018年版	2023年版
5 テストマネジメント 5.1 テスト組織 5.1.1 独立したテスト 5.1.2 テストマネージャーとテスト担当者のタスク 5.2 テストの計画と見積り 5.2.1 テスト計画書の目的と内容 5.2.2 テスト戦略とテストアプローチ 5.2.3 開始基準と終了基準（準備完了（ready）の定義と完了（done）の定義） 5.2.4 テスト実行スケジュール 5.2.5 テスト工数に影響する要因 5.2.6 テスト見積りの技術 5.3 テストのモニタリングとコントロール 5.3.1 テストで使用するメトリクス 5.3.2 テストレポートの目的、内容、読み手 5.4 構成管理 5.5 リスクとテスト 5.5.1 リスクの定義 5.5.2 プロダクトリスクとプロジェクトリスク 5.5.3 リスクベースドテストとプロダクト品質 5.6 欠陥マネジメント	5 テスト活動のマネジメント 5.1 テスト計画 5.1.1 テスト計画書の目的と内容 5.1.2 イテレーションとリリース計画に対するテスト担当者の貢献 5.1.3 開始基準と終了基準 5.1.4 見積り技法 5.1.5 テストケースの優先順位付け 5.1.6 テストピラミッド 5.1.7 テストの四象限 5.2 リスクマネジメント 5.2.1 リスク定義とリスク属性 5.2.2 プロジェクトリスクとプロダクトリスク 5.2.3 プロダクトリスク分析 5.2.4 プロダクトリスクコントロール 5.3 テストモニタリング、テストコントロールとテスト完了 5.3.1 テストで使用するメトリクス 5.3.2 テストレポートの目的、内容、読み手 5.3.3 テストステータスの伝達 5.4 構成管理 5.5 欠陥マネジメント

順序も含め、全体に構成が変更されています。
2018年版の「テストマネジメント」が2023年版では「テスト活動のマネジメント」に変更されています。この変更は、テストの領域における管理と監督の焦点が、単に「テスト」そのものから、「テスト活動」全体へと広がったことを示しています。「テストマネジメント」はテストケースの作成、テストの実行など、比較的狭い範囲の活動を指しているのに対し、「テスト活動のマネジメント」は、テスト計画やテストプロセスの改善、リスク管理、リソース割り当て、スケジュール管理、ステークホルダーとのコミュニケーション、テスト成果物のレビューなど、テスト活動に関わる全範囲の活動をカバーしていると考えられます。つまりこの改定は、テスト活動全体を戦略的、効率的に管理する際の重要性を強調したと言えるでしょう。

内容はより体系的に再構成されており、テスト計画、リスクマネジメント、テストモニタリングとコントロールなどのセクションに分けられています。
テスト計画のセクションでは、イテレーションとリリース計画へのテスト担当者の貢献、テストケースの優先順位付け、見積り技法など、テスト計画のプロセスがより詳細に記述されています。

また2023年版では、テストピラミッドやテストの四象限など、新しい概念やツールが導入されています。さらに、リスク定義やリスク属性の詳細な説明が追加され、リスクマネジメントプロセスが詳細にわたって記述されています。

これらの変更は、テストプロセスの重要性が高まっている現代のソフトウェア開発環境に適応し、テストプロフェッショナルが新しいツール、技術、プロセスを効果的に活用できるようにするためのものと解釈できます。

5.1 テスト計画（2018年版：5.2 テストの計画と見積り）

5.2.1 テスト計画書の目的と内容（2018年版：5.2.1 テスト計画書の目的と内容）

【共通点】

・テスト計画書の目的と役割
両シラバスでテスト計画書がプロジェクトのテスト活動を概説し、テスト目的を達成するための手段を提供することが強調されています。

・テスト計画書の内容
テストの範囲、目的、リスク、リソースの調達といったテスト計画の要素が両シラバスに記載されています。

・リスクの考慮
両シラバスでリスクの識別とそれに基づく計画の調整の重要性が強調されています。

・文書化とコミュニケーション
テスト計画書がチームメンバーやステークホルダーとのコミュニケーション手段として機能することが強調されています。

・スタンダードの遵守
両方の文章でISO/IEC/IEEE 29119-3 標準に言及し、テスト計画のガイドラインとしてこの標準が参照されることが示されています。

【変更点】

・テスト計画の具体的なプロセスの詳細化
2023年版ではテストプロジェクトの概要、前提と制約、ステークホルダー、コミュニケーション方法、リスクレジスターなど、より具体的な計画要素が詳細に記載されています。

・テスト計画書の活用
2023年版ではテスト計画書がテスト担当者の思考をガイドし、将来の課題に向かい合うよう促す役割が明確にされています。

・テストアプローチと独立性
2023年版ではテストレベルやテストタイプ、テスト技法などのテストアプローチに関する具体的な内容が詳述されており、テストの独立性や必要なメトリックの収集についても言及されています。

・予算とスケジュール
2023年版ではテスト計画の予算設定とスケジューリングが明確に取り上げられています。

5.1.2 イテレーションとリリース計画に対するテスト担当者の貢献（2023年版のみ）

2023年版で新たに追加された内容です。要約は以下の通りです。

イテレーティブなSDLC（ソフトウェア開発ライフサイクル）では、リリース計画とイテレーション計画の２つの計画が行われる。リリース計画では、プロダクトのリリースに向けてプロダクトバックログの定義と再定義を行い、、大きなユーザーストーリーを小さなユーザーストーリーへと洗練する。この計画は全てのイテレーションのテストアプローチとテスト計画書の基礎となる。テスト担当者は、テスト可能なユーザーストーリーと受け入れ基準の作成、プロジェクトと品質のリスク分析、ユーザーストーリーに関連するテスト工数の見積り、テストアプローチの決定、リリースのためのテスト計画に関与する。

イテレーション計画では、各イテレーションの終わりを見据えてイテレーションバックログを考慮し、ユーザーストーリーの詳細なリスク分析に参加する。テスト担当者は、ユーザーストーリーの試験性を判断し、それをタスク（特にテストタスク）に分解し、テストタスクの工数を見積り、テスト対象の機能的及び非機能的側面を識別し洗練する。

5.1.3 開始基準と終了基準（2018年版：5.2.3 開始基準と終了基準（準備完了（ready）の定義と完了（done）の定義））

【共通点】

・開始基準と終了基準の定義
両シラバスで開始基準と終了基準の役割が強調されており、特定のテスト活動やソフトウェア開発活動を効果的に管理するための事前条件や完了条件を定義することが説明されています。

・リスク管理
開始基準が満たされていない場合のリスクが高まる点と、これによりプロジェクトの難易度が増し、コストと時間が増加する可能性があることが両シラバスで指摘されています。

・テスト活動の管理
テスト活動の開始と終了を適切に管理することの重要性が強調されており、テストプロセス全体の質と効率を確保するために必要な手順が説明されています。

【変更点】

・文書の詳細度と内容の範囲
2018年版では、開始基準と終了基準の具体的な例としてテスト可能な要件、ユーザーストーリー、モデルの準備、テスト環境の準備などが挙げられています。対して2023年版ではリソースの可用性やテストウェアの可用性、初期品質レベルなど、より広範な要素が開始基準の例として提供されています。

・終了基準の具体例
2018年版では、終了基準として計画したテスト実行の完了、定義済みカバレッジの達成などが挙げられています。2023年版では、終了基準として徹底度の測定（カバレッジレベル、未解決欠陥の数など）と、予算切れや時間切れも終了基準として認められる場合があると述べられており、これは2018年版では触れられていない点です。

・アジャイル開発への言及
2023年版ではアジャイル開発の文脈で「完了（done）の定義」と「準備完了（Ready）の定義」という用語が特に強調されており、開発およびテスト活動に対するアプローチが具体的に言及されています。

これらの比較から、2023年版はより現代的な開発環境、特にアジャイル開発のプラクティスを反映しており、リソースの可用性や初期品質レベルの管理など、より詳細で広範なガイドラインを提供しています。一方、2018年版はより伝統的なテストマネジメントのアプローチを取り、具体的なテスト活動とその計画に焦点を当てています。

5.1.4 見積り技法（2018年版：5.2.6 テスト見積りの技術）

【共通点】

・見積りの重要性
両シラバスでテスト工数見積りがプロジェクト管理において重要であると強調されています。

・メトリクスと専門家の知識の使用
メトリクスに基づく見積りと専門家の経験を利用するアプローチが両シラバスで言及されています。

・アジャイル開発への適用
両シラバスでアジャイル開発の文脈での見積り技術が取り上げられ、バーンダウンチャートやプランニングポーカーなどの具体例が挙げられています。

【変更点】

・見積り技術の範囲と詳細度
2018年版では一般的な2つのテクニック（メトリクスと専門家の知識）に焦点を当てており、アジャイルとシーケンシャル開発の例を交えて説明しています。
2023年版では、見積り技法を4つ挙げ（比率に基づく見積り、外挿、ワイドバンドデルファイ、三点見積り）、それぞれの方法の詳細な説明と適用例が提供されています。

・技術的な詳細と説明の深さ
2018年版は見積りのアプローチについての概要的な説明に留まっています。
2023年版は具体的な見積り方法や計算式を提供し、それぞれの見積り技法の利点と実施方法についてより詳細に説明しています。

・文脈と例の提供
2018年版はアジャイルとシーケンシャルのプロジェクトの例を挙げることで、見積り技法の適用を説明しますが、特定の計算方法や式は提供していません。
2023年版では、各見積り技法について具体的な計算方法や、プロジェクト実施時の実際の数値を使用した例を提供しており、理解を深めるための具体的な情報が豊富です。

5.1.5 テストケースの優先順位付け（2023年版のみ）

2023年版のみの内容です。要約は以下のとおりです。

テストケースの優先順位付けには、リスクベース、カバレッジベース、要件ベースの戦略が用いられる。これにより、最も重要なリスクをカバーするテストケースが最初に実行され、最も高いカバレッジを提供するテストが優先される。また、テスト実行の順序は、テストケースや機能の依存関係に基づいて調整されることがあり、リソースの可用性も考慮される必要がある。このプロセスは、テストケースが効果的に実行されるようにするために、テスト計画と実行スケジュールに組み込まれる。

なお2018年版では、「5.2.4 テスト実行スケジュール」の中で、テスト実行スケジュール全般を解説しつつ、テストケースの優先順位付けにも触れています。2023年版と同じく、テストケースの優先順位を定めることが重要であること、テストケース間の依存関係を考慮に入れる必要があること、テストケースの組み合わせとスケジュールはテスト活動の成功に不可欠であることが強調されています。

5.1.6 テストピラミッド

2023年版で新たに追加された内容です。要約は以下のとおりです。

テストピラミッドは、テストの自動化と工数配分を支援するモデルであり、さまざまなレベルのテストで異なるテストの粒度を示している。ピラミッドの各レイヤーは、テストの複雑さと実行速度が異なり、低いレイヤーでは小さくて速いテストが多く必要で、上位のレイヤーでは少数の大規模なエンドツーエンドテストが行われる。テストピラミッドの具体的なレイヤーには「ユニットテスト」、「サービステスト」、「UIテスト」などがあり、これらはテストの目的に応じて選ばれる。

5.1.7 テストの四象限

2023年版で新たに追加された内容です。要約は以下のとおりです。

テストの四象限モデルは、Brian Marickによって定義され、テストレベルとタイプをアジャイル開発に適合させるために視覚的に分類している。このモデルは、テストの適切なタイプとレベルが開発プロセス全体に統合されることを保証し、各ステークホルダーにテストタイプを明確に説明する方法を提供する。

5.2 リスクマネジメント（2018年版：5.5 リスクとテスト）

タイトルが、「リスクとテスト」から「リスクマネジメント」に変更されています。
2023年版では、導入文で次のように述べています。（要約）

リスクマネジメントは組織が目標達成の可能性を高め、製品品質を向上させ、ステークホルダーの信頼を確保するために重要であり、主にリスク分析とリスクコントロールの二つの活動から構成されている。リスク分析はリスクの特定と評価を含み、リスクコントロールはリスクの軽減と監視を行う。これらに基づきテスト活動を選択、優先付けし管理するアプローチをリスクベースドテストと呼ぶ。

5.2.1 リスク定義とリスク属性（5.5.1 リスクの定義）

それぞれのリスクの定義は以下の通りです。

2018年版	2023年版
リスクは、将来に否定的な結果となる事象が起きる恐れを含む。リスクのレベルは、そのような事象が 起きる可能性とその影響（事象による結果がもたらす損害）で決まる。	リスクとは、それらが顕在化することによって悪影響が生じる、潜在的な事象、ハザード、脅威、また は状況のことである。リスクは、2つの要素によって特徴づけられる： ・リスクの可能性-リスクが顕在化する確率（0 より大きく 1 より小さい） ・リスクの影響（損害）-この顕在化がもたらす結果 これら 2 つの要素は、リスクの尺度であるリスクレベルを表す。リスクレベルが高いほど、その処置は より重要である。

5.2.2 プロジェクトリスクとプロダクトリスク（2018年版：5.5.2 プロダクトリスクとプロジェクトリスク）

【共通点】

両シラバスで、プロダクトリスクとプロジェクトリスクについて説明されています。
どちらも、プロダクトリスクがプロダクトの品質に関連し、プロジェクトリスクがプロジェクトの実行に影響を及ぼす点を説明しています。

【変更点】

・詳細の程度：
2018年版はプロダクトリスクとプロジェクトリスクに関連する具体的な問題例を詳しく説明しており、実際のリスク事例に基づいています。
2023年版では、よりプロジェクトとプロダクトリスクの区別に重点を置き、両者が持つ可能性のある影響を詳しく説明しています。

・フォーカスの差：
2018年版では、 プロダクトリスクとプロジェクトリスクの具体的な例として、機能的な問題やシステムアーキテクチャの問題、非機能要件への対応不足などに触れています。
プロジェクトリスクについても具体的な問題点を挙げており、プロジェクト遂行上の問題（リリースの遅れ、資金不足、人間関係の問題など）や技術的な課題（テスト環境の準備遅延、データ変換の問題など）が詳細に説明されています。
ただし、これらのリスクが顕在化した場合の直接的な影響や結果については詳しく触れていません。

2023年版では、プロダクトリスクとプロジェクトリスクの区別はあるものの、プロダクトリスクが顕在化した場合の具体的な負の結果に大きく焦点を当てています。
ユーザーの不満足、収益や信頼の損失、第三者への損害賠償、刑事罰、さらには身体的な損害や死亡に至る重大な結果まで詳述しています。このアプローチは、リスクの顕在化がもたらす潜在的なリスクをより具体的かつ深刻なものとして提示し、ステークホルダーに対するリスクの深刻性を理解させることに注力しています。

5.2.3 プロダクトリスク分析

2023年版で新たに追加された内容です。要約は以下のとおりです。

プロダクトリスク分析の目的は、テストの工数をプロダクトリスクの残存レベルを最小化する方法に集中させるため、プロダクトリスクに関する認識を提供することである。この分析は、ソフトウェア開発ライフサイクル（SDLC）の初期段階で開始される。プロセスはリスク識別とリスクアセスメントの二つの主要部分で構成され、ステークホルダーは様々な手法を用いてリスクを識別し、その後、リスクの可能性、影響、レベルを評価して優先順位を設定し、対処法を提案する。このアセスメントは定量的、定性的、またはその両方のアプローチを含むことがある。プロダクトリスク分析の結果はテストの範囲、深さ、テスト工数の見積り、テストの優先順位付け、そしてリスクを低減するための追加活動の判断に影響を与える。

5.2.4 プロダクトリスクコントロール

2023年版で新たに追加された内容です。要約は以下のとおりです。

プロダクトリスクコントロールは、リスク軽減とリスクモニタリングから成り、識別されたプロダクトリスクに対応する措置を実施してリスクレベルを下げ、その効果を確認することを目的としている。リスクコントロールには、リスクの軽減、受け入れ、移転、およびコンティンジェンシー計画などの対応策が含まれる。具体的なテスト活動には、適切なスキルを持つテスト担当者の選定、テストの独立性の保持、レビューと静的解析の実施、適切なテスト技法とカバレッジレベルの適用、関連する品質特性に応じたテストタイプの選定、リグレッションテストを含む動的テストの実施が含まれる。

5.3 テストモニタリング、テストコントロールとテスト完了（2018年版：5.3 テストのモニタリングとコントロール）

・導入文

【共通点】

両シラバスともに、テストモニタリングがテスト進捗の評価やテスト終了基準の達成状況を確認するために重要であると述べています。またどちらも、テストに関連する情報を収集することの重要性に触れています。さらに両方とも、テストコントロールがテスト進行に関する調整や優先順位の見直しなどを行うために使用されると説明しています。

【変更点】

2018年版では、テストコントロールの具体的な例として「テスト環境や他のリソースの利用可否により、テストスケジュールを変更する」という点を挙げていますが、2023年版では「必要なときに必要な箇所へ新しいリソースを追加」というようにリソース追加のアクションも含めています。

2018年版はより詳細な例とステップを説明しているのに対し、2023年版はコントロールのための指示を提供する形式での説明が含まれており、テスト完了についての言及もあります。

5.3.1 テストで使用するメトリクス（2018年版・2023年版共通）

【共通点】

・テストメトリクスの用途：
両シラバスで、テストメトリクスがプロジェクトの進捗状況、テスト対象の現在の品質、テスト活動の効果を測定するために使用されることが説明されています。

・メトリクスのカテゴリー：
両シラバスで、プロジェクト進捗、テスト進捗、欠陥メトリクス、コストメトリクスなどのカテゴリーが含まれています。

・メトリクスの具体例：
テストケースの準備や実行、テスト環境の準備、欠陥情報など具体的なメトリクスが共通して挙げられています。

【変更点】

・メトリクスの詳細性：
2023年版では、より多様なメトリクスが提供されており、プロダクト品質やリスクメトリクスなど、より具体的で詳細なメトリクスの種類が述べられています。

・イテレーションゴールの言及：
2023年版では、テスト目的やイテレーションゴールに対するテスト活動の有効性を示すためのメトリクス収集が強調されていますが、2018年版ではそのような言及がありません。

・テストモニタリングとテストコントロールの言及：
2023年版では、テストメトリクスがテストモニタリングおよびテストコントロールを支援するために使われることが特に強調されています。

5.3.2 テストレポートの目的、内容、読み手（2018年版・2023年版共通）

【共通点】

・目的の共通性：
両シラバスで、テストレポートの目的がテスト活動に関する情報を要約し、ステークホルダーに伝達することとして説明されています。

・テスト進捗レポートとテスト完了レポート：
両シラバスで、テスト進捗レポートとテスト完了レポートの二種類のレポートが存在し、その用途が説明されています。

・テスト進捗レポートの構成：
テストの進捗、テスト計画書に対する進捗、テスト対象の品質など、テスト進捗レポートに含まれるべき内容が両シラバスで共通しています。

・ISO/IEC/IEEE 29119-3 標準の言及：
両シラバスで、ISO/IEC/IEEE 29119-3 標準に基づくテストレポートの構成と記載例が言及されています。

【変更点】

・テスト情報の詳細度：
2023年版では、テストの進捗レポートが頻繁に（毎日、毎週など）作成されるべきであり、テスト期間、進捗状況、テストに支障をきたすものおよびその回避策などの詳細な内容が説明されていますが、2018年版はこれらの項目についてやや一般的な記述にとどまっています。

・テスト進捗レポートの詳細
2018年版では、テスト活動の状況、進捗を妨げる要因、次の報告までの計画されたテスト、およびテスト対象の品質に関する情報を含む比較的具体的な内容を提供するとしています。2023年版では、テスト期間、進捗状況、支障とその回避策、新たに発生したリスク、および次の期間のテスト計画に焦点を当てています。また、テストメトリクスの具体的な例が述べられています。また2018年版では特定の形式や頻度について言及していないのに対し、2023年版では、テスト進捗レポートが定期的に（毎日、毎週など）作成されることを明示しており、これにより継続的なテスト管理とステークホルダーとのコミュニケーションが強調されています。2018年版では特にこの点についての言及がありません。

それぞれの内容例は以下の通りです。

2018年版	2023年版
• テスト活動の状況とテスト計画書に対する進捗 • 進捗を妨げている要因 • 次のレポートまでの間に計画されているテスト • テスト対象の品質	テスト期間 • テストの進捗状況（例：テストスケジュールの前倒し、遅れ）、顕著な逸脱を含む • テストに支障をきたすもの、およびその回避策 • テストメトリクス（例については 5.3.1 項参照） • テスト期間中に新たに発生したリスクと変更されたリスク • 次の期間でのテスト計画書

・テスト完了レポートの詳細：
2018年版では、「テスト完了レポート」は「テストサマリーレポート」と呼ばれ、テストプロジェクトのまとめを提供することが強調されています。2023年版では単に「テスト完了レポート」と呼ばれ、特定のテスト段階の完了を報告することに焦点が当てられています。

それぞれの内容例は、以下の通りです。

2018年版（テストサマリーレポート）	2023年版（テスト完了レポート）
• 行ったテストの要約 • テスト期間中に発生したこと • 計画からの逸脱（テスト活動のスケジュール、期間もしくは工数など） • 終了基準または完了（done）の定義に対するテストとプロダクト品質の状況 • 進捗を妨げた、または引き続き妨げている要因 • 欠陥、テストケース、テストカバレッジ、活動進捗、リソース消費のメトリクス（例えば、5.3.1 で示したメトリクス） • 残存リスク（5.5 節を参照） • 再利用可能なテスト作業成果物	• テスト概要 • 当初のテスト計画書に基づくテストとプロダクト品質の評価（すなわち、テスト目的と終了基 準） • テスト計画書からの逸脱（例：テストスケジュール、期間、労力などの計画との差異） • テストの阻害要因および回避策 • テスト進捗レポートに基づくテストメトリクス • 未解決のリスク、修正されなかった欠陥 • テストに関連する学習した教訓

5.3.3 テストステータスの伝達（2023年版のみ）

2023年版で新たに追加された内容です。要約は以下の通りです。

テストステータスの伝達手段は、テストマネジメントの懸念、組織の戦略、規制基準、またはチームの自律性に応じて異なる。選択肢には口頭でのコミュニケーション、ダッシュボード、電子的なコミュニケーションチャネル、オンラインドキュメント、正式なテストレポートなどがあり、これらを単独または組み合わせて使用することができる。特に分散型チームでは、形式的なコミュニケーションが必要とされることもあり、ステークホルダーの関心に応じてコミュニケーションを調整する必要がある。

5.4 構成管理（2018年版・2023年版共通）

【共通点】

・構成管理の基本目的：
両シラバスで構成管理の目的がプロジェクトやプロダクトのライフサイクルを通じてテストアイテムやテストウェアの完全性を確立し、維持することであると述べられています。

・識別とバージョンコントロール：
両シラバスともテストアイテムとテストウェアを一意に識別し、バージョンコントロールを行い、変更履歴を残し、アイテム間の関連付けを強調しています。

・トレーサビリティの維持：
テストプロセス全体を通してのトレーサビリティの維持が、どちらのバージョンでも重要視されています。

・ドキュメントとソフトウェアアイテムの記録：
識別されたすべてのドキュメントやソフトウェアアイテムをテストドキュメントに明確に記載することが両方に含まれています。

【変更点】

・構成管理の範囲の詳細：
2018年版では、 テストアイテムの一意識別、バージョンコントロール、変更履歴の保持、アイテム間の関連付けに重点を置いています。2023年版では、より広範な構成アイテムの管理を提案しており、テスト環境などの複雑な構成アイテムも含まれ、CMによってベースラインが確立され、正式な変更コントロールプロセスを通じてのみ変更が可能としています。

・ベースラインの管理への言及：
2023年版では、 新しいベースラインの作成と変更された構成アイテムの記録の保持、以前のベースラインへの復帰の可能性に言及しています。2018年版では、このトピックに関する言及はありません。

・DevOps との統合への言及：
2023年版では、 継続的インテグレーション、継続的デリバリー、継続的デプロイメントの文脈での自動化されたCMの実装に触れており、これが通常自動化した DevOps パイプラインの一部として含まれると説明しています。2018年版では、DevOpsや自動化に関する具体的な言及はありません。

これらの変更から、2023年版では構成管理の範囲が広がり、より現代的なソフトウェア開発プラクティスと統合されていることがうかがえます。これにより、よりダイナミックで複雑な開発環境における構成管理の重要性が強調されています。

5.5 欠陥マネジメント（2018年版：5.6 欠陥マネジメント）

【共通点】

・目的：
両方の文章で欠陥マネジメントの主要な目的は、欠陥を検出し、追跡し、解決することにあります。

・欠陥レポート：
欠陥の識別、記録、解決のための詳細なレポートが必要であるとしています。

・ステークホルダーの関与：
両シラバスで、欠陥マネジメントプロセスが関係するすべてのステークホルダーによって遵守される必要があるとされています。

【変更点】

・詳細度と例示：
2018年版では、欠陥レポートの具体的な内容に関してより詳細な説明が提供されており、具体的なレポートの要素や、静的テストで検出された欠陥の取り扱いに言及しています。
2023年版では、欠陥レポートの概要は記述されていますが、動的テストに特化し、静的テストの取り扱いについては簡潔に言及されています。

・偽陽性の取り扱い：
2018年版では、偽陽性の具体的な例（ネットワーク接続の切断やタイムアウトなど）と偽陽性がテスト結果に与える影響について詳細に言及しています。偽陽性を最小限に抑える必要があるとも述べられています。
2023年版では、偽陽性への言及が「本当の欠陥だと判明する場合もあれば、他の何か（例えば、偽陽性、変更要求）の場合もある」という形で簡潔に述べられており、詳細な例や影響についての言及はありません。

・欠陥マネジメントプロセスの記述の詳細度違い：
2018年版では、欠陥マネジメントプロセスについてより詳細に記述されており、具体的な関係者のリストが提供されています。また、非形式的な記録や追跡を行う組織についても言及しており、異なるアプローチが認められていることが示されています。
2023年版では、欠陥マネジメントプロセスがより一般的に記述されており、全てのステークホルダーが遵守すべき最低限のプロセス要素が述べられています。

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

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