diff --git a/.claude/skills/fix-mermaid/SKILL.md b/.claude/skills/fix-mermaid/SKILL.md index b1482776..9fece871 100644 --- a/.claude/skills/fix-mermaid/SKILL.md +++ b/.claude/skills/fix-mermaid/SKILL.md @@ -16,6 +16,34 @@ allowed-tools: # Mermaid v10 構文修正スキル +## 🚀 まず再利用スクリプトを使う（トークン節約・最優先） + +静的 HTML の Mermaid 描画崩れを直すときは、**ボイラープレート（render ループ・SVG 後処理・中央寄せ CSS）を手書きで再生成しないこと**。以下の再利用スクリプトで機械的処理を一括適用できる。 + +1. **図ソースを JS テンプレートリテラルで定義**（LLM の判断が必要なのはここだけ）: + 各図を 1 ステートメント 1 行・カラム 0・改行は `
` で `const DIAGRAMS = { 'diag-1': 'flowchart TD ...' }` として HTML の ` + + + +
+ + + + +
+ +
+
ISTQB CTFL v4.0.1 — Chapter 1 完全解説
+

+ テストの基礎
Fundamentals of Testing +

+

+ 本ガイドは ISTQB Certified Tester Foundation Level Syllabus + v4.0.1（2024年9月15日付）に準拠した、中級者〜上級者向けの体系的解説です。試験で問われる + LO 全 14 項目を網羅し、各概念の実務的な意味まで掘り下げます。 +

+
+
試験問題: 40問中 8問
+
K1×2 + K2×6
+
学習目安: 180分
+
合格基準: 65% (26/40)
+
+
+ + +
+
+
Section 0
+

Chapter 1 の全体像と学習目標

+
Overview & Learning Objectives
+
+ +
+

シラバスにおける位置づけ

+

+ Chapter 1 は CTFL v4.0 + 全体の語彙と思考モデルを提供する章です。ここで定義される用語は + Chapter 2〜6 + 全体で繰り返し使用されるため、理解の甘さが後続章の習得に直接影響します。 +

+
+
+
図 0-1 各 Chapter の依存関係と試験配点
+
+
+
試験戦略
+ Chapter 4（390分・12問）と Chapter 5（335分・10問）で試験の 55% + を占めます。Chapter 1 + の用語を固めておかないと、これらの章の問題文を正確に解釈できません。 +
+
+ +
+

学習目標 (Learning Objectives) 一覧

+

+ Chapter 1 には全 14 の LO があります。K1（記憶）= 2件、K2（理解）= 6件 + が試験の出題レベルです。 +

+
+
+
FL-1.1.1
+ K1 記憶 +
典型的なテスト目標を識別する
+
+
+
FL-1.1.2
+ K2 理解 +
テストとデバッグを区別する
+
+
+
FL-1.2.1
+ K2 理解 +
テストが必要な理由を例示する
+
+
+
FL-1.2.2
+ K1 記憶 +
テストと品質保証の関係を説明する
+
+
+
FL-1.2.3
+ K2 理解 +
根本原因・エラー・欠陥・故障を区別する
+
+
+
FL-1.3.1
+ K2 理解 +
7つのテスト原則を説明する
+
+
+
FL-1.4.1
+ K2 理解 +
各テスト活動と関連タスクを説明する
+
+
+
FL-1.4.2
+ K2 理解 +
+ コンテキストがテストプロセスに与える影響を説明する +
+
+
+
FL-1.4.3
+ K2 理解 +
テスト活動を支えるテストウェアを区別する
+
+
+
FL-1.4.4
+ K2 理解 +
トレーサビリティ維持の価値を説明する
+
+
+
FL-1.4.5
+ K2 理解 +
テストにおける異なるロールを比較する
+
+
+
FL-1.5.1
+ K2 理解 +
テストに必要な汎用スキルの例を示す
+
+
+
FL-1.5.2
+ K1 記憶 +
ホールチームアプローチの利点を説明する
+
+
+
FL-1.5.3
+ K2 理解 +
+ テストの独立性のメリット・デメリットを区別する +
+
+
+
+
+ + +
+
+
Section 1.1
+

テストとは何か

+
What is Testing?
+
+ +
+

テストの定義

+

CTFL v4.0 では、ソフトウェアテストを次のように定義しています。

+
+
公式定義 (CTFL v4.0.1 §1.1)
+ ソフトウェアテストとは、欠陥を発見し、ソフトウェア作業成果物の品質を評価するための一連の活動である。テストはソフトウェア品質を評価し、運用におけるソフトウェア故障のリスクを低減する。 +
+

+ 従来の「テスト = + ソフトウェアを実行して結果を確認する」という認識は誤解です。v4.0 + ではテストを以下の2次元で捉えます。 +

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
次元種別説明
実行有無動的テスト (Dynamic Testing)ソフトウェアを実際に実行して行うテスト
実行有無静的テスト (Static Testing) + ソフトウェアを実行せずに行うテスト（レビュー・静的解析） +
目的検証 (Verification) + システムが仕様を満たすか確認する — "Are we building the + product right?" +
目的妥当性確認 (Validation) + システムがユーザーのニーズを満たすか確認する — "Are we + building the right product?" +
+
+
+
+
図 1.1-1 テストの2次元分類
+
+
+ +
+

テスト目標 (Test Objectives) — FL-1.1.1

+

+ v4.0 + で定義される典型的なテスト目標は以下の9つです。試験では「どのシナリオがどの目標に該当するか」を問う問題が出題されます。 +

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
#テスト目標実務例
1 + 要件・ユーザーストーリー・設計・コードなどの作業成果物の評価 + 要件レビューで曖昧な仕様を検出する
2故障を引き起こし欠陥を発見する境界値テストでクラッシュを再現する
3 + テスト対象の必要なカバレッジを確保する + 命令カバレッジ 100% を達成する
4 + 不十分なソフトウェア品質のリスクレベルを低減する + リスクベーステストで重要機能を優先する
5 + 指定要件が満たされているかを検証する + 受け入れ基準に対するシステムテスト
6 + 契約・法的・規制上の要件への準拠を検証する + 医療機器の FDA 規制適合確認
7 + 意思決定に必要な情報をステークホルダーに提供する + テスト進捗レポートでリリース可否を判断
8テスト対象の品質への信頼を構築する本番リリース前の回帰テスト合格
9 + テスト対象が完全で期待通りに動作するかを妥当性確認する + UAT（ユーザー受け入れテスト）実施
+
+
+
コンテキスト依存
+ テスト目標はコンテキストによって変わります。テスト対象、テストレベル、リスク、SDLC、ビジネスコンテキストが影響します。 +
+
+ +
+

テストとデバッグの違い — FL-1.1.2

+

+ 試験最頻出の区別です。テストとデバッグは別の活動であり、通常別の担当者が行います。 +

+
+
+
+ 図 1.1-2 テスト → デバッグ → 確認テスト → 回帰テストのフロー +
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
活動担当目的
テスト (Testing)テスター故障を引き起こす / 欠陥を直接発見する
デバッグ (Debugging)開発者故障の原因（欠陥）を見つけて修正する
確認テスト (Confirmation Testing)テスター（初回テストと同じ人が望ましい）修正が効いたかを確認する
回帰テスト (Regression Testing)テスター修正が他の箇所に悪影響を与えていないかを確認する
+
+
+
試験の罠
+ 「テストが欠陥を見つけた」は日常語として正しいですが、ISTQB + 的には不正確です。正確には「テストが故障を観察し、そこから欠陥を推定した」です。テストは出力（故障）を見るのであって、コード（欠陥）を直接見ているわけではありません。 +
+
+
+ + +
+
+
Section 1.2
+

テストはなぜ必要か

+
Why is Testing Necessary?
+
+ +
+

テストの貢献 — FL-1.2.1

+

+ ソフトウェアは現代社会に深く組み込まれており、障害が発生すると金銭的損失・時間損失・ブランド毀損、最悪の場合は人命に関わる問題が生じます。テストは以下の観点でプロジェクト成功に貢献します。 +

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
貢献領域具体的価値
欠陥の早期発見 + 後工程で発見するよりも修正コストが大幅に低い（詳細は原則 + 3 参照） +
リスク低減 + 本番障害の発生確率を下げ、事業継続リスクを最小化する +
意思決定支援 + リリース可否判断のための客観的データをステークホルダーに提供する +
品質評価 + 現状の品質レベルを定量的に示し、改善活動の優先付けを支援する +
コンプライアンス + 規制・契約要件への適合を証明し、法的リスクを回避する +
欠陥予防 + 根本原因分析により、類似欠陥の将来的な発生を防止する +
+
+
+ +
+

テストと品質保証 (QA) の関係 — FL-1.2.2

+

+ v4.0 で最もよく混同される概念の一つです。QA + とテストは異なるレベルで機能します。 +

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
観点品質保証 (QA)テスト (Testing)
定義 + 品質要件が満たされるという信頼を提供するプロセス指向の活動 + 品質を評価し欠陥を発見するための活動
種別プロアクティブ（予防的）リアクティブ（検出的）
対象プロセス全体特定の作業成果物・製品
位置づけ品質管理 (QM) の一部品質コントロール (QC) の一形態
+
+
+
+
図 1.2-1 品質管理の階層構造
+
+
+ +
+

エラー・欠陥・故障・根本原因 — FL-1.2.3

+

+ CTFL v4.0 + 試験で最も頻繁に問われる概念の連鎖です。ISO/IEC/IEEE + 29119 標準と整合した定義を使用します。 +

+
+
+
+ 図 1.2-2 根本原因 → エラー → 欠陥 → 故障の連鎖 +
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
用語英語定義実例（ECサイト購入処理）
根本原因Root Cause問題発生の根本的な理由 + 要件定義書に税率の取り扱い仕様が記載されていなかった +
エラーError / Mistake誤った結果を生み出す人間の行為開発者が税率の計算ロジックを逆に実装
欠陥Defect / Bug / Faultコンポーネントや成果物の不備 + コード中の tax * price が + price / tax になっている +
故障Failureテスト対象が期待した範囲で動作しないこと決済確認画面で表示金額が正しくない
+
+
+
根本原因分析の重要性
+ 根本原因分析 (Root Cause Analysis) + を実施することで、類似した故障・欠陥の将来的な発生を防止できます。これはテストの「欠陥予防」という目標に直結します。 +
+
+
v4.0 用語の注意
+ 旧来の ISTQB 資料では fault が + defect の同義語として使われていました。v4.0 では + defect + が優先用語ですが、試験では両方が使われる可能性があります。また日常語の + "bug" は ISTQB 用語では defect + の同義語であり、failure（故障）ではありません。 +
+
+
+ + +
+
+
Section 1.3
+

テストの7原則

+
Testing Principles — FL-1.3.1
+
+ +

+ v4.0 + で定義される7つのテスト原則は、すべてのテスト活動に適用される汎用ガイドラインです。試験では「このシナリオはどの原則に該当するか」という適用問題が出ます。暗記だけでなく、シナリオへの適用練習が必須です。 +

+ +
+
+
図 1.3-1 7つのテスト原則の概要
+
+ +
+
+
1
+
+
+ テストは欠陥の存在を示すが、欠陥の不在は証明できない +
+
+ Testing shows the presence, not the absence of defects +
+

+ テストで欠陥が見つかったとしても、すべての欠陥が発見されたとは言えない。テストに合格しても「欠陥ゼロ」の証明にはならない。
実務的意味: + リリース判断はテスト結果 + リスク評価の総合判断が必要。 +

+ 参照: Buxton 1970 +
+
+
+
2
+
+
網羅的なテストは不可能
+
+ Exhaustive testing is impossible +
+

+ 境界値・入力値の組み合わせ・実行パスをすべてテストすることは（小規模なケースを除き）現実的でない。
対策: + リスクと優先度に基づいてテスト範囲を絞り込む（リスクベーステスト）。 +

+ → リスクベーステスト (Ch.5) に直結 +
+
+
+
3
+
+
早期テストが時間とコストを節約する
+
+ Early testing saves time and money +
+

+ 欠陥の発見が遅れるほど修正コストは指数的に増大する。 +

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
フェーズ修正コストの相対値
要件定義1×
設計3〜6×
実装10×
テスト15〜40×
本番リリース後40〜1000×
+
+ → Shift-Left アプローチ (Ch.2) に直結 +
+
+
+
4
+
+
欠陥はクラスタリングする
+
Defects cluster together
+

+ 少数のモジュールやコンポーネントに欠陥が集中する傾向がある（パレートの法則: + 80% の欠陥は 20% + のモジュールに存在）。予測された欠陥クラスターと実際のクラスターは、リスクベーステストの重要な入力となる。
実務的意味: + 過去に欠陥が多く見つかった箇所を重点的にテストする。 +

+ → リスクベーステスト (Ch.5) に直結 +
+
+
+
5
+
+
+ テストは劣化する（農薬のパラドックス） +
+
+ Tests wear out (Pesticide Paradox) +
+

+ 同じテストを繰り返すと、新たな欠陥を発見する能力が低下する（Beizer + 1990）。農薬を同じ方法で使い続けると害虫が耐性を持つのと同じ構造。
対策: + テストケースを定期的に見直し、新しいテストを追加する。
例外: + 自動化された回帰テストは「既知の動作確認」が目的なので、繰り返しても有効。 +

+ 参照: Beizer 1990 +
+
+
+
6
+
+
テストはコンテキスト依存
+
Testing is context dependent
+

+ 普遍的に通用するテストアプローチは存在しない（Kaner 2011）。 +

+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
コンテキスト例テストの特徴
医療機器（安全クリティカル）形式的な文書・高い独立性・規制準拠
スタートアップのWebアプリ探索的テスト・CI/CD統合・スピード優先
金融システム + セキュリティ・パフォーマンス・コンプライアンス重視 +
組み込みシステムリアルタイム制約・ハードウェア連携テスト
+
+ 参照: Kaner 2011 +
+
+
+
7
+
+
欠陥不在の誤謬
+
Absence-of-defects fallacy
+

+ テストに全合格しても、ユーザーのニーズを満たすシステムが出来上がるとは限らない。
具体例: + バグのない給与計算システムが、実際のビジネスルールと合っていない。
これは検証 + (Verification) だけでなく、妥当性確認 (Validation) + も必要であることを示す。 +

+ → 原則1 との組み合わせで頻出 +
+
+
+
+ + +
+
+
Section 1.4
+

テスト活動・テストウェア・テストの役割

+
Test Activities, Testware and Test Roles
+
+ +
+

7つのテスト活動とタスク — FL-1.4.1

+

+ v4.0 + のテストプロセスは7つの主要活動で構成されます。順次実行される場合もあれば、反復・並行実行される場合もあります。 +

+
+
+
+ 図 1.4-1 テストプロセスの7活動（点線 = + モニタリングと制御が全活動を横断） +
+
+
+
+
+ step + 1 +
+
+
テスト計画 (Test Planning)
+
+ テストの目的・アプローチ・リソース・スケジュールを定義する。リスク分析を行い、テスト範囲を決定する。 +
+
+ 主な成果物: テスト計画書、リスク登録簿 +
+
+
+
+
+ cross + ↕ +
+
+
+ テストのモニタリングと制御 (Test Monitoring & Control) +
+
+ 計画との乖離を継続的に追跡（モニタリング）し、是正措置を取る（制御）。全活動を横断して実施される。 +
+
+ 主な成果物: テスト進捗レポート、是正アクション +
+
+
+
+
+ step + 2 +
+
+
テスト分析 (Test Analysis)
+
+ テストベース（要件・設計書等）を分析し、テスト条件（何をテストするか）を特定する。テストベース内の欠陥もここで発見できる。 +
+
+ 主な成果物: テスト条件、欠陥レポート（テストベース内の不備） +
+
+
+
+
+ step + 3 +
+
+
テスト設計 (Test Design)
+
+ テスト条件をテストケースとテストデータに変換する。テスト技法（ブラックボックス・ホワイトボックス等）を適用する。 +
+
+ 主な成果物: テストケース、テストデータ、テストチャーター +
+
+
+
+
+ step + 4 +
+
+
+ テスト実装 (Test Implementation) +
+
+ テストケースをテスト手順・テストスクリプト・テストスイートに整理する。テスト環境の準備も含む。 +
+
+ 主な成果物: + テスト手順（スクリプト）、テストスイート、テスト実行スケジュール +
+
+
+
+
+ step + 5 +
+
+
テスト実行 (Test Execution)
+
+ テスト手順を実際に実行し、期待結果と実際の結果を比較・記録する。欠陥が見つかれば報告する。 +
+
+ 主な成果物: テストログ、欠陥レポート（実行時の欠陥） +
+
+
+
+
+ step + 6 +
+
+
テスト完了 (Test Completion)
+
+ テスト活動を終了し、テストウェアを引き渡す。教訓・改善提案を文書化する。アーカイブ・廃棄の決定を行う。 +
+
+ 主な成果物: テスト完了レポート、改善提案、教訓 +
+
+
+
+ +
+ コンテキストがテストプロセスに与える影響 — FL-1.4.2 +
+

テストプロセスはプロジェクトのコンテキストによって大きく異なります。

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
影響要因具体例
SDLC モデル + ウォーターフォール（順次）/ アジャイル（反復）/ + DevOps（継続的） +
テスト対象の種類Webアプリ・組み込みシステム・モバイルアプリ
リスクレベル安全クリティカル（航空・医療）vs 一般業務システム
ビジネスコンテキスト + スピード重視（スタートアップ）vs + 規制準拠重視（金融・医療） +
チーム規模・スキル専任テスターあり vs 開発者がテストも兼任
+
+
+ +
+

テストウェア (Testware) — FL-1.4.3

+

+ テストウェアとは、テスト活動の成果として生成・維持されるあらゆる作業成果物の総称です。構成管理の対象となります。 +

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
テスト活動生成されるテストウェア
テスト計画テスト計画書、リスク登録簿
テスト分析テスト条件、欠陥レポート（テストベースの不備）
テスト設計テストケース、テストデータ、テストチャーター
テスト実装 + テスト手順（テストスクリプト）、テストスイート、テスト実行スケジュール +
テスト実行テストログ、欠陥レポート（実行時の欠陥）
テスト完了テスト完了レポート、改善アクションアイテム、教訓
+
+
+
テストウェアの管理
+ テストウェアは構成管理 (Configuration Management) + の対象であり、バージョン管理と変更追跡が必要です。Chapter + 5（§5.4）で詳述。 +
+
+ +
+

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

+

+ テストベース (Test Basis) + とは、テスト分析を行う際に参照するすべての情報（要件、ユーザーストーリー、設計書、コードなど）の総称です。 +

+
+
+
+ 図 1.4-2 テストベースからテスト結果へのトレーサビリティチェーン +
+
+

トレーサビリティを維持する価値:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
価値説明
影響分析 + 要件変更時に影響を受けるテストケースを即座に特定できる +
カバレッジ評価どの要件が十分にテストされているかを把握できる
進捗報告 + テスト結果を要件にひも付けてステークホルダーに報告できる +
監査対応テストの根拠を規制当局や顧客に証明できる
リスク管理リスクとテスト対応状況のひも付けが明確になる
+
+
+ +
+

テストにおけるロール — FL-1.4.5

+

+ v4.0 + ではテストの主要なロールを2つに整理しています。プロジェクト形態によって責務の分担が変わります。 +

+
+ + + + + + + + + + + + + + + + + + + + +
ロール主な責務代表的な活動
+ テスト管理ロール
Test Management Role + 		テスト全体の計画・統制・完了 + テスト計画・テストのモニタリングと制御・テスト完了・リソース管理・ステークホルダーへの報告 +
+ テストロール
Testing Role + 		具体的なテスト活動の実施 + テスト分析・テスト設計・テスト実装・テスト実行・欠陥報告 +
+
+
+
+
+ 図 1.4-3 プロジェクト形態によるロールの違い +
+
+
+
+ + +
+
+
Section 1.5
+

テストに必要な本質的スキルと良い実践

+
+ Essential Skills and Good Practices in Testing +
+
+ +
+

汎用スキル — FL-1.5.1

+

テスターには技術スキルだけでなく、幅広い汎用スキルが求められます。

+
+
+ 🔬 +
分析的思考
+
+ 複雑な状況を分解し、欠陥の原因を推論する能力 +
+
+
+ 🎯 +
批判的思考
+
+ 前提を疑い、要件や設計の問題点を発見する能力 +
+
+
+ 💬 +
コミュニケーション
+
+ 欠陥報告の明確な記述・ステークホルダーとの対話 +
+
+
+ 🔍 +
好奇心と注意深さ
+
+ 「この部分はどう動くのか」を常に問いかける姿勢 +
+
+
+ 🤝 +
協調性
+
+ 開発者・PO・ユーザーとの建設的な関係構築 +
+
+
+ 📐 +
系統性
+
+ 網羅的で体系的なアプローチによるテスト実施 +
+
+
+ 🛠 +
テスト固有知識
+
+ テスト技法・プロセス・SDLC・ツール・欠陥分類 +
+
+
+ 🏢 +
ドメイン知識
+
+ テスト対象のビジネス・技術領域の深い理解 +
+
+
+
+ +
+

ホールチームアプローチ — FL-1.5.2

+

+ アジャイル開発から来た概念で、CTFL v4.0 + では特に重要視されています。品質保証を特定のロールだけの仕事にしない考え方です。 +

+
+
+
図 1.5-1 ホールチームアプローチの全体像
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
利点説明
品質の共同責任品質保証が特定の部門・ロールだけの仕事でなくなる
チームの効率向上 + 必要なスキルを持つメンバーが状況に応じてテスト活動に参加できる +
早期フィードバック + ビジネス代表者がアクセプタンス基準定義に早期から参加する +
コラボレーション促進テスターと開発者が共同でテスト自動化を構築する
+
+
+
重要な例外
+ ホールチームアプローチが常に適切とは限りません。安全クリティカルな領域など、高い独立性が必要な場合は例外です。FL-1.5.2 + は + K1（記憶）レベルですが、「利点を述べよ」と「例外を述べよ」の両方が問われます。 +
+
+ +
+

テストの独立性 — FL-1.5.3

+

+ 独立性とは、テスターが作業成果物の作者から切り離されている度合いです。独立性が高いほど、認知バイアスの影響が少なくなります。 +

+
+
+
図 1.5-2 独立性の4段階
+
+
+
+
+
独立性なし
+
作者自身がテスト
+
+ コードへの深い理解
+
+ スピードが速い
+
- 認知バイアスが最も強い
+
- 見落としが多い
+
+
+
+
一部独立
+
同一チームのピア
+
+ バランスの取れた知識
+
+ コンテキスト共有済み
+
- 部分的なバイアスが残る
+
- チーム内の忖度リスク
+
+
+
+
高い独立性
+
組織内の別チーム
+
+ 外部視点・客観的評価
+
+ 認知バイアス小
+
- コンテキスト習得に時間
+
- チーム間サイロ化リスク
+
+
+
+
非常に高い独立性
+
組織外部のテスター
+
+ 完全な客観性
+
+ 専門知識
+
- コスト高
+
- コンテキスト習得困難
+
+
+
+
実務的結論
+ 多くのプロジェクトでは複数の独立性レベルを組み合わせるのが最善です。例: + 開発者が単体テストを実施（独立性なし）し、独立した QA + チームがシステムテストを実施（高い独立性）する。 +
+
+
+ + +
+
+
Appendix A
+

用語集

+
Glossary — Chapter 1 Keywords
+
+

+ CTFL v4.0.1 Chapter 1 のキーワードはすべて K1 レベル（記憶）の試験対象です。以下の定義を確実に記憶してください。 +

+
+
+
Coverage
+
カバレッジ
+
テスト対象がどの程度テストされたかの割合
+
+
+
Debugging
+
デバッグ
+
欠陥の原因を特定・分析・除去するプロセス
+
+
+
Defect / Bug / Fault
+
欠陥
+
+ コンポーネントや成果物の不備。v4.0 では defect が優先語 +
+
+
+
Error / Mistake
+
エラー
+
誤った結果を生み出す人間の行為
+
+
+
Failure
+
故障
+
+ テスト対象が期待した範囲で実行されないこと（観察可能な症状） +
+
+
+
Quality
+
品質
+
+ 製品・サービスが明示的・暗黙的なニーズを満たす度合い +
+
+
+
Quality Assurance (QA)
+
品質保証
+
+ 品質要件が満たされるという信頼を提供するプロセス指向の活動 +
+
+
+
Root Cause
+
根本原因
+
+ 問題発生の根本的な理由。根本原因分析で特定する +
+
+
+
Test Analysis
+
テスト分析
+
+ テストベースを評価し、テスト条件を特定する活動 +
+
+
+
Test Basis
+
テストベース
+
+ テスト分析の根拠となる情報（要件・設計書・ユーザーストーリー等） +
+
+
+
Test Case
+
テストケース
+
+ 事前条件・入力値・期待結果・事後条件のセット +
+
+
+
Test Completion
+
テスト完了
+
+ テスト活動を終了しテスト成果物を引き渡す活動 +
+
+
+
Test Condition
+
テスト条件
+
+ テストの根拠となる、テスト対象の測定可能な側面 +
+
+
+
Test Control
+
テスト制御
+
テスト計画との乖離を是正するための行動
+
+
+
Test Data
+
テストデータ
+
テスト実行時に使用する入力データ
+
+
+
Test Design
+
テスト設計
+
+ テスト条件をテストケース・手順に変換する活動 +
+
+
+
Test Execution
+
テスト実行
+
+ テストケースを実際に動作させ結果を記録する活動 +
+
+
+
Test Implementation
+
テスト実装
+
+ テストケースをテスト手順にまとめ実行可能な状態にする活動 +
+
+
+
Test Monitoring
+
テストのモニタリング
+
テスト活動の進捗を継続的に確認する活動
+
+
+
Test Object
+
テスト対象
+
+ テストの対象となるコンポーネント・システム・成果物 +
+
+
+
Test Objective
+
テスト目標
+
テスト活動の目的・目標
+
+
+
Test Planning
+
テスト計画
+
+ テストの目的・アプローチ・リソース等を定義する活動 +
+
+
+
Test Procedure
+
テスト手順
+
+ テストケースを実行順に並べた手順書（テストスクリプト） +
+
+
+
Test Process
+
テストプロセス
+
テスト計画〜テスト完了までの一連の活動
+
+
+
Test Result
+
テスト結果
+
テストケース実行後の実際の出力
+
+
+
Testing
+
テスト
+
欠陥発見と品質評価のための一連の活動
+
+
+
Testware
+
テストウェア
+
+ テスト活動の成果として生成・維持される作業成果物 +
+
+
+
Traceability
+
トレーサビリティ
+
+ テストベースと他の成果物の関係を追跡できる性質 +
+
+
+
Validation
+
妥当性確認
+
+ システムがユーザーニーズを満たすかを確認すること +
+
+
+
Verification
+
検証
+
+ システムが仕様要件を満たすかを確認すること +
+
+
+
+ + +
+
+
Appendix B
+

試験対策チェックリスト

+
Exam Preparation Checklist
+
+

+ 以下の項目をすべて説明できるかを確認してください。試験本番前に全項目にチェックを入れることを目標にしてください。 +

+ +
1.1 テストとは何か
+
    +
  • テスト目標を9つすべて列挙・説明できる
    • +
  • 動的テストと静的テストの違いを説明できる
    • +
  • + 検証 (Verification) と妥当性確認 (Validation) の違いを、"build it right" + / "right thing" で説明できる +
    • +
  • テストとデバッグのプロセスの違いをフロー形式で説明できる
    • +
  • 確認テストと回帰テストの役割の違いを区別できる
    • +
+ +
1.2 テストはなぜ必要か
+
    +
  • エラー・欠陥・故障・根本原因の連鎖を具体例を使って説明できる
    • +
  • + 品質保証 (QA) とテストの違いをプロセス指向・製品指向の観点で説明できる +
    • +
  • テストが成功に貢献する方法を4つ以上挙げられる
    • +
  • 根本原因分析がなぜ欠陥予防につながるかを説明できる
    • +
+ +
1.3 テストの7原則
+
    +
  • 7つのテスト原則を名称（英語名含む）と説明をセットで言える
    • +
  • + 各原則を具体的なシナリオに適用できる（例: 農薬パラドックス → + 回帰テストの見直し） +
    • +
  • 「欠陥不在の誤謬」が妥当性確認の重要性とどう繋がるかを説明できる
    • +
  • + 「早期テスト（原則3）」が Shift-Left + アプローチとどう繋がるかを説明できる +
    • +
+ +
+ 1.4 テスト活動・テストウェア・テストのロール +
+
    +
  • 7つのテスト活動を順番通りに挙げ、各活動の主な成果物を言える
    • +
  • テストベースとテストウェアを区別できる
    • +
  • トレーサビリティ維持の5つの価値を説明できる
    • +
  • テスト管理ロールとテストロールの責務を区別できる
    • +
  • コンテキストがテストプロセスに与える影響の例を3つ以上挙げられる
    • +
+ +
1.5 本質的スキルと良い実践
+
    +
  • ホールチームアプローチの利点を4つ以上説明できる
    • +
  • + ホールチームアプローチが適切でない場合（安全クリティカル等）を説明できる +
    • +
  • 4段階の独立性レベルを各メリット・デメリットとともに説明できる
    • +
  • 「独立性は高いほどよい」が誤りである理由を説明できる
    • +
+
+ + +
+
+
Appendix C
+

参照リソース

+
References & Sources
+
+

本ガイドの作成に使用した一次・二次情報源のすべてを以下に示します。

+
+
+
📄
+
+
+ ISTQB CTFL Syllabus v4.0.1（公式シラバス PDF） +
+ https://istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf +
+ 一次情報。2024年9月15日付。試験の全出題根拠。 +
+
+
+
+
🌐
+
+
ISTQB CTFL v4.0 公式概要ページ
+ https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/ +
+ 試験概要・出題構成・ダウンロードリンク一覧。 +
+
+
+
+
📢
+
+
ISTQB CTFL v4.0 リリースアナウンス
+ https://istqb.org/istqb-releases-certified-tester-foundation-level-v4-0-ctfl/ +
+ v4.0 改訂の背景・主要変更点・設計思想の説明。 +
+
+
+
+
📖
+
+
ISTQB 公式グロッサリー
+ https://glossary.istqb.org/en_US/search?term= +
+ 全用語の公式定義を検索できるオンラインツール。 +
+
+
+
+
🎓
+
+
+ CTFL v4.0 Chapter-by-Chapter Syllabus Deep Dive +
+ https://www.istqb.guru/ctfl-v4-syllabus-chapter-by-chapter-deep-dive/ +
+ 各章の試験ポイントと適用問題の解説（2026年最終更新）。 +
+
+
+
+
🔍
+
+
+ Defect vs Failure vs Error vs Mistake: ISTQB Distinctions +
+ https://www.istqb.guru/defect-vs-failure-vs-error-vs-mistake-istqb/ +
+ 試験頻出の用語区別を深掘りした解説（2026年）。 +
+
+
+
+
📋
+
+
+ ISTQB CTFL v4.0 Certification Guide 2026 +
+ https://www.istqb.com/ctfl-v4-0/ +
+ 試験ガイド・章別学習時間・受験情報（2026年5月21日確認）。 +
+
+
+
+
📑
+
+
+ Overview of ISTQB CTFL v4.0 (testing101.net) +
+ https://www.testing101.net/post/overview-of-the-istqb-certified-tester-foundation-level-ctfl-v4-0-new +
+ v3.1 から v4.0 への変更点・章別問題数の詳細解説（2025年）。 +
+
+
+
+
📚
+
+
+ ISTQB Glossary 2026: 200+ Testing Terms Explained +
+ https://www.istqb.guru/istqb-glossary/ +
+ 用語の波別学習アドバイスと効率的な暗記法（2026年）。 +
+
+
+
+ +
+
バージョン情報
+ 本ガイドは ISTQB CTFL Syllabus + v4.0.1（2024-09-15）に準拠しています。v4.0.1 は v4.0 + の著作権・ロゴ更新のみで、試験出題内容に変更はありません。v3.1 + シラバスは英語試験について + 2024年5月9日 をもって終了しています。 +
+
+
+
+ + + + + diff --git a/Ctfl-v4-chapter1-fundamentals.md b/Ctfl-v4-chapter1-fundamentals.md new file mode 100644 index 00000000..14b3bd61 --- /dev/null +++ b/Ctfl-v4-chapter1-fundamentals.md @@ -0,0 +1,625 @@ +# ISTQB CTFL v4.0 Chapter 1: テストの基礎 + +## 中級者〜上級者向け完全解説ガイド + +> **対象バージョン:** ISTQB Certified Tester Foundation Level Syllabus v4.0.1 (2024-09-15) +> **試験配点:** Chapter 1 = 8問 / 40問 (K1×2, K2×6) +> **学習目安時間:** 180分 + +--- + +## 目次 + +1. [Chapter 1 の全体像と学習目標](#1-chapter-1-の全体像と学習目標) +2. [1.1 テストとは何か (What is Testing?)](#2-11-テストとは何か) +3. [1.2 テストはなぜ必要か (Why is Testing Necessary?)](#3-12-テストはなぜ必要か) +4. [1.3 テストの原則 (Testing Principles)](#4-13-テストの原則-7原則) +5. [1.4 テスト活動・テストウェア・テストの役割](#5-14-テスト活動テストウェアテストの役割) +6. [1.5 テストに必要な本質的スキルと良い実践](#6-15-テストに必要な本質的スキルと良い実践) +7. [用語集](#7-用語集) +8. [試験対策チェックリスト](#8-試験対策チェックリスト) +9. [参照リソース](#9-参照リソース) + +--- + +## 1. Chapter 1 の全体像と学習目標 + +### 1.1 シラバスにおける位置づけ + +Chapter 1 は CTFL v4.0 全体の「語彙と思考モデル」を提供する章です。ここで定義される用語は Chapter 2〜6 全体で繰り返し使用されるため、理解の甘さが後続章の習得に直接影響します。 + +```mermaid +flowchart TD + C1["Chapter 1: テストの基礎\n語彙・思考モデルの確立"] + C2["Chapter 2: SDLCとテスト"] + C3["Chapter 3: 静的テスト"] + C4["Chapter 4: テスト分析と設計"] + C5["Chapter 5: テスト活動の管理"] + C6["Chapter 6: テストツール"] + C1 --> C2 + C1 --> C3 + C1 --> C4 + C1 --> C5 + C1 --> C6 +``` + +### 1.2 学習目標 (Learning Objectives) 一覧 + +| LO ID | 認知レベル | 内容 | +|---|---|---| +| FL-1.1.1 | K1 | 典型的なテスト目標を識別する | +| FL-1.1.2 | K2 | テストとデバッグを区別する | +| FL-1.2.1 | K2 | テストが必要な理由を例示する | +| FL-1.2.2 | K1 | テストと品質保証の関係を説明する | +| FL-1.2.3 | K2 | 根本原因・エラー・欠陥・故障を区別する | +| FL-1.3.1 | K2 | 7つのテスト原則を説明する | +| FL-1.4.1 | K2 | 各テスト活動とタスクを説明する | +| FL-1.4.2 | K2 | コンテキストがテストプロセスに与える影響を説明する | +| FL-1.4.3 | K2 | テスト活動を支えるテストウェアを区別する | +| FL-1.4.4 | K2 | トレーサビリティ維持の価値を説明する | +| FL-1.4.5 | K2 | テストにおける異なるロールを比較する | +| FL-1.5.1 | K2 | テストに必要な汎用スキルの例を示す | +| FL-1.5.2 | K1 | ホールチームアプローチの利点を説明する | +| FL-1.5.3 | K2 | テストの独立性のメリット・デメリットを区別する | + +> K1 = 記憶 (Remember) / K2 = 理解 (Understand) / K3 = 適用 (Apply) + +--- + +## 2. 1.1 テストとは何か + +### 2.1 テストの定義 + +CTFL v4.0 では、ソフトウェアテストを次のように定義しています。 + +> **ソフトウェアテスト**とは、欠陥を発見し、ソフトウェア作業成果物の品質を評価するための一連の活動である。 + +#### 重要な視点の転換 + +従来の「テスト = ソフトウェアを実行して結果を確認する」という認識は **誤解** です。v4.0 ではテストを以下の2次元で捉えます。 + +| 次元 | 種別 | 説明 | +|---|---|---| +| 実行有無 | **動的テスト (Dynamic Testing)** | ソフトウェアを実際に実行して行うテスト | +| 実行有無 | **静的テスト (Static Testing)** | ソフトウェアを実行せずに行うテスト（レビュー・静的解析） | +| 目的 | **検証 (Verification)** | システムが仕様を満たすかを確認する ("Are we building the product right?") | +| 目的 | **妥当性確認 (Validation)** | システムがユーザーのニーズを満たすかを確認する ("Are we building the right product?") | + +```mermaid +flowchart LR + subgraph テスト全体 + direction TB + DT["動的テスト\n(ソフトウェアを実行)"] + ST["静的テスト\n(ソフトウェアを実行しない)\nレビュー・静的解析"] + end + subgraph 目的 + direction TB + VE["検証 (Verification)\n仕様通りに作られているか"] + VA["妥当性確認 (Validation)\n正しいものを作っているか"] + end + DT --> VE + DT --> VA + ST --> VE +``` + +### 2.2 テスト目標 (Test Objectives) + +v4.0 で定義される典型的なテスト目標は以下の9つです。試験では「どのシナリオがどのテスト目標に該当するか」を問う問題が出題されます。 + +| # | テスト目標 | 実務例 | +|---|---|---| +| 1 | 要件・ユーザーストーリー・設計・コードなどの作業成果物の評価 | 要件レビューで曖昧な仕様を検出する | +| 2 | 故障を引き起こし欠陥を発見する | 境界値テストでクラッシュを再現する | +| 3 | テスト対象の必要なカバレッジを確保する | 命令カバレッジ 100% を達成する | +| 4 | 不十分なソフトウェア品質のリスクレベルを低減する | リスクベーステストで重要機能を優先する | +| 5 | 指定要件が満たされているかを検証する | 受け入れ基準に対するシステムテスト | +| 6 | 契約・法的・規制上の要件への準拠を検証する | 医療機器のFDA規制適合確認 | +| 7 | 意思決定に必要な情報をステークホルダーに提供する | テスト進捗レポートでリリース可否を判断 | +| 8 | テスト対象の品質への信頼を構築する | 本番リリース前の回帰テスト合格 | +| 9 | テスト対象が完全でステークホルダーの期待通りに動作するかを妥当性確認する | UAT（ユーザー受け入れテスト）実施 | + +### 2.3 テストとデバッグの違い (FL-1.1.2) + +これは試験頻出の区別です。 + +```mermaid +flowchart TD + T1["テスト実行\n(Testing)"] + F["故障を観察\n(Failure observed)"] + DB1["デバッグ開始\n(Debugging)"] + DB2["欠陥の特定\n(Defect found)"] + DB3["欠陥の修正\n(Defect fixed)"] + CT["確認テスト\n(Confirmation Testing)"] + RT["回帰テスト\n(Regression Testing)"] + T1 --> F + F --> DB1 + DB1 --> DB2 + DB2 --> DB3 + DB3 --> CT + CT --> RT + + style T1 fill:#1a1a2e,stroke:#7c3aed,color:#e9d5ff + style DB1 fill:#1a1a2e,stroke:#0d9488,color:#99f6e4 + style DB3 fill:#1a1a2e,stroke:#0d9488,color:#99f6e4 + style CT fill:#1a1a2e,stroke:#7c3aed,color:#e9d5ff + style RT fill:#1a1a2e,stroke:#7c3aed,color:#e9d5ff +``` + +| 活動 | 担当 | 目的 | +|---|---|---| +| **テスト (Testing)** | テスター | 故障を引き起こす / 欠陥を直接発見する | +| **デバッグ (Debugging)** | 開発者 | 故障の原因（欠陥）を見つけて修正する | + +> **ポイント:** テストは「症状」を見つける活動。デバッグは「原因」を見つけて排除する活動。異なる人が行うのが原則です。 + +#### デバッグの典型的なプロセス + +1. 故障の再現 (Reproduction of a failure) +2. 診断：欠陥の特定 (Diagnosis / finding the defect) +3. 欠陥の修正 (Fixing the defect) + +修正後は **確認テスト (Confirmation Testing)** で修正が効いたかを確認し、さらに **回帰テスト (Regression Testing)** で修正が他の箇所に悪影響を与えていないかを確認します。 + +--- + +## 3. 1.2 テストはなぜ必要か + +### 3.1 テストの貢献 (FL-1.2.1) + +ソフトウェアは現代社会に深く組み込まれており、障害が発生すると金銭的損失・時間損失・ブランド毀損、最悪の場合は人命に関わる問題が生じます。テストは以下の観点でプロジェクト成功に貢献します。 + +| 貢献領域 | 具体的価値 | +|---|---| +| 欠陥の早期発見 | 後工程で発見するよりも修正コストが大幅に低い | +| リスク低減 | 本番障害の発生確率を下げる | +| 意思決定支援 | リリース可否判断のための客観的データを提供 | +| 品質評価 | 現状の品質レベルを定量的に示す | +| コンプライアンス | 規制・契約要件への適合を証明 | + +### 3.2 テストと品質保証 (QA) の関係 (FL-1.2.2) + +v4.0 でよく混同される重要な概念の区別です。 + +| 観点 | 品質保証 (QA) | テスト (Testing) | +|---|---|---| +| 定義 | 品質要件が満たされるという信頼を提供することに焦点を当てたプロセス指向の活動 | 品質を評価し欠陥を発見するための活動 | +| 種別 | プロアクティブ（予防的） | リアクティブ（検出的） | +| 対象 | プロセス全体 | 特定の作業成果物・製品 | +| 位置づけ | より広い品質管理 (QM) の一部 | 品質管理 (QC) の一形態 | + +```mermaid +flowchart TD + QM["品質管理 (Quality Management)"] + QA["品質保証 (Quality Assurance)\nプロセス指向・予防的\nISO/IEC 25010 等の標準準拠"] + QC["品質コントロール (Quality Control)\n製品指向・検出的"] + T["テスト (Testing)\nQCの一形態"] + QM --> QA + QM --> QC + QC --> T +``` + +### 3.3 エラー・欠陥・故障・根本原因 (FL-1.2.3) + +CTFL v4.0 試験で最も頻繁に問われる概念の一つです。ISO/IEC/IEEE 29119 標準と整合した定義を使用します。 + +```mermaid +flowchart LR + E["エラー (Error / Mistake)\n人間のミス\n例: 開発者が仕様を誤解して\n誤った変数名を使用"] + D["欠陥 (Defect / Bug / Fault)\nコード・ドキュメント内の欠陥\n例: コード中の誤った計算式"] + F["故障 (Failure)\n実行時の観察可能な不具合\n例: 合計金額が間違って表示される"] + RC["根本原因 (Root Cause)\n問題発生の根本的理由\n例: コードレビューが\n不十分だったプロセス"] + E -->|引き起こす| D + D -->|引き起こす| F + RC -->|根本的に引き起こす| E + + style E fill:#1a1a2e,stroke:#f59e0b,color:#fef3c7 + style D fill:#1a1a2e,stroke:#ef4444,color:#fee2e2 + style F fill:#1a1a2e,stroke:#ef4444,color:#fee2e2 + style RC fill:#1a1a2e,stroke:#6366f1,color:#e0e7ff +``` + +| 用語 | 英語 | 定義 | 実例（ECサイト購入処理） | +|---|---|---|---| +| **エラー** | Error / Mistake | 誤った結果を生み出す人間の行為 | 開発者が税率の計算ロジックを逆に実装 | +| **欠陥** | Defect / Bug / Fault | コンポーネントや成果物の不備 | コード中の `tax * price` が `price / tax` になっている | +| **故障** | Failure | テスト対象が期待した範囲で動作しないこと | 決済確認画面で表示金額が正しくない | +| **根本原因** | Root Cause | 問題発生の根本的な理由 | 要件定義書に税率の取り扱い仕様が記載されていなかった | + +> **試験の罠:** 「テストが欠陥を見つけた」ではなく、正確には「テストが故障を観察し、そこから欠陥を推定した」です。テストは出力（故障）を見るのであって、コード（欠陥）を直接見ているわけではありません。 + +#### 根本原因分析の重要性 + +根本原因分析 (Root Cause Analysis) を実施することで、類似した故障や欠陥の将来的な発生を **防止** できます。これはテストの「欠陥予防」という目標に直結します。 + +--- + +## 4. 1.3 テストの原則 (7原則) + +v4.0 で定義される7つのテスト原則は、すべてのテスト活動に適用される汎用ガイドラインです。試験では「このシナリオはどの原則に該当するか」という適用問題が出ます。 + +```mermaid +flowchart TD + P1["原則1\nテストは欠陥の存在を示す\nが不在は証明できない"] + P2["原則2\n網羅的なテストは不可能"] + P3["原則3\n早期テストが時間とコストを節約"] + P4["原則4\n欠陥はクラスタリングする"] + P5["原則5\nテストは劣化する\n(農薬のパラドックス)"] + P6["原則6\nテストはコンテキスト依存"] + P7["原則7\n欠陥不在の誤謬"] + + P1 --- P2 + P2 --- P3 + P3 --- P4 + P4 --- P5 + P5 --- P6 + P6 --- P7 +``` + +### 原則 1: テストは欠陥の存在を示すが、欠陥の不在は証明できない + +- テストで欠陥が見つかったとしても、すべての欠陥が発見されたとは言えない +- テストに合格しても「欠陥ゼロ」の証明にはならない +- **実務的意味:** リリース判断はテスト結果 + リスク評価の総合判断が必要 + +### 原則 2: 網羅的なテストは不可能 (Exhaustive testing is impossible) + +- 境界値・入力値の組み合わせ・実行パスをすべてテストすることは（小規模なケースを除き）現実的でない +- **対策:** リスクと優先度に基づいてテスト範囲を絞り込む（リスクベーステスト） + +### 原則 3: 早期テストが時間とコストを節約 (Early testing saves time and money) + +- 欠陥の発見が遅れるほど修正コストは指数的に増大する +- 要件フェーズで見つけた欠陥の修正コスト vs 本番で見つけた場合の差は10〜100倍になることもある + +| フェーズ | 修正コストの相対値 | +|---|---| +| 要件定義 | 1× | +| 設計 | 3〜6× | +| 実装 | 10× | +| テスト | 15〜40× | +| 本番リリース後 | 40〜1000× | + +### 原則 4: 欠陥はクラスタリングする (Defects cluster together) + +- 少数のモジュールやコンポーネントに欠陥が集中する傾向がある（パレートの法則） +- **実務的意味:** 過去に欠陥が多く見つかった箇所を重点的にテストする + +### 原則 5: テストは劣化する (Tests wear out) — 農薬のパラドックス + +- 同じテストを繰り返すと、新たな欠陥を発見する能力が低下する +- **対策:** テストケースを定期的に見直し、新しいテストを追加する +- **例外:** 自動化された回帰テストは目的が「既知の動作確認」なので、繰り返しても有効 + +### 原則 6: テストはコンテキスト依存 (Testing is context dependent) + +- 普遍的に通用するテストアプローチは存在しない +- 安全クリティカルシステム vs ECサイト、ウォーターフォール vs アジャイルで最適な手法が異なる + +| コンテキスト例 | テストの特徴 | +|---|---| +| 医療機器（安全クリティカル） | 形式的な文書・高い独立性・規制準拠 | +| スタートアップのWebアプリ | 探索的テスト・CI/CD統合・スピード優先 | +| 金融システム | セキュリティ・パフォーマンス・コンプライアンス重視 | +| 組み込みシステム | リアルタイム制約・ハードウェア連携テスト | + +### 原則 7: 欠陥不在の誤謬 (Absence-of-defects fallacy) + +- テストに全合格しても、ユーザーのニーズを満たすシステムが出来上がるとは限らない +- **具体例:** バグのない給与計算システムが、実際のビジネスルールと合っていない +- 検証 (Verification) だけでなく、妥当性確認 (Validation) も必要 + +--- + +## 5. 1.4 テスト活動・テストウェア・テストの役割 + +### 5.1 テスト活動とタスク (FL-1.4.1) + +v4.0 のテストプロセスは以下の7つの主要活動で構成されます。これらは順次実行される場合もあれば、繰り返し・並行実行される場合もあります。 + +```mermaid +flowchart LR + TP["テスト計画\n(Test Planning)"] + TM["テストのモニタリング\nと制御\n(Test Monitoring\n& Control)"] + TA["テスト分析\n(Test Analysis)"] + TD["テスト設計\n(Test Design)"] + TI["テスト実装\n(Test Implementation)"] + TE["テスト実行\n(Test Execution)"] + TC["テスト完了\n(Test Completion)"] + + TP --> TA + TM -.-> TP + TM -.-> TA + TM -.-> TD + TM -.-> TI + TM -.-> TE + TM -.-> TC + TA --> TD + TD --> TI + TI --> TE + TE --> TC + + style TM fill:#1a1a2e,stroke:#7c3aed,color:#e9d5ff +``` + +各活動の詳細： + +| 活動 | 主なタスク | 主な成果物 | +|---|---|---| +| **テスト計画** | テストの範囲・アプローチ・リソース・スケジュールの定義 | テスト計画書 | +| **テストのモニタリングと制御** | 進捗の追跡、逸脱時の是正措置 | テスト進捗レポート | +| **テスト分析** | テストベースを分析し、テスト条件を特定する | テスト条件、欠陥レポート（テストベース内の欠陥） | +| **テスト設計** | テスト条件をテストケース・テストデータに変換する | テストケース、テストチャーター | +| **テスト実装** | テストケースをテスト手順・テストスイートに整理する | テスト手順、テストスイート、テストスケジュール | +| **テスト実行** | テスト手順を実行し、結果を記録する | テストログ、欠陥レポート | +| **テスト完了** | テスト活動を終了し、教訓を文書化する | テスト完了レポート、改善提案 | + +### 5.2 コンテキストがテストプロセスに与える影響 (FL-1.4.2) + +テストプロセスはプロジェクトのコンテキストによって大きく異なります。影響要因の例： + +| 影響要因 | 具体例 | +|---|---| +| ソフトウェア開発ライフサイクル (SDLC) | ウォーターフォール、アジャイル、DevOps | +| テスト対象の種類 | Webアプリ、組み込み、モバイル | +| リスクレベル | 安全クリティカル vs 一般業務システム | +| ビジネスコンテキスト | 競争優位のためのスピード重視 vs 規制準拠重視 | +| チーム規模・スキル | 専任テスターあり vs 開発者がテストも兼任 | + +### 5.3 テストウェア (Testware) (FL-1.4.3) + +テストウェアとは、テスト活動の成果として生成・維持されるあらゆる作業成果物の総称です。 + +| テスト活動 | 生成されるテストウェア | +|---|---| +| テスト計画 | テスト計画書、リスク登録簿 | +| テスト分析 | テスト条件、欠陥レポート（テストベースの不備） | +| テスト設計 | テストケース、テストデータ、テストチャーター | +| テスト実装 | テスト手順（テストスクリプト）、テストスイート、テスト実行スケジュール | +| テスト実行 | テストログ、欠陥レポート（実行時の欠陥） | +| テスト完了 | テスト完了レポート、改善アクションアイテム、教訓 | + +> **テストウェアの管理:** テストウェアは **構成管理 (Configuration Management)** の対象であり、バージョン管理と変更追跡が必要です（Chapter 5で詳述）。 + +### 5.4 テストベースとテストウェア間のトレーサビリティ (FL-1.4.4) + +**テストベース (Test Basis)** とは、テスト分析を行う際に参照するすべての情報（要件、ユーザーストーリー、設計書、コードなど）の総称です。 + +```mermaid +flowchart TD + TB["テストベース\n(Test Basis)\n要件・設計書・ユーザーストーリー"] + TC2["テスト条件\n(Test Conditions)"] + TCS["テストケース\n(Test Cases)"] + TR["テスト結果\n(Test Results)"] + TB -->|分析| TC2 + TC2 -->|設計| TCS + TCS -->|実行| TR + TR -.->|トレーサビリティ| TB +``` + +トレーサビリティを維持する価値： + +| 価値 | 説明 | +|---|---| +| 影響分析 | 要件変更時に影響を受けるテストケースを即座に特定できる | +| カバレッジ評価 | どの要件が十分にテストされているかを把握できる | +| 進捗報告 | テスト結果を要件にひも付けてステークホルダーに報告できる | +| 監査対応 | テストの根拠を規制当局や顧客に証明できる | +| リスク管理 | リスクとテスト対応状況のひも付けが明確になる | + +### 5.5 テストにおけるロール (FL-1.4.5) + +v4.0 ではテストの主要なロールを2つに整理しています。 + +| ロール | 主な責務 | +|---|---| +| **テスト管理ロール (Test Management Role)** | テスト計画・テストのモニタリングと制御・テスト完了に関する活動全般 | +| **テストロール (Testing Role)** | テスト分析・テスト設計・テスト実装・テスト実行に関する活動全般 | + +#### アジャイルコンテキストでのロールの違い + +```mermaid +flowchart TD + subgraph 従来型プロジェクト + TM2["テストマネージャー\n専任"] + TR2["テスター\n専任または外部"] + end + subgraph アジャイルプロジェクト + TM3["チームメンバー全員\nテスト管理も分担"] + TR3["開発者・テスター・\nプロダクトオーナーが協力"] + end +``` + +| プロジェクト形態 | テスト管理ロール | テストロール | +|---|---|---| +| 従来型（ウォーターフォール） | 専任のテストマネージャー | 専任のテスター（内部・外部） | +| アジャイル | チームメンバー全員で分担 | 開発者・テスター・PO・QEが協力 | + +--- + +## 6. 1.5 テストに必要な本質的スキルと良い実践 + +### 6.1 テストに必要な汎用スキル (FL-1.5.1) + +テスターには技術スキルだけでなく、幅広い汎用スキルが求められます。 + +| スキルカテゴリ | 具体的スキル | +|---|---| +| **テスト固有の知識** | テスト技法、テストプロセス、SDLC、ツール、欠陥分類 | +| **ドメイン知識** | テスト対象のビジネス・技術領域の理解 | +| **分析的思考** | 複雑な状況を分解し、欠陥の原因を推論する能力 | +| **批判的思考** | 前提を疑い、要件や設計の問題点を発見する能力 | +| **コミュニケーション** | 欠陥報告の明確な記述、ステークホルダーとの効果的な対話 | +| **好奇心と注意深さ** | 「この部分はどう動くのか」を常に問いかける姿勢 | +| **協調性** | 開発者・PO・ユーザーとの建設的な関係構築 | +| **慎重さと系統性** | 網羅的で体系的なアプローチによるテスト実施 | + +### 6.2 ホールチームアプローチ (Whole Team Approach) (FL-1.5.2) + +アジャイル開発から来た概念で、CTFL v4.0 では特に重要視されています。 + +```mermaid +flowchart TD + subgraph ホールチームアプローチ + DE["開発者\n(Developer)"] + TE2["テスター\n(Tester)"] + PO["プロダクトオーナー\n(Product Owner)"] + BA["ビジネスアナリスト"] + OP["運用\n(Ops)"] + end + Q["品質は全員の責務\n(Quality = Everyone's Responsibility)"] + DE --> Q + TE2 --> Q + PO --> Q + BA --> Q + OP --> Q +``` + +ホールチームアプローチの主要な利点： + +| 利点 | 説明 | +|---|---| +| 品質の共同責任 | 品質保証が特定の部門・ロールだけの仕事でなくなる | +| チームの効率向上 | スキルを持つメンバーが状況に応じてテスト活動に参加できる | +| 早期フィードバック | ビジネス代表者がアクセプタンス基準定義に早期から参加 | +| コラボレーション促進 | テスターと開発者が共同でテスト自動化を構築 | + +> **重要:** ホールチームアプローチが常に適切とは限りません。安全クリティカルな領域など、高い独立性が必要な場合は例外です。 + +### 6.3 テストの独立性 (Independence of Testing) (FL-1.5.3) + +独立性とは、テスターが作業成果物の作者から切り離されている度合いです。 + +```mermaid +flowchart LR + L0["独立性なし\n作者自身がテスト"] + L1["一部独立\n同一チームのピアがテスト"] + L2["高い独立性\n組織内の別チームがテスト"] + L3["非常に高い独立性\n組織外部のテスターがテスト"] + + L0 --> L1 --> L2 --> L3 +``` + +| 独立性レベル | メリット | デメリット | +|---|---|---| +| 低（作者自身） | コードへの深い理解・スピード | 認知バイアスで見落としが多い | +| 中（同一チーム） | バランスの取れた知識 | 部分的なバイアスが残る | +| 高（組織内別チーム） | 外部視点・客観的評価 | コンテキスト理解に時間が必要 | +| 非常に高（外部組織） | 完全な客観性・専門知識 | コスト高・コンテキスト習得困難 | + +#### 独立性の価値と限界 + +**メリット:** + +- 作者と異なる認知バイアスを持つため、見落としていた欠陥を発見しやすい +- 要件の別解釈による欠陥を発見できる + +**デメリット:** + +- 独立したテスターは開発者ほどコードやシステムの詳細を知らない +- 開発チームとテストチームの間に「壁」（サイロ化）ができることがある +- 情報の引き継ぎに時間がかかる + +**実務的結論:** 多くのプロジェクトでは **複数の独立性レベルを組み合わせる** のが最善です（例: 開発者が単体テストを行い、独立したQAチームがシステムテストを行う）。 + +--- + +## 7. 用語集 + +| 用語（日本語） | 用語（英語） | 定義 | +|---|---|---| +| カバレッジ | Coverage | テスト対象がどの程度テストされたかの割合 | +| デバッグ | Debugging | 欠陥の原因を特定・分析・除去するプロセス | +| 欠陥 | Defect / Bug / Fault | コンポーネントや成果物の不備 | +| エラー | Error | 誤った結果を生み出す人間の行為 | +| 故障 | Failure | テスト対象が期待した範囲で実行されないこと | +| 品質 | Quality | 製品・サービスが明示的・暗黙的なニーズを満たす度合い | +| 品質保証 | Quality Assurance (QA) | 品質要件が満たされるという信頼を提供するプロセス指向の活動 | +| 根本原因 | Root Cause | 問題発生の根本的な理由 | +| テスト分析 | Test Analysis | テストベースを評価し、テスト条件を特定する活動 | +| テストベース | Test Basis | テスト分析の根拠となる情報（要件・設計書等） | +| テストケース | Test Case | 事前条件・入力値・期待結果・事後条件のセット | +| テスト完了 | Test Completion | テスト活動を終了しテスト成果物を引き渡す活動 | +| テスト条件 | Test Condition | テストの根拠となる、テスト対象の測定可能な側面 | +| テスト制御 | Test Control | テスト計画との乖離を是正する活動 | +| テストデータ | Test Data | テスト実行時に使用する入力データ | +| テスト設計 | Test Design | テスト条件をテストケース・手順に変換する活動 | +| テスト実行 | Test Execution | テストケースを実際に動作させ結果を記録する活動 | +| テスト実装 | Test Implementation | テストケースをテスト手順にまとめ実行可能な状態にする活動 | +| テストのモニタリング | Test Monitoring | テスト活動の進捗を継続的に確認する活動 | +| テスト対象 | Test Object | テストの対象となるコンポーネント・システム・成果物 | +| テスト目標 | Test Objective | テスト活動の目的・目標 | +| テスト計画 | Test Planning | テストの目的・アプローチ・リソース等を定義する活動 | +| テスト手順 | Test Procedure | テストケースを実行順に並べた手順書 | +| テストプロセス | Test Process | テスト計画〜テスト完了までの一連の活動 | +| テスト結果 | Test Result | テストケース実行後の実際の出力 | +| テスト | Testing | 欠陥発見と品質評価のための一連の活動 | +| テストウェア | Testware | テスト活動の成果として生成・維持される作業成果物 | +| トレーサビリティ | Traceability | テストベースと他の成果物の関係を追跡できる性質 | +| 妥当性確認 | Validation | システムがユーザーニーズを満たすかを確認すること | +| 検証 | Verification | システムが仕様要件を満たすかを確認すること | + +--- + +## 8. 試験対策チェックリスト + +Chapter 1 の試験対策として、以下のすべての項目を確実に説明できるかを確認してください。 + +### 1.1 テストとは何か + +- [ ] テスト目標を9つすべて列挙・説明できる +- [ ] 動的テストと静的テストの違いを説明できる +- [ ] 検証 (Verification) と妥当性確認 (Validation) の違いを説明できる +- [ ] テストとデバッグのプロセスの違いを図示できる +- [ ] 確認テストと回帰テストの役割を区別できる + +### 1.2 テストはなぜ必要か + +- [ ] エラー・欠陥・故障・根本原因の連鎖を具体例を使って説明できる +- [ ] 品質保証 (QA) とテストの違いを説明できる +- [ ] テストが成功に貢献する方法を複数挙げられる + +### 1.3 テストの原則 + +- [ ] 7つのテスト原則を名称と説明を含めてすべて言える +- [ ] 各原則を具体的なシナリオに適用できる +- [ ] 「農薬のパラドックス」とその対策を説明できる +- [ ] 「欠陥不在の誤謬」が妥当性確認の重要性とどう繋がるかを説明できる + +### 1.4 テスト活動・テストウェア・テストの役割 + +- [ ] 7つのテスト活動を順番通りに挙げ、各成果物を言える +- [ ] テストベースとテストウェアを区別できる +- [ ] トレーサビリティ維持の5つの価値を説明できる +- [ ] テスト管理ロールとテストロールの責務を区別できる + +### 1.5 本質的スキルと良い実践 + +- [ ] ホールチームアプローチの利点を4つ以上説明できる +- [ ] 4段階の独立性レベルを各メリット・デメリットとともに説明できる +- [ ] ホールチームアプローチが適切でない場合を説明できる + +--- + +## 9. 参照リソース + +| リソース | URL | 備考 | +|---|---|---| +| ISTQB CTFL v4.0 公式概要ページ | | 試験概要・出題構成 | +| ISTQB CTFL Syllabus v4.0.1 (PDF) | | 一次情報・全文PDF (2024-09-15) | +| ISTQB CTFL v4.0 リリースアナウンス | | v4.0 改訂の背景と主要変更点 | +| ISTQB 公式グロッサリー | | 用語の公式定義検索 | +| CTFL v4.0 Chapter-by-Chapter Deep Dive | | 各章の試験ポイント解説 (2026) | +| Defect vs Failure vs Error vs Mistake | | 頻出概念の詳細解説 (2026) | +| ISTQB CTFL v4.0 Certification Guide 2026 | | 試験ガイドと章別学習時間 | +| ISTQB CTFL v4.0 Overview (testing101.net) | | v3.1からv4.0への変更点解説 | +| ISTQB Glossary 2026: 200+ Testing Terms | | 用語の波別学習アドバイス | + +--- + +> **最終確認:** +> +> - 本ガイドは ISTQB CTFL Syllabus **v4.0.1** (2024-09-15) に準拠しています +> - v4.0.1 はv4.0の著作権・ロゴ更新のみで、試験出題内容に変更はありません +> - v3.1シラバスは英語試験について **2024年5月9日** をもって終了しています +> - 試験: 40問・60分・26問正解(65%)以上で合格 +> - Chapter 1 は全40問中 **8問** (K1×2, K2×6) diff --git a/Ctfl-v4-chapter2-sdlc-and-testing.html b/Ctfl-v4-chapter2-sdlc-and-testing.html new file mode 100644 index 00000000..8a5dfbd9 --- /dev/null +++ b/Ctfl-v4-chapter2-sdlc-and-testing.html @@ -0,0 +1,2080 @@ + + + + + + CTFL v4.0 Chapter 2: SDLCとテスト — 完全解説ガイド + + + + + + + + +
+ +
+
● CTFL Syllabus v4.0.1
+
ISTQB Certified Tester Foundation Level
+

Chapter 2: SDLCとテスト
完全解説ガイド

+
+ 対象: 中級〜上級エンジニア + 参照: Syllabus v4.0.1 (2024-09-15) + 推奨学習時間: 約80分 +
+
+
+ 7 + 試験問題数（全40問中） +
+
+ 5 + v4.0で新設/変更された項目 +
+
+ 3+4+5 + アプローチ+タイプ+レベル +
+
+
+ + +
+
+ § OVERVIEW +

Chapter 2 の全体像と試験戦略

+
+ +

+ Chapter 2はSDLC（Software Development + Lifecycle）の文脈においてテストをどう機能させるかを扱う。v4.0ではDevOps、Shift Left、TDD/BDD/ATDD、レトロスペクティブが新設された。さらに「統合テスト」がコンポーネント統合テストとシステム統合テストの2段階に分離された。 +

+ +
+
+
図1: Chapter 2 構造マップ
+
+ +
+ 試験戦略: Chapter + 2の問題は主にK2（理解）レベル。「定義の丸暗記」ではなく「シナリオを読んでどのレベル/タイプ/アプローチが適切かを判断する」力が問われる。v4.0の新設項目（DevOps + / Shift Left / BDD / 統合テストの分離）を重点的に押さえること。 +
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
セクション問題数K-レベルv4.0変更頻出トピック
2.1 SDLCのコンテキスト2問 + K1 + K2 + 新設多数DevOps特性、Shift Left手法
2.2 テストレベル/タイプ4問K2統合テスト分離各レベルの目的・テスト基盤・担当者
2.3 メンテナンステスト1問K2—変更の種類、インパクト分析
+
+
+ + +
+
+ § 2.1.1 +

SDLCモデルとテスト活動の影響

+
+ +

+ SDLCの選択はテストのあらゆる側面に影響する。シラバスはどのSDLCモデルが「優れているか」を問うのではなく、「テストをSDLCに適合させる方法」を問う。 +

+ +
+
+
図2: SDLCモデルの分類とテストへの影響
+
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
側面シーケンシャル（Waterfall/V-model）イテラティブ/インクリメンタル（Agile）
テストの開始時期後半フェーズが中心各イテレーション内で並行
静的テスト要件・設計レビューとして前半に実施各スプリントで継続的に実施
動的テストコード完成後に集中各スプリント内で完結
テスト文書詳細・フォーマル軽量・Just Enough
自動化の位置づけプロジェクト後半リグレッション防止として初期から
テスターの関与後半フェーズに集中要件定義から継続的に関与
+
+ +
+

V-model: テストレベルと開発フェーズの対応

+

+ V-modelはシーケンシャルモデルの代表例。左辺の各開発フェーズに右辺のテストレベルが対応し、テスト基盤（Test Basis）となる成果物が明示的に結びつく。 +

+
+
+
+ 図3: V-model — 開発フェーズとテストレベルの対応（v4.0の5レベル構成） +
+
+
+ v4.0の重要変更: V-modelの右辺は + v3.1の「統合テスト」1段階から、コンポーネント統合テストとシステム統合テストの2段階に分離された。これは試験頻出事項。 +
+
+
+ + +
+
+ § 2.1.2 +

良いテスト実践とSDLCへの統合

+
+

+ シラバスは「Good Testing + Practices（良いテスト実践）」として、SDLCモデルによらず適用できる4原則を定めている。 +

+ +
+
+
図4: 良いテスト実践の4原則
+
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
開発活動対応するテスト活動根拠
要件定義要件レビュー、受入基準作成欠陥の早期発見（Shift Left）
設計テスト設計（テスト条件の特定）アーキテクチャの問題を設計段階で検出
コーディングコンポーネントテスト、コードレビュー単体レベルの欠陥除去
統合統合テスト（コンポーネント統合/システム統合）インターフェース欠陥の検出
リリース受入テスト、リグレッションテストデプロイ判断の根拠取得
+
+
+ + +
+
+ § 2.1.3 +

テストファーストアプローチ v4.0 新設

+
+

+ 3つのアプローチはすべて「テストが開発を駆動する」という共通原則を持ち、Shift + Leftを実践する中核的手法。 +

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
アプローチ正式名称テスト記述者テスト形式目的
TDDTest-Driven Development開発者プログラミング言語のテストコードコード設計の改善
ATDDAcceptance Test-Driven Development開発者・テスター・ビジネス自然言語ベースの受入基準全員の共通理解を形成
BDDBehavior-Driven Development開発者・テスター・ビジネスGiven/When/Then 形式（Gherkin）システムの振る舞いを仕様化
+
+ +
+

TDD サイクル（Red-Green-Refactor）

+
+
+
図5: TDD の Red-Green-Refactor サイクル
+
+
+ +
+

BDD — Given/When/Then 形式（Gherkin）

+
+ 
Feature: ショッピングカートへの商品追加
+
+  Scenario: 在庫ありの商品をカートに追加する
+    Given ユーザーが商品詳細ページを閲覧している
+    When  ユーザーが「カートに追加」ボタンをクリックする
+    Then  カート内の商品数が1増加する
+    And   「カートに追加しました」のメッセージが表示される
+
+
+ +
+ 試験の落とし穴: + BDDはGiven/When/Then形式（Gherkin）を使用するが、ATDDは必ずしもこの形式を使わない。ATDDの本質は「受入基準からテストを派生させる」ことであり、フォーマットは問わない。 +
+
+ + +
+
+ § 2.1.4 +

DevOpsとテスト v4.0 新設

+
+

+ DevOpsは開発（テストを含む）とオペレーションが共通目標に向けて協働するための組織変革。技術的プラクティスに加え、文化的変革が必須であることがシラバスで明示されている。 +

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
特性説明テストへの影響
チームの自律性各チームがエンドツーエンドの責任を持つテスターが開発チームに埋め込まれる
高速フィードバックCIによる自動テスト実行数分以内に品質フィードバックを取得
統合ツールチェーンCI/CDパイプラインの自動化テスト自動化が必須インフラに
継続的インテグレーション（CI）コードの頻繁なマージ + 自動ビルド/テストリグレッション即時検出
継続的デリバリー（CD）常にリリース可能な状態を維持全テストレベルの高速化が前提
+
+ +
+

CI/CDパイプラインにおけるテストフロー

+
+
+
+ 図6: DevOps CI/CDパイプラインにおけるテストフロー +
+
+
+ +
+
+
メリット
+
+ 安定した環境（IaC）でのテスト
非機能テストのパイプライン組み込み
テストカバレッジの継続的可視化 +
+
+
+
リスク・課題
+
+ テスト自動化の初期構築コストが高い
手動テストの位置づけが不明確になりがち
パイプライン維持に専門知識が必要 +
+
+
+ +
+ 重要: + DevOpsは手動テストの廃止を意味しない。探索的テストなどの手動テストは依然として重要な役割を持つ。シラバスはこの点を明示的に述べている。 +
+
+ + +
+
+ § 2.1.5 +

シフトレフト（Shift Left） v4.0 新設

+
+

+ 「Early Testing saves time and + money」（テスト原則3番）の実践的手法。テスト活動をSDLCの早い段階に移動させることで欠陥検出コストを削減する。 +

+ +
+
+
図7: 従来アプローチ vs シフトレフト
+
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
手法タイミング目的
仕様・要件のレビュー要件定義フェーズ曖昧さ・矛盾の早期検出
コード実装前のテスト設計設計フェーズテスト容易性を設計に反映
CI/CDでの自動テストコミット時即時フィードバック
静的解析（Lint/SAST）コミット/ビルド時コード品質の継続的確認
TDD / ATDD実装フェーズテストによる設計駆動
+
+ +
+ 正しい理解: + シフトレフトは「後半テストをなくす」ことではなく、「前半にもテスト活動を追加する」ことで全体の品質を向上させる考え方。後半のシステムテストや受入テストは依然として必要。 +
+
+ + +
+
+ § 2.1.6 +

+ レトロスペクティブとプロセス改善 v4.0 新設 +

+
+

+ レトロスペクティブ（振り返り会議）はプロジェクト、フェーズ、リリース、またはイテレーションの終了時に実施し、テストプロセスの継続的改善に活用する。 +

+ +
+
+
図8: レトロスペクティブの構造と成果
+
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
議題例テスト観点での改善内容
テストカバレッジ不足していたテスト観点の特定と次回への反映
欠陥の傾向分析繰り返し発生する欠陥パターンの根本原因分析
テスト自動化手動で繰り返したテストの自動化候補の洗い出し
テスト環境の問題環境起因の障害への対策
テストプロセスの効率化テスト設計・実行の所要時間の見直し
+
+
+ + +
+
+ § 2.2.1 +

テストレベル（5段階） v4.0 変更

+
+

+ v4.0の重要変更: + v3.1では「統合テスト」1段階だったが、v4.0ではコンポーネント統合テストとシステム統合テストに分離され、計5段階構成になった。 +

+ +
+
+
図9: 5段階テストレベルの階層構造（v4.0）
+
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
属性コンポーネントコンポーネント統合システムシステム統合受入
目的個別コンポーネントの動作確認コンポーネント間IF確認システム全体の動作確認外部システムとの統合確認ビジネス要件を満たすか確認
テスト対象1コンポーネント/クラスコンポーネント群のIFシステム全体他システム・サードパーティとの結合システム全体（本番同等環境）
テスト基盤詳細設計、コンポーネント仕様IF設計、アーキテクチャ設計システム要件仕様システムIF設計ユーザー要件、ユースケース、契約
テスト担当者主に開発者開発者/テスターテスターテスター/統合チームユーザー/顧客/テスター
代表的な欠陥ロジックエラーIF不整合、データ変換エラー機能要件の未達、性能問題外部システムとの通信エラービジネス要件の未達
+
+ +
+

受入テストの4サブタイプ

+

受入テストはシラバスで特に詳しく定義されており、試験で問われやすい。

+
+
+
図10: 受入テストの4サブタイプ
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
サブタイプ略称実施者目的
ユーザー受入テストUAT実際のユーザー実際の利用シナリオでの検証
運用受入テストOATシステム管理者バックアップ・リカバリ・メンテナンス性確認
契約・規制受入テスト—テスター/外部監査契約条件・法規制・標準への準拠確認
アルファ/ベータテスト—限定ユーザー実際の利用環境での問題検出
+
+
+
+ + +
+
+ § 2.2.2 +

テストタイプ（4種類）

+
+

+ テストタイプは「何を評価するか」を定義する。テストレベルとは独立しており、すべてのテストレベルで全タイプを適用できる。 +

+ +
+
+
図11: 4つのテストタイプ
+
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
テストタイプ評価対象代表的な技法主なテスト基盤
機能テスト機能要件（完全性・正確性・適切性）同値分割、境界値分析、デシジョンテーブル要件仕様、ユースケース、ユーザーストーリー
非機能テスト品質特性（性能・セキュリティ・信頼性等）性能テスト、セキュリティテスト、ユーザビリティテスト性能要件、セキュリティ基準、UI仕様
ブラックボックス外部仕様との整合性（内部実装を見ない）同値分割、境界値分析、ユースケーステスト仕様書、要件
ホワイトボックス内部構造の網羅性ステートメント/ブランチカバレッジコード、アーキテクチャ図
+
+ +
+

非機能テストの品質特性（ISO/IEC 25010）

+
+
+
+ 図12: ISO/IEC 25010 品質特性と非機能テストの対応 +
+
+
+ +
+ 試験のポイント: + テストタイプはテストレベルとは独立。例えば「コンポーネントレベルで非機能テスト（単体レベルの性能計測）」も「システムレベルでホワイトボックステスト」も理論上は可能。これは試験でひっかけとして使われることがある。 +
+
+ + +
+
+ § 2.2.3 +

確認テストとリグレッションテスト

+
+

+ 欠陥修正後に実施する2種類のテスト。目的が異なるため、混同しないよう区別して理解する必要がある。 +

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
属性確認テスト (Confirmation Testing)リグレッションテスト (Regression Testing)
別名リテスト (Re-test)回帰テスト
目的欠陥修正が正しく行われたことを確認修正によって他の部分に影響が出ていないことを確認
実施タイミング欠陥修正後欠陥修正後、変更後、環境変更後
テスト範囲修正された欠陥に関連するテストのみ修正の影響範囲全体（場合によってはシステム全体）
自動化の推奨度低〜中（修正内容に依存）高（繰り返し実行のため）
+
+ +
+

欠陥修正後のテストフロー

+
+
+
+ 図13: 欠陥修正後の確認テスト・リグレッションテストフロー +
+
+
+ DevOps/Agile環境での推奨: + リグレッションテストはCI/CDパイプラインで自動実行することが強く推奨される。頻繁な変更に対応するためには手動実行は非効率。 +
+
+
+ + +
+
+ § 2.3 +

メンテナンステスト

+
+

+ システムのリリース後に行われるテスト活動。リリース前のテストとは異なる特性・課題を持つ。変更の種類とインパクト分析が中心概念。 +

+ +
+
+
+ 図14: メンテナンステストのトリガー（変更の4種類） +
+
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
変更の種類例テストの焦点リスクレベル
修正変更バグフィックスのパッチ適用確認テスト + 限定的リグレッション中
適応的変更OSバージョンアップ、クラウド移行互換性テスト + 全体リグレッション高
改善的変更新機能追加、UI刷新新機能テスト + 影響範囲のリグレッション中〜高
廃止・退役旧システムの廃止、データ移行データ移行テスト、並行稼働テスト高
+
+ +
+

インパクト分析（Impact Analysis）

+

+ メンテナンステストの計画において中核となるプロセス。変更の影響範囲を体系的に分析し、テスト範囲と優先順位を決定する。 +

+
+
+
図15: インパクト分析プロセス
+
+
+ +
+

メンテナンステスト固有の課題

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
課題理由対策
テスト基盤の陳腐化長年の変更でドキュメントが実装と乖離変更都度のドキュメント更新、逆エンジニアリング
変更範囲の不明確さ依存関係が複雑化しているシステム依存関係分析ツールの活用、コードカバレッジ計測
本番環境での直接テストテスト環境が整備されていない本番同等環境の整備、フィーチャーフラグの活用
開発者知識の喪失担当者離脱による知識断絶テスト自動化、テストドキュメントの充実
+
+
+
+ + +
+
+ § 試験対策 +

頻出問題パターンと落とし穴

+
+ +
+

v4.0で追加・変更された重要ポイント

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
変更内容v3.1v4.0
統合テストの分離統合テスト（1段階） + コンポーネント統合テスト + システム統合テスト（2段階）変更 +
DevOpsセクションなし2.1.4として新設新設
Shift Leftセクションなし2.1.5として新設新設
テストファーストアプローチTDD/ATDDのみ + TDD / ATDD / BDD（3種類）を明確化変更 +
レトロスペクティブなし2.1.6として新設新設
+
+
+ +
+

よくある誤解と正しい理解

+
+
+
+
誤解
+ BDD = TDDの発展形・上位互換 +
+
+
正しい理解
+ BDDとTDDは異なるアプローチ。BDDは振る舞い仕様に焦点、TDDはコード設計に焦点 +
+
+
+
+
誤解
+ シフトレフト = テストを前倒しにするだけ +
+
+
正しい理解
+ テスト活動全体の前倒し + + 後半テストとの組み合わせ。後半テストは依然として必要 +
+
+
+
+
誤解
+ DevOps = 手動テストの廃止 +
+
+
正しい理解
+ 探索的テストなどの手動テストは依然として重要な役割を持つ +
+
+
+
+
誤解
+ 確認テスト = リグレッションテスト +
+
+
正しい理解
+ 目的が異なる。確認テストは修正確認、リグレッションは副作用確認 +
+
+
+
+
誤解
+ テストタイプはテストレベルに紐付く +
+
+
正しい理解
+ テストタイプはすべてのテストレベルで適用可能（独立している） +
+
+
+
+
誤解
+ ATDDはGiven/When/Then形式を使う +
+
+
正しい理解
+ Given/When/Then（Gherkin）はBDDの形式。ATDDは形式を問わない +
+
+
+
+ +
+

試験頻出のK2問題パターン例

+
+
問題タイプ 1 — テストレベルの識別
+
+ 開発チームが外部決済APIとの統合後、決済フローに問題が発生した。この問題を検出するために最も適切なテストレベルはどれか？ +
+
+ システム統合テスト（外部システムとの結合インターフェースを確認するため） +
+
+
+
+ 問題タイプ 2 — テストファーストアプローチの識別 +
+
+ テストチームがコードを書く前に、Gherkinを使ってGiven/When/Then形式でテストシナリオを定義している。どのアプローチか？ +
+
+ BDD（Given/When/Then形式 + テストファーストの組み合わせがBDDの特徴） +
+
+
+
問題タイプ 3 — DevOpsにおけるテストの役割
+
+ DevOpsチームがCIパイプラインでビルドのたびに自動テストを実行している。このテストの主要な目的は何か？ +
+
+ リグレッション防止と即時フィードバック（変更の副作用を最速で検出し開発者に通知する） +
+
+
+
問題タイプ 4 — メンテナンステストの変更種別
+
+ 本番稼働中のシステムのデータベースをOracleからPostgreSQLに移行する際のテストは、どの変更種別に該当するか？ +
+
+ 適応的変更（Adaptive Changes）— 環境変化への対応が目的であるため +
+
+
+
問題タイプ 5 — 受入テストのサブタイプ
+
+ システム管理者がシステムのバックアップ・リストア手順と障害時の自動復旧機能を検証している。これはどのテストか？ +
+
+ 運用受入テスト（OAT）— システム管理者による運用面の検証が特徴 +
+
+
+
+ + +
+
+ § 参照 +

参照URL一覧

+
+

本ガイド作成に使用した一次資料・信頼性の高い情報源。最終確認日: 2026-06-29。

+ +
+
+
01
+
+
ISTQB CTFL v4.0 公式ページ
+
+ https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/ +
+
+ International Software Testing Qualifications Board — 公式 +
+
+
+
+
02
+
+
CTFL Syllabus v4.0.1（PDF）— 一次資料
+
+ https://istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf +
+
+ ISTQB, 2024-09-15 改訂 — 本ガイドの主要参照元 +
+
+
+
+
03
+
+
ISTQB v4.0 リリースアナウンス
+
+ https://istqb.org/istqb-releases-certified-tester-foundation-level-v4-0-ctfl/ +
+
ISTQB, 2023-05-09 — v4.0リリース時の公式発表
+
+
+
+
04
+
+
ISTQB 用語集（Glossary）
+
+ https://glossary.istqb.org/en_US/search +
+
ISTQB — テスト用語の公式定義
+
+
+
+
05
+
+
ASTQB版 CTFL Syllabus v4.0.1（PDF）
+
+ https://astqb.org/assets/documents/ISTQB_CTFL_Syllabus_v4.0.1.pdf +
+
+ ASTQB（米国ISTQBメンバーボード） — ミラー資料 +
+
+
+
+
06
+
+
ISTQB.com — CTFL v4.0 試験・シラバスガイド
+
+ https://www.istqb.com/ctfl-v4-0/ +
+
+ istqb.com (独立教育リソース), 最終更新 2026-05-21 +
+
+
+
+
07
+
+
istqb.guru — Chapter別シラバス詳細解説
+
+ https://www.istqb.guru/ctfl-v4-syllabus-chapter-by-chapter-deep-dive/ +
+
istqb.guru, 2026-04-17
+
+
+
+
08
+
+
+ testing101.net — CTFL v4.0 概要とChapter別ポイント +
+
+ https://www.testing101.net/post/overview-of-the-istqb-certified-tester-foundation-level-ctfl-v4-0-new +
+
+ testing101.net, 2025-05-01 — v4.0変更点の詳細解説 +
+
+
+
+
09
+
+
+ ISO/IEC 25010 — Systems and software Quality Requirements and + Evaluation +
+
+ https://www.iso.org/standard/78176.html +
+
ISO/IEC — 非機能テストの品質特性の国際標準
+
+
+
+
10
+
+
CTFL-AT（Agile Tester）公式ページ
+
+ https://istqb.org/certifications/certified-tester-foundation-level-agile-tester-ctfl-at/ +
+
ISTQB — CTFL後の発展資格（Agileストリーム）
+
+
+
+
11
+
+
+ mastersoftwaretesting.com — CTFL Complete Study Guide 2025 +
+
+ https://mastersoftwaretesting.com/certification-guides/istqb/ctfl/ctfl-complete-guide +
+
mastersoftwaretesting.com, 2026-01-23
+
+
+
+
+ + +
+

+ 著作権表示: 本資料はISTQB CTFL Syllabus + v4.0.1の学習用解説資料です。ISTQB®はInternational Software Testing + Qualifications + Boardの登録商標です。シラバスの著作権は各著者およびISTQBに帰属します。 +

+

+ 最終更新: 2026年6月29日 | 参照シラバス: ISTQB + CTFL v4.0.1 (2024-09-15) +

+
+
+ + + + diff --git a/Ctfl-v4-chapter2-sdlc-and-testing.md b/Ctfl-v4-chapter2-sdlc-and-testing.md new file mode 100644 index 00000000..0da5f4d4 --- /dev/null +++ b/Ctfl-v4-chapter2-sdlc-and-testing.md @@ -0,0 +1,584 @@ +# ISTQB CTFL v4.0 — Chapter 2: SDLCとテスト 完全解説ガイド + +> **対象読者:** 中級〜上級エンジニア（実務経験2年以上、CTFL受験準備中） +> **参照シラバス:** ISTQB CTFL Syllabus v4.0.1（2024年9月15日改訂） +> **試験配点:** 全40問中 **7問**（K1: 2問 / K2: 5問） +> **推奨学習時間:** 約80分 + +--- + +## 目次 + +1. [Chapter 2 の全体像と試験戦略](#chapter-2-の全体像と試験戦略) +2. [2.1 SDLCのコンテキストにおけるテスト](#21-sdlcのコンテキストにおけるテスト) + - [2.1.1 SDLCモデルとテスト活動の影響](#211-sdlcモデルとテスト活動の影響) + - [2.1.2 良いテスト実践とSDLCへの統合](#212-良いテスト実践とsdlcへの統合) + - [2.1.3 テストファーストアプローチ（TDD / ATDD / BDD）](#213-テストファーストアプローチtdd--atdd--bdd) + - [2.1.4 DevOpsとテスト](#214-devopsとテスト) + - [2.1.5 シフトレフト（Shift Left）](#215-シフトレフトshift-left) + - [2.1.6 レトロスペクティブとプロセス改善](#216-レトロスペクティブとプロセス改善) +3. [2.2 テストレベルとテストタイプ](#22-テストレベルとテストタイプ) + - [2.2.1 テストレベル（5段階）](#221-テストレベル5段階) + - [2.2.2 テストタイプ（4種類）](#222-テストタイプ4種類) + - [2.2.3 確認テストとリグレッションテスト](#223-確認テストとリグレッションテスト) +4. [2.3 メンテナンステスト](#23-メンテナンステスト) +5. [試験対策: 頻出問題パターンと落とし穴](#試験対策-頻出問題パターンと落とし穴) +6. [参照URL一覧](#参照url一覧) + +--- + +## Chapter 2 の全体像と試験戦略 + +### Chapter 2 が扱う3つの大テーマ + +```mermaid +flowchart TD + A["Chapter 2: SDLCとテスト"] --> B["2.1 SDLCのコンテキストにおけるテスト"] + A --> C["2.2 テストレベルとテストタイプ"] + A --> D["2.3 メンテナンステスト"] + + B --> B1["SDLCモデルへの適合"] + B --> B2["良いテスト実践"] + B --> B3["TDD / ATDD / BDD"] + B --> B4["DevOps"] + B --> B5["Shift Left"] + B --> B6["レトロスペクティブ"] + + C --> C1["5つのテストレベル"] + C --> C2["4つのテストタイプ"] + C --> C3["確認・リグレッション"] + + D --> D1["変更の契機"] + D --> D2["インパクト分析"] +``` + +### 試験配点マップ + +| セクション | 問題数 | K-レベル | 頻出トピック | +|-----------|--------|---------|-------------| +| 2.1 SDLCのコンテキスト | 2問 | K1/K2 | DevOps特性、Shift Left手法 | +| 2.2 テストレベル/タイプ | 4問 | K2 | 各レベルの目的・テスト基盤・テスト対象 | +| 2.3 メンテナンステスト | 1問 | K2 | 変更の種類、インパクト分析 | + +> **試験戦略:** Chapter 2は「定義の正確な理解」が鍵。特に **v4.0での新設事項**（コンポーネント統合テストとシステム統合テストの分離、DevOps追加）を重点的に押さえること。 + +--- + +## 2.1 SDLCのコンテキストにおけるテスト + +### 2.1.1 SDLCモデルとテスト活動の影響 + +SDLCの選択はテストのあらゆる側面に影響する。シラバスはこの関係を明示的に定義している。 + +#### SDLCモデルの分類 + +```mermaid +flowchart LR + subgraph sequential["シーケンシャルモデル"] + W["Waterfall"] + V["V-model"] + end + subgraph iterative["イテラティブ/インクリメンタルモデル"] + AG["Agile\n(Scrum / XP / Kanban)"] + SP["Spiral"] + end + subgraph hybrid["ハイブリッド"] + HB["Hybrid SDLC\n(例: Wagile)"] + end + + sequential -->|"静的テスト中心\n後半に動的テスト"| effect1["テスト活動の後倒しリスク"] + iterative -->|"各イテレーションで\n静的+動的両方"| effect2["継続的テストが可能"] + hybrid --> effect3["組み合わせに応じて\nアプローチを調整"] +``` + +#### SDLCモデルごとのテスト活動の違い + +| 側面 | シーケンシャル（Waterfall/V-model） | イテラティブ/インクリメンタル（Agile） | +|------|-------------------------------------|--------------------------------------| +| **テストの開始時期** | 後半フェーズが中心 | 各イテレーション内で並行 | +| **静的テスト** | 要件・設計レビューとして前半に実施 | 各スプリントで継続的に実施 | +| **動的テスト** | コード完成後に集中 | 各スプリント内で完結 | +| **テスト文書** | 詳細・フォーマル | 軽量・Just Enough | +| **自動化の位置づけ** | プロジェクト後半 | リグレッション防止として初期から | +| **テスターの関与** | 後半フェーズに集中 | 要件定義から継続的に関与 | + +> **重要ポイント:** シラバスは「どのSDLCモデルが優れているか」を問うのではなく、「テストをSDLCに適合させる方法」を問う。正しい問いは「このSDLCでテストをどう統合するか？」である。 + +#### V-model: テストレベルと開発フェーズの対応 + +```mermaid +flowchart LR + subgraph left["開発フェーズ（左辺）"] + R["要件定義"] + SA["システム設計"] + AD["アーキテクチャ設計"] + DD["詳細設計"] + CD["コーディング"] + end + subgraph right["テストフェーズ（右辺）"] + AT["受入テスト"] + ST["システムテスト"] + SIT["システム統合テスト"] + CIT["コンポーネント統合テスト"] + CT["コンポーネントテスト"] + end + + R -.->|"テスト基盤"| AT + SA -.->|"テスト基盤"| ST + AD -.->|"テスト基盤"| SIT + DD -.->|"テスト基盤"| CIT + CD --> CT +``` + +--- + +### 2.1.2 良いテスト実践とSDLCへの統合 + +シラバスは「良いテスト実践（Good Testing Practices）」として、SDLCモデルによらず適用できる原則を定めている。 + +#### 4つの良いテスト実践 + +```mermaid +flowchart TD + GP["良いテスト実践\n(Good Testing Practices)"] + + GP --> P1["1. テスト目標の対応付け\n各開発活動に対応するテスト活動を設ける"] + GP --> P2["2. テストタイプの適用\n各テストレベルに適切なテストタイプを使用"] + GP --> P3["3. テスト目標のSDLC適合\n プロセス・制約・目標に合わせてテスト目標を策定"] + GP --> P4["4. テスター関与の早期化\n レビュー・分析・設計を開発初期から実施"] +``` + +**具体的な実践例:** + +| 開発活動 | 対応するテスト活動 | 根拠 | +|---------|-------------------|------| +| 要件定義 | 要件レビュー、受入基準作成 | 欠陥の早期発見（Shift Left） | +| 設計 | テスト設計（テスト条件の特定） | アーキテクチャの問題を設計段階で検出 | +| コーディング | コンポーネントテスト、コードレビュー | 単体レベルの欠陥除去 | +| 統合 | 統合テスト | インターフェース欠陥の検出 | +| リリース | 受入テスト、回帰テスト | デプロイ判断の根拠取得 | + +--- + +### 2.1.3 テストファーストアプローチ（TDD / ATDD / BDD） + +v4.0の重要な追加事項。3つのアプローチはいずれも「テストが開発を駆動する」という共通原則を持つ。 + +#### 3アプローチの比較 + +| アプローチ | 正式名称 | テスト記述者 | テスト形式 | 目的 | +|-----------|---------|------------|----------|------| +| **TDD** | Test-Driven Development | 開発者 | プログラミング言語のテストコード | コードの設計を改善 | +| **ATDD** | Acceptance Test-Driven Development | 開発者・テスター・ビジネス | 自然言語ベースの受入基準 | 全員の共通理解を形成 | +| **BDD** | Behavior-Driven Development | 開発者・テスター・ビジネス | Given/When/Then 形式 | システムの振る舞いを仕様化 | + +#### TDD サイクル + +```mermaid +flowchart LR + A["1. Failing Testを書く\n（Red）"] --> B["2. テストを通る\n最小限のコードを書く\n（Green）"] + B --> C["3. コードをリファクタリング\n（Refactor）"] + C --> A +``` + +#### BDD の Given/When/Then 形式 + +```gherkin +Feature: ショッピングカートへの商品追加 + + Scenario: 在庫ありの商品をカートに追加する + Given ユーザーが商品詳細ページを閲覧している + When ユーザーが「カートに追加」ボタンをクリックする + Then カート内の商品数が1増加する + And 「カートに追加しました」のメッセージが表示される +``` + +#### 3アプローチの共通点と相違点 + +```mermaid +flowchart TD + common["3アプローチの共通点"] + common --> c1["テストファースト原則\n（コード前にテストを定義）"] + common --> c2["Shift Leftの実践\n（早期テスト設計）"] + common --> c3["自動化による継続的品質保証\n（テストは自動化テストとして永続）"] + + diff["主な相違点"] + diff --> d1["TDD: 開発者中心、単体テストレベル"] + diff --> d2["ATDD: チーム全体、受入テストレベル"] + diff --> d3["BDD: 自然言語記述、振る舞い仕様"] +``` + +> **試験の落とし穴:** BDDはGiven/When/Then形式を使用するが、ATDDは必ずしもこの形式を使わない。ATDDは「受入基準からテストを派生させる」ことが本質であり、形式は問わない。 + +--- + +### 2.1.4 DevOpsとテスト + +v4.0で新設されたセクション。CI/CDパイプラインにおけるテストの役割を明確化。 + +#### DevOpsの定義（シラバスの定義） + +DevOpsは開発（テストを含む）とオペレーションが共通目標に向けて協働するための**組織変革**である。技術的プラクティスに加え、**文化的変革**が必須。 + +#### DevOpsの主要特性 + +| 特性 | 説明 | テストへの影響 | +|------|------|--------------| +| **チームの自律性** | 各チームがエンドツーエンドの責任を持つ | テスターが開発チームに埋め込まれる | +| **高速フィードバック** | CIによる自動テスト実行 | 数分以内に品質フィードバックを取得 | +| **統合ツールチェーン** | CI/CDパイプラインの自動化 | テスト自動化が必須インフラに | +| **継続的インテグレーション（CI）** | コードの頻繁なマージ + 自動ビルド/テスト | リグレッション即時検出 | +| **継続的デリバリー（CD）** | 常にリリース可能な状態を維持 | 全テストレベルの高速化が前提 | + +#### DevOps CI/CDパイプラインにおけるテストフロー + +```mermaid +flowchart LR + commit["コードコミット"] --> ci_build["CIビルド"] + ci_build --> unit["コンポーネント\nテスト\n自動実行"] + unit --> integration["統合テスト\n自動実行"] + integration --> static["静的解析\n（Lint / SAST）"] + static --> staging["ステージング\n環境デプロイ"] + staging --> system["システムテスト\n自動実行"] + system --> manual["探索的テスト\n（手動）"] + manual --> prod["本番デプロイ"] + + unit -->|"失敗"| notify["開発者に\n即時通知"] + integration -->|"失敗"| notify + system -->|"失敗"| notify +``` + +#### DevOpsのテストにおけるメリットとリスク + +**メリット:** + +- 安定した環境でのテストが可能（Infrastructure as Code） +- 非機能テスト（性能・セキュリティ）をパイプラインに組み込み可能 +- テストカバレッジの可視化と品質メトリクスの継続的収集 + +**リスク・課題:** + +- テスト自動化の初期構築コストが高い +- 手動テスト（探索的テスト等）の位置づけが不明確になりがち +- パイプラインの維持・管理に専門知識が必要 + +--- + +### 2.1.5 シフトレフト（Shift Left） + +シフトレフトは「テストを早期に実施する」という原則の実践的手法。 + +#### シフトレフトの本質 + +```mermaid +flowchart LR + subgraph traditional["従来のアプローチ"] + t1["要件"] --> t2["設計"] --> t3["実装"] --> t4["テスト（後倒し）"] + end + subgraph shiftleft["シフトレフト"] + s1["テスト設計\n（要件段階）"] --> s2["仕様レビュー\n（設計段階）"] --> s3["TDD/ATDD\n（実装段階）"] --> s4["テスト実行\n（通常タイミング）"] + end +``` + +#### シフトレフトの具体的手法 + +| 手法 | タイミング | 目的 | +|------|----------|------| +| 仕様・要件のレビュー | 要件定義フェーズ | 曖昧さ・矛盾の早期検出 | +| コード実装前のテスト設計 | 設計フェーズ | テスト容易性を設計に反映 | +| CI/CDでの自動テスト | コミット時 | 即時フィードバック | +| 静的解析 | コミット/ビルド時 | コード品質の継続的確認 | +| TDD / ATDD | 実装フェーズ | テストによる設計駆動 | + +> **重要:** シフトレフトは「後半テストをなくす」ことではなく、「前半にもテスト活動を追加する」ことで全体の品質を向上させる考え方。後半のテストは依然として必要。 + +--- + +### 2.1.6 レトロスペクティブとプロセス改善 + +#### シラバスにおけるレトロスペクティブの定義 + +レトロスペクティブ（振り返り会議）はプロジェクト、フェーズ、リリース、またはイテレーションの終了時に実施し、**テストプロセスの継続的改善**に活用する。 + +#### レトロスペクティブの目的 + +```mermaid +flowchart TD + retro["レトロスペクティブ"] + retro --> r1["成功事例の確認\n（続けること）"] + retro --> r2["改善機会の特定\n（変えること）"] + retro --> r3["教訓の文書化\n（次プロジェクトへの継承）"] + + r1 --> outcome["テスト有効性・効率性・品質の向上\nチームコラボレーションの改善"] + r2 --> outcome + r3 --> outcome +``` + +#### テスト観点でのレトロスペクティブ活動例 + +| 議題 | 改善内容の例 | +|------|------------| +| テストカバレッジ | 不足していたテスト観点の特定と次回への反映 | +| 欠陥の傾向分析 | 繰り返し発生する欠陥パターンの根本原因分析 | +| テスト自動化 | 手動で繰り返したテストの自動化候補の洗い出し | +| テスト環境の問題 | 環境起因の障害への対策 | +| テストプロセスの効率化 | テスト設計・実行の所要時間の見直し | + +--- + +## 2.2 テストレベルとテストタイプ + +### 2.2.1 テストレベル（5段階） + +> **v4.0の重要変更:** v3.1では「統合テスト」1段階だったが、v4.0では **コンポーネント統合テスト** と **システム統合テスト** に分離された。これは試験頻出事項。 + +#### 5つのテストレベルの全体構造 + +```mermaid +flowchart BT + L1["コンポーネントテスト\n(Component Testing)"] --> L2["コンポーネント統合テスト\n(Component Integration Testing)"] + L2 --> L3["システムテスト\n(System Testing)"] + L3 --> L4["システム統合テスト\n(System Integration Testing)"] + L4 --> L5["受入テスト\n(Acceptance Testing)"] + + style L1 fill:#e8f4fd,stroke:#2196F3 + style L2 fill:#e8f5e9,stroke:#4CAF50 + style L3 fill:#fff3e0,stroke:#FF9800 + style L4 fill:#fce4ec,stroke:#E91E63 + style L5 fill:#ede7f6,stroke:#673AB7 +``` + +#### 各テストレベルの詳細比較 + +| 属性 | コンポーネントテスト | コンポーネント統合テスト | システムテスト | システム統合テスト | 受入テスト | +|------|------------------|-----------------------|--------------|-----------------|----------| +| **目的** | 個別コンポーネントの動作確認 | コンポーネント間インターフェースの確認 | システム全体の動作確認 | 外部システムとの統合確認 | ビジネス要件を満たすか確認 | +| **テスト対象** | 1つのコンポーネント/クラス/モジュール | コンポーネント群のインターフェース | システム全体 | 他システム・サードパーティとの結合 | システム全体（本番同等環境） | +| **テスト基盤** | 詳細設計、コンポーネント仕様 | インターフェース設計、アーキテクチャ設計 | システム要件仕様 | システムインターフェース設計 | ユーザー要件、ユースケース、契約 | +| **テスト担当者** | 主に開発者 | 開発者/テスター | テスター | テスター/統合チーム | ユーザー/顧客/テスター | +| **環境** | 開発環境 | 開発/統合環境 | テスト環境 | テスト/ステージング環境 | 本番同等環境 | +| **代表的な欠陥** | ロジックエラー、アルゴリズムの誤り | インターフェース不整合、データ変換エラー | 機能要件の未達、性能問題 | 外部システムとの通信エラー | ビジネス要件の未達、ユーザビリティ問題 | + +#### 受入テストの4サブタイプ + +受入テストはシラバスで特に詳しく定義されている。試験で問われやすい。 + +| サブタイプ | 略称 | 実施者 | 目的 | +|-----------|------|--------|------| +| ユーザー受入テスト | UAT | 実際のユーザー | 実際の利用シナリオでの検証 | +| 運用受入テスト | OAT | システム管理者 | バックアップ・リカバリ・メンテナンス性の確認 | +| 契約・規制受入テスト | — | テスター/外部監査 | 契約条件・法規制・標準への準拠確認 | +| アルファ/ベータテスト | — | 限定ユーザー | 実際の利用環境での問題検出 | + +```mermaid +flowchart TD + AT["受入テスト\n(Acceptance Testing)"] + AT --> UAT["ユーザー受入テスト\n(UAT)\n実際のユーザーが実際のシナリオで検証"] + AT --> OAT["運用受入テスト\n(OAT)\nシステム管理者が運用面を検証"] + AT --> CRT["契約・規制受入テスト\n契約・法規制への準拠を検証"] + AT --> ABT["アルファ/ベータテスト\n限定ユーザーによる実環境テスト"] +``` + +--- + +### 2.2.2 テストタイプ（4種類） + +テストタイプは「何を評価するか」を定義する。テストレベルとは独立しており、**すべてのテストレベルで全タイプを適用できる**。 + +#### 4つのテストタイプの概要 + +```mermaid +flowchart TD + TT["テストタイプ\n(Test Types)"] + TT --> FT["機能テスト\n(Functional Testing)\n「何をするか」を検証"] + TT --> NFT["非機能テスト\n(Non-Functional Testing)\n「どのようにするか」を検証"] + TT --> BBT["ブラックボックステスト\n(Black-Box Testing)\n仕様・外部仕様ベース"] + TT --> WBT["ホワイトボックステスト\n(White-Box Testing)\n内部構造ベース"] +``` + +#### テストタイプ詳細 + +| テストタイプ | 評価対象 | 代表的な技法 | 主なテスト基盤 | +|------------|---------|------------|--------------| +| **機能テスト** | 機能要件（完全性・正確性・適切性） | 同値分割、境界値分析、デシジョンテーブル | 要件仕様、ユースケース、ユーザーストーリー | +| **非機能テスト** | 品質特性（性能・セキュリティ・信頼性・使いやすさ等） | 性能テスト、セキュリティテスト、ユーザビリティテスト | 性能要件、セキュリティ基準、UI仕様 | +| **ブラックボックステスト** | 外部仕様との整合性（内部実装を見ない） | 同値分割、境界値分析、ユースケーステスト | 仕様書、要件 | +| **ホワイトボックステスト** | 内部構造の網羅性 | ステートメントカバレッジ、ブランチカバレッジ | コード、アーキテクチャ図 | + +#### 非機能テストの品質特性（ISO/IEC 25010） + +```mermaid +flowchart TD + NF["非機能テストの主要対象\n（ISO/IEC 25010 品質特性）"] + NF --> PERF["性能効率性\n(Performance Efficiency)\n応答時間・スループット・リソース使用率"] + NF --> COMP["互換性\n(Compatibility)\n共存性・相互運用性"] + NF --> USAB["使用性\n(Usability)\n認識可能性・学習容易性・操作性"] + NF --> RELI["信頼性\n(Reliability)\n成熟性・可用性・フォールトトレランス"] + NF --> SECU["セキュリティ\n(Security)\n機密性・完全性・否認防止性"] + NF --> MAIN["保守性\n(Maintainability)\n変更可能性・テスト容易性"] + NF --> PORT["移植性\n(Portability)\n適応性・設置性・置換可能性"] +``` + +> **試験のポイント:** テストタイプはテストレベルとは**独立**。例えば「コンポーネントレベルで非機能テスト（例：単体レベルの性能計測）」も「システムレベルでホワイトボックステスト」も理論上は可能。 + +--- + +### 2.2.3 確認テストとリグレッションテスト + +欠陥修正後に実施する2種類のテスト。混同しやすいため、区別を明確に理解する。 + +#### 比較表 + +| 属性 | 確認テスト (Confirmation Testing) | リグレッションテスト (Regression Testing) | +|------|----------------------------------|----------------------------------------| +| **別名** | リテスト (Re-test) | 回帰テスト | +| **目的** | 欠陥修正が正しく行われたことを確認 | 修正によって他の部分に影響が出ていないことを確認 | +| **実施タイミング** | 欠陥修正後 | 欠陥修正後、変更後、環境変更後 | +| **テスト範囲** | 修正された欠陥に関連するテストのみ | 修正の影響範囲全体（場合によってはシステム全体） | +| **自動化の推奨度** | 低〜中（修正内容に依存） | 高（繰り返し実行のため）| + +#### 欠陥修正後のテストフロー + +```mermaid +flowchart LR + defect["欠陥報告\n(Defect Report)"] --> fix["開発者が修正"] + fix --> confirm["確認テスト\n修正箇所が正しく直ったか確認"] + confirm -->|"Pass"| regress["リグレッションテスト\n修正の副作用がないか確認"] + confirm -->|"Fail"| reopen["欠陥を\nReopen"] + regress -->|"Pass"| close["テスト完了\nDeployへ"] + regress -->|"新欠陥検出"| new_defect["新規欠陥報告"] +``` + +> **重要:** リグレッションテストはDevOps/Agile環境では**CI/CDパイプラインで自動実行**することが強く推奨される。頻繁な変更に対応するためには手動実行は非効率。 + +--- + +## 2.3 メンテナンステスト + +システムのリリース後に行われるテスト活動。リリース前のテストとは異なる特性を持つ。 + +### 変更の種類とメンテナンステストのトリガー + +```mermaid +flowchart TD + MT["メンテナンステスト\nのトリガー"] + MT --> C1["修正変更\n(Corrective Changes)\n欠陥・障害の修正"] + MT --> C2["適応的変更\n(Adaptive Changes)\n環境変化への対応\n（OS更新、DBアップグレード等）"] + MT --> C3["改善的変更\n(Perfective Changes)\n機能追加・性能改善"] + MT --> C4["廃止・退役\n(Retirement)\nシステムやコンポーネントの廃止"] +``` + +### 変更の種類ごとのメンテナンステストの特性 + +| 変更の種類 | 例 | テストの焦点 | リスクレベル | +|-----------|------|------------|------------| +| **修正変更** | バグフィックスのパッチ適用 | 確認テスト + 限定的リグレッション | 中 | +| **適応的変更** | OSバージョンアップ、クラウド移行 | 互換性テスト + 全体リグレッション | 高 | +| **改善的変更** | 新機能追加、UI刷新 | 新機能テスト + 影響範囲のリグレッション | 中〜高 | +| **廃止・退役** | 旧システムの廃止、データ移行 | データ移行テスト、並行稼働テスト | 高 | + +### インパクト分析（Impact Analysis） + +メンテナンステストの計画において中核となるプロセス。 + +```mermaid +flowchart TD + IA["インパクト分析\n(Impact Analysis)"] + IA --> IA1["変更の影響範囲を特定\n変更されたコンポーネントと依存関係を調査"] + IA --> IA2["テスト範囲の決定\n確認テストとリグレッションテストの範囲を決定"] + IA --> IA3["リスクの評価\n変更による未意図の副作用リスクを評価"] + IA --> IA4["テスト優先順位付け\n影響度の高い領域から優先的にテスト"] + + IA1 --> output["インパクト分析の\n成果物"] + IA2 --> output + IA3 --> output + IA4 --> output + + output --> plan["メンテナンステスト計画\nの策定"] +``` + +### メンテナンステストの難しさ + +通常のプロジェクトテストと比較したメンテナンステスト固有の課題: + +| 課題 | 理由 | 対策 | +|------|------|------| +| テスト基盤の陳腐化 | 長年の変更でドキュメントが実装と乖離 | 変更都度のドキュメント更新、逆エンジニアリング | +| 変更範囲の不明確さ | 依存関係が複雑化しているシステム | 依存関係分析ツールの活用、コードカバレッジ計測 | +| 本番環境での直接テスト | テスト環境が整備されていない | 本番同等環境の整備、フィーチャーフラグの活用 | +| 開発者知識の喪失 | 担当者離脱による知識断絶 | テスト自動化、テストドキュメントの充実 | + +--- + +## 試験対策: 頻出問題パターンと落とし穴 + +### v4.0で新たに追加・変更された重要ポイント + +| 変更内容 | v3.1 | v4.0 | +|---------|------|------| +| 統合テストの分離 | 統合テスト（1段階） | コンポーネント統合テスト + システム統合テスト（2段階） | +| DevOpsセクション | なし | 2.1.4として新設 | +| Shift Leftセクション | なし | 2.1.5として新設 | +| テストファーストアプローチ | TDD/ATDDのみ | TDD / ATDD / BDD（3種類）を明確化 | +| レトロスペクティブ | なし | 2.1.6として新設 | + +### よくある誤解と正しい理解 + +| よくある誤解 | 正しい理解 | +|------------|-----------| +| BDD = TDDの発展形 | BDDとTDDは異なるアプローチ。BDDは振る舞い仕様に焦点、TDDはコード設計に焦点 | +| シフトレフト = テストを前倒しにするだけ | テスト活動全体の前倒し + 後半テストとの組み合わせ | +| DevOps = 手動テストの廃止 | 手動テスト（探索的テスト等）は依然として重要な役割を持つ | +| 確認テスト = リグレッションテスト | 目的が異なる。確認テストは修正確認、リグレッションは副作用確認 | +| テストタイプはテストレベルに紐付く | テストタイプはすべてのテストレベルで適用可能 | + +### 試験頻出のK2問題パターン例 + +**問題タイプ1: シナリオと適切なテストレベルの対応** + +> *開発チームが外部決済APIとの統合後、決済フローの問題を検出した。どのテストレベルが最も適切か？* +> → **システム統合テスト**（外部システムとの結合を確認するため） + +**問題タイプ2: 手法の識別** + +> *テストチームがコードを書く前に、Gherkinを使ってGiven/When/Then形式でテストシナリオを定義している。どのアプローチか？* +> → **BDD**（Given/When/Then形式 + テストファースト） + +**問題タイプ3: DevOpsにおけるテストの役割** + +> *DevOpsチームがCIパイプラインでビルドのたびに自動テストを実行している。このテストの主要な目的は何か？* +> → **リグレッション防止と即時フィードバック** + +--- + +## 参照URL一覧 + +| 資料 | URL | 最終確認日 | +|------|-----|----------| +| ISTQB CTFL v4.0 公式ページ | | 2026-06-29 | +| CTFL Syllabus v4.0.1（PDF） | | 2026-06-29 | +| ISTQB リリースアナウンス（v4.0） | | 2026-06-29 | +| ISTQB 用語集 | | 2026-06-29 | +| ASTQB版 Syllabus v4.0.1（PDF） | | 2026-06-29 | +| ISTQB.com — CTFL v4.0 ガイド | | 2026-06-29 | +| istqb.guru — Chapter別解説 | | 2026-06-29 | +| testing101.net — CTFL v4.0 概要 | | 2026-06-29 | +| ISO/IEC 25010（品質モデル）概要 | | 2026-06-29 | +| CTFL-AT（Agile Tester）公式ページ | | 2026-06-29 | + +--- + +## 試験配点の最終確認 + +> **Chapter 2 の出題配分（冒頭の再掲）:** +> +> - Chapter 2 は全40問中 **7問** が出題されます +> - 内訳: **K1 × 2問** / **K2 × 5問** +> - K3（適用）レベルの出題はありません +> - 章末で配点を素早く確認できるよう、冒頭の「試験配点」を再掲しています + +--- + +> **著作権表示:** 本資料はISTQB CTFL Syllabus v4.0.1の学習用解説資料です。ISTQB®はInternational Software Testing Qualifications Boardの登録商標です。シラバスの著作権は各著者およびISTQBに帰属します。 +> +> **最終更新:** 2026年6月29日 diff --git a/Ctfl-v4-chapter3-static-testing.md b/Ctfl-v4-chapter3-static-testing.md new file mode 100644 index 00000000..2a144c0f --- /dev/null +++ b/Ctfl-v4-chapter3-static-testing.md @@ -0,0 +1,344 @@ +# CTFL v4.0 第3章：静的テスト 徹底解説 + +> 本資料は ISTQB® Certified Tester Foundation Level (CTFL) v4.0.1 シラバスの **Chapter 3「静的テスト（Static Testing）」** を、中級者〜上級者のソフトウェアエンジニア・QAエンジニア向けにステップバイステップで解説したものです。公式シラバス（英語版・日本語版）および ISO/IEC 20246 等の関連標準、現場で使われる静的解析ツールの動向を調査したうえで、シラバスの構成に沿って独自にまとめています。各セクション末尾に出典URLを明記していますので、一次情報の確認にご活用ください。 + +--- + +## 0. この章の位置づけ + +CTFL v4.0 シラバスは全6章で構成され、Chapter 3「静的テスト」の標準学習時間は **80分** と、6章の中では最も短い部類に入ります。とはいえ、出題範囲としての重要度が低いわけではなく、「欠陥をできるだけ早く・安く見つける」というテストの大原則（第1章で学ぶ7原則の3番目「早期テストは時間とコストを節約する」）を実践するうえでの中核技法がここに詰まっています。 + +```mermaid +flowchart TD + T["ソフトウェアテスト"] --> S["静的テスト（Static Testing）
ソフトウェアを実行しない"] + T --> D["動的テスト（Dynamic Testing）
ソフトウェアを実行する"] + S --> S1["レビュー
人手による評価"] + S --> S2["静的解析
ツールによる評価"] + D --> D1["テスト技法に基づくテストケース設計
（第4章）"] + D --> D2["テスト実行・故障の検出と分析"] + + classDef static fill:#2d3a2d,stroke:#6b9b6b,color:#e8f5e8; + classDef dynamic fill:#2d2d3a,stroke:#6b6b9b,color:#e8e8f5; + class S,S1,S2 static; + class D,D1,D2 dynamic; +``` + +第2章で学ぶ「シフトレフト」の考え方とも直結しており、コードがまだ実行できない段階（要件定義・設計フェーズ）から欠陥を発見できる唯一の手段が静的テストです。動的テストが「動かして壊れ方を見る」アプローチだとすれば、静的テストは「動かす前に、人の目とツールでミスを見つける」アプローチだと整理すると理解しやすくなります。 + +### 学習目標（Learning Objectives）一覧 + +| 項番 | 学習目標 | 認知レベル | +|---|---|---| +| FL-3.1.1 | 静的テストで検証できる作業成果物の種類を認識する | K1（記憶） | +| FL-3.1.2 | 静的テストの価値を説明する | K2（理解） | +| FL-3.1.3 | 静的テストと動的テストを比較対比する | K2（理解） | +| FL-3.2.1 | 早期かつ頻繁なステークホルダーからのフィードバックの利点を識別する | K1（記憶） | +| FL-3.2.2 | レビュープロセスの活動を要約する | K2（理解） | +| FL-3.2.3 | レビューの主要な役割にどの責務が割り当てられるかを想起する | K1（記憶） | +| FL-3.2.4 | さまざまなレビュー種別を比較対比する | K2（理解） | +| FL-3.2.5 | レビューを成功させる要因を想起する | K1（記憶） | + +キーワード（本シラバスで暗記必須とされる用語）：**anomaly（不正）、dynamic testing（動的テスト）、formal review（公式レビュー）、informal review（非公式レビュー）、inspection（インスペクション）、review（レビュー）、static analysis（静的解析）、static testing（静的テスト）、technical review（テクニカルレビュー）、walkthrough（ウォークスルー）** + +> 出典：ISTQB® Certified Tester Foundation Level Syllabus v4.0.1（2024-09-15）, Chapter 3, p.32-33
+> + +--- + +## 1. 3.1 静的テストの基本 + +### 1.1 静的テストとは何か + +静的テストは、対象のソフトウェアを実際に動かさずに、要件定義書・設計書・ソースコードといった作業成果物を**人手による精査（レビュー）**、あるいは**ツールによる自動チェック（静的解析）**によって評価するアプローチです。動的テストとの最大の違いは「実行するかどうか」であり、静的テストは実行不可能な文書段階の成果物にも適用できる点が大きな強みになります。 + +静的テストの目的は、欠陥の検出だけにとどまりません。可読性・完全性・正確性・試験性・一貫性といった品質特性を評価し、成果物全体の品質を底上げすることも狙いの一つです。さらに、静的テストは「仕様通りに作られているか」を確認する**検証（Verification）**と、「本当にユーザーが欲しいものになっているか」を確認する**妥当性確認（Validation）**の両方に活用できます。たとえば、ユーザーストーリーのレビューでは「受け入れ基準が記載通りに実装可能か（検証）」と「そのユーザーストーリーがそもそもユーザーの課題を解決しているか（妥当性確認）」の両方を確認することになります。 + +近年のアジャイル開発では、テスト担当者・ビジネス側の代表者（プロダクトオーナーやビジネスアナリスト）・開発担当者が共同で行う**Example Mapping（実例マッピング）**、**ユーザーストーリーの共同執筆**、**バックログリファインメント**といった協働作業も、広い意味での静的テストに含まれます。これらの場では、ユーザーストーリーが「Definition of Ready（準備完了の定義）」を満たしているか、受け入れ基準がテスト可能な形になっているかを、適切な質問を投げかけながら確認していきます。 + +### 1.2 静的テストで検証可能な作業成果物（3.1.1） + +レビューの対象になり得る作業成果物は非常に幅広く、「人が読んで理解できるもの」であればほぼすべてが対象になります。一方、静的解析の対象にするには、検査の前提となる構造（コードの文法、モデルの記法など）が必要です。 + +| 分類 | 静的テストの対象となる作業成果物の例 | +|---|---| +| 要求関連 | 要件仕様書、ユーザーストーリー、受け入れ基準 | +| 設計関連 | システムアーキテクチャ仕様書、詳細設計書、データモデル、画面遷移図 | +| 実装関連 | ソースコード、ビルドスクリプト、設定ファイル | +| テスト関連 | テスト計画書、テストケース、テストチャーター、自動化スクリプト | +| プロジェクト管理関連 | プロジェクト計画書、契約書、製品バックログアイテム | + +一方で、静的テストに適さない作業成果物も存在します。具体的には、人間にとって解釈が困難なもの（例：機械生成された難読化コード）や、ツールで分析すべきでない成果物が該当します。代表例として挙げられるのが**サードパーティの実行可能コード**です。これは多くの場合ライセンス契約上の制約によって、逆コンパイルや静的解析ツールでの分析自体が認められていないためです。この「静的テストに適さない成果物」という観点は、シラバスv4.0で新たに明文化された考え方であり、実務でOSSライブラリやベンダー提供のバイナリを扱う際に意識しておくべきポイントです。 + +> 出典：ISTQB® CTFL Syllabus v4.0.1, Section 3.1.1, p.33
+> + +### 1.3 静的テストの価値（3.1.2） + +静的テストの価値は、大きく次の4つに整理できます。 + +**(1) 最も早い段階で欠陥を検出できる** +コードが1行も書かれていない要件定義の段階からレビューを始められるため、「早期テストの原則」を最も忠実に実践できる手段です。要件の段階で見つかる矛盾や曖昧さは、設計・実装・テストの各工程に伝播する前に取り除けます。 + +**(2) 動的テストでは発見しにくい欠陥を見つけられる** +たとえば次のような欠陥は、動的テストでは原理的に発見が難しいか、非常に手間がかかります。 + +- 到達不能コード（どんな条件分岐をたどっても実行されないコードの塊） +- 意図したとおりに実装されていない設計パターン +- ドキュメントなど、そもそも「実行できない」成果物に内在する欠陥 + +**(3) 成果物の品質に対する信頼を積み上げ、共通理解を醸成する** +レビューを通じて要件を確認するプロセスは、書かれた要件が本当にステークホルダーの真のニーズを反映しているかを早期に検証する機会にもなります。これにより、開発に関わる人々の間で「何を作るべきか」についての認識のずれを防ぎ、コミュニケーションの質も向上します。 + +**(4) 結果的にプロジェクト全体のコストを削減する** +レビューの実施自体にはコストがかかりますが、後工程での手戻りコストを考えれば、レビューを行わない場合よりもプロジェクト全体のコストは下がるのが一般的です。同様に、静的解析で検出できる種類のコード欠陥は、動的テストで見つけるよりも効率的に検出でき、結果としてコード欠陥の件数自体の減少と、開発工数全体の削減につながります。 + +ここで静的解析についても補足しておくと、静的解析はテストケースを必要とせず、ツールによって自動実行できるため、レビューよりも少ない工数で多くの欠陥候補を洗い出せるという特徴があります。多くの組織では、CI（継続的インテグレーション）パイプラインに静的解析を組み込み、コードがコミットされるたびに自動でチェックする運用が一般的になっています。静的解析は主にコードの欠陥検出に使われますが、保守性やセキュリティの評価にも活用され、スペルチェッカーや文章の読みやすさを評価するツールも広い意味では静的解析の一種です。 + +> 出典：ISTQB® CTFL Syllabus v4.0.1, Section 3.1.2, p.33-34
+> + +### 1.4 静的テストと動的テストの違い（3.1.3） + +静的テストと動的テストは対立する技法ではなく、互いの弱点を補い合う**補完関係**にあります。「欠陥を検出する」という目的は共通していますが、検出のメカニズムや得意領域は異なります。 + +```mermaid +flowchart LR + subgraph ST["静的テスト"] + direction TB + ST1["作業成果物を読む・解析する"] --> ST2["欠陥を直接発見する"] + end + subgraph DT["動的テスト"] + direction TB + DT1["テストケースを実行する"] --> DT2["故障が発生する"] + DT2 --> DT3["原因を分析し欠陥を特定する
（デバッグ）"] + end +``` + +両者の違いを観点ごとに整理すると、以下のようになります。 + +| 観点 | 静的テスト | 動的テスト | +|---|---|---| +| ソフトウェアの実行 | 不要 | 必要 | +| 欠陥の発見プロセス | 欠陥を直接発見する | テスト実行が故障を引き起こし、その後の分析で欠陥を特定する | +| 適用できる対象 | 実行不可能な成果物（文書・モデルなど）にも適用可能 | 実行可能な成果物のみが対象 | +| 検出が得意な品質特性 | 保守性など、コードを実行しなくても評価できる特性 | 性能効率性など、実際にコードを動かさないと評価できない特性 | +| めったに実行されない処理経路の欠陥 | 比較的見つけやすい | 動的テストだけでは到達・再現が難しい場合がある | + +実務上特に重要なのは、「静的テストでしか見つからない欠陥」と「動的テストでしか見つからない欠陥」がそれぞれ存在するという点です。たとえば実行時のパフォーマンス劣化は動的テストでなければ確認できませんが、コーディング規約違反や到達不能コードは動的テストではほぼ検出できません。したがって、どちらか一方に偏ったテスト戦略はリスクが高く、両方を組み合わせることが推奨されます。 + +シラバスでは、静的テストによって早期かつ安価に検出しやすい欠陥の代表例として、次の7カテゴリが挙げられています。 + +| 欠陥カテゴリ | 具体例 | +|---|---| +| 要件の欠陥 | 矛盾、曖昧な表現、記載漏れ、不正確な記述、重複した記載 | +| 設計の欠陥 | 非効率なデータベース構造、モジュール分割の悪さ | +| 一部のコーディング欠陥 | 未定義値のままの変数、未宣言変数の使用、到達不能コード、コードの重複、過度に複雑なロジック | +| コーディング標準からの逸脱 | 命名規則などコーディング規約への不適合 | +| インタフェース仕様の誤り | パラメータの数・型・順序の不一致 | +| 特定のセキュリティ脆弱性 | バッファオーバーフローなど | +| テストベースに対するカバレッジの不備 | ある受け入れ基準に対応するテストが漏れている、など | + +> 出典：ISTQB® CTFL Syllabus v4.0.1, Section 3.1.3, p.34
+> + +--- + +## 2. 3.2 フィードバックとレビュープロセス + +### 2.1 早期かつ頻繁なステークホルダーフィードバックの利点（3.2.1） + +レビューの議論に入る前に、なぜそもそも「早期かつ頻繁なフィードバック」が重要なのかを押さえておきます。 + +開発の初期段階でステークホルダーの関与が乏しいと、開発チームが作っているものが、ステークホルダーが本来思い描いていたビジョンとずれていく危険があります。このずれに気づくのが終盤であればあるほど、軌道修正のコストは指数関数的に増大し、最悪の場合は納期遅延や責任の押し付け合い、プロジェクト自体の失敗に直結します。 + +逆に、開発ライフサイクル全体を通じて頻繁にフィードバックを得られれば、要件に対する誤解を未然に防ぎ、要件の変更が必要になった場合にも早い段階で気づき、対応できます。これは開発チーム自身が「自分たちが何を作っているのか」をより深く理解することにもつながり、ステークホルダーにとって価値の高い機能や、リスクへの影響が大きい部分に開発の力を集中させやすくなるという副次的な効果もあります。 + +レビューは、この「早期かつ頻繁なフィードバック」を構造的に実現するための代表的な手段の一つだと位置づけられます。 + +> 出典：ISTQB® CTFL Syllabus v4.0.1, Section 3.2.1, p.35
+> + +### 2.2 レビュープロセスの活動（3.2.2） + +レビューには様々な形式があり、案件の重要度やリスクに応じて柔軟に調整される必要があります。シラバスでは、その柔軟性の土台として ISO/IEC 20246 規格が定義する汎用的なレビュープロセスを参照しています。ISO/IEC 20246 は、インスペクション・レビュー・ウォークスルーといった作業成果物レビュー全般について、ライフサイクルのどの段階でも使える汎用的なプロセス、活動、タスク、レビュー技法、文書テンプレートを定めた国際標準です。「より公式なレビューが必要であれば、以下の各活動でより多くのタスクをこなすことになる」という考え方が基本になります。 + +なお、対象となる作業成果物のサイズが大きい場合、1回のレビューですべてをカバーしきれないことがあります。その場合は、同じ成果物に対してレビュープロセス全体を複数回繰り返す（章やモジュール単位で分割してレビューする）運用も想定されています。 + +レビュープロセスは、次の5つの活動から構成されます。 + +```mermaid +flowchart LR + A["1. 計画"] --> B["2. レビューの開始"] + B --> C["3. 個々のレビュー"] + C --> D["4. コミュニケーションと分析"] + D --> E["5. 修正と報告"] + D -.->|"終了基準未達の場合は
フォローアップレビューを実施"| C + + classDef step fill:#28324a,stroke:#7090c0,color:#eef2fb; + class A,B,C,D,E step; +``` + +各活動の内容を、表で具体的に整理します。 + +| 活動 | 主な目的 | 具体的なタスクの例 | +|---|---|---| +| ① 計画 | レビューのスコープを定義する | レビューの目的・対象成果物・評価する品質特性・重点領域・終了基準・参照すべき標準・工数とスケジュールを決定する | +| ② レビューの開始 | 参加者と成果物の準備を整える | 参加者全員が対象成果物にアクセスできる状態にし、各自の役割と責務を理解させ、レビューに必要な情報を行き渡らせる | +| ③ 個々のレビュー | レビューアが各自で成果物を精査する | チェックリストベースドレビューやシナリオベースドレビューなどの技法を用いて、不正（anomaly）・提案・疑問点を識別し記録する | +| ④ コミュニケーションと分析 | 見つかった不正を議論し合意する | レビューミーティングなどを通じて、各不正のステータス・担当者・必要な対応を決定し、成果物全体の品質レベルとフォローアップの要否を判断する | +| ⑤ 修正と報告 | 欠陥を修正し結果を報告する | 欠陥ごとに欠陥レポートを作成し、是正措置を追跡できるようにする。終了基準を満たした時点で成果物を受け入れ、レビュー結果を関係者に報告する | + +ここで重要な用語の整理をしておきます。レビューア個人が気づいた「気になる点」は、確定した欠陥（defect）ではなく、まず**不正（anomaly）**として扱われます。不正は、レビューミーティングなどでの議論・分析を経て初めて、欠陥として認定されるか、あるいは「問題なし」と判断されるかが決まります。この「いきなり欠陥と決めつけない」という姿勢は、後述するレビューの成功要因（参加者を責めない文化づくり）とも密接に関係しています。 + +> 出典：ISTQB® CTFL Syllabus v4.0.1, Section 3.2.2, p.35-36
+>
+> ISO/IEC 20246:2017 Software and systems engineering — Work product reviews（概要）
+> + +### 2.3 レビューでの役割と責務（3.2.3） + +レビューには複数のステークホルダーが関わり、それぞれが異なる役割を担います。1人が複数の役割を兼任することも一般的ですが、シラバスでは以下の6つの principal role（主要な役割）が定義されています。 + +| 役割 | 主な責務 | +|---|---| +| マネージャー | 何をレビュー対象とするかを決定し、要員や時間といったリソースを提供する | +| 作成者（オーサー） | レビュー対象の作業成果物を作成し、指摘された不正・欠陥を修正する | +| モデレーター（ファシリテーターとも呼ばれる） | レビューミーティングが効果的に進行するよう、議論の調整・時間管理・誰もが安心して発言できる雰囲気づくりを担う | +| 書記（スクライブ、レコーダーとも呼ばれる） | レビューアから集まった不正情報をまとめ、ミーティング中の決定事項や新たに見つかった不正を記録する | +| レビューア | 実際にレビューを行う。プロジェクトに関わる人だけでなく、その分野の専門家やその他のステークホルダーが担うこともある | +| レビューリーダー | 誰を関与させるか、いつ・どこでレビューを行うかなど、レビュー全体に対して最終的な責任を持つ | + +より詳細な役割分担は ISO/IEC 20246 でさらに細かく定義されていますが、CTFL試験で問われるのはこの6つの基本形です。 + +> **実務・試験で押さえておきたいポイント**：最も公式なレビュー種別である**インスペクション**では、客観性を担保するために**作成者がレビューリーダーや書記を兼任することはできません**。これは作成者自身が自分の成果物の評価プロセスをコントロールしてしまうことを防ぐための仕組みであり、CTFL試験でも頻出のポイントです。 +> +> 出典：ISTQB® CTFL Syllabus v4.0.1, Section 3.2.3, p.36
+> + +### 2.4 レビュー種別（3.2.4） + +レビューには「非公式」から「非常に公式」まで、さまざまな形式が存在します。どの程度の公式さが必要かは、採用しているSDLC、開発プロセスの成熟度、対象成果物の重要度や複雑さ、法規制や監査証跡の必要性といった要因によって決まります。同じ成果物に対して、まず非公式レビューを行い、その後でより公式なレビューを実施するという段階的な運用も可能です。 + +```mermaid +flowchart LR + A["非公式レビュー
Informal Review"] --> B["ウォークスルー
Walkthrough"] + B --> C["テクニカルレビュー
Technical Review"] + C --> D["インスペクション
Inspection"] + + classDef low fill:#3a2d2d,stroke:#c08a6b,color:#f5e8e0; + classDef high fill:#2d3a3a,stroke:#6bc0b0,color:#e0f5f0; + class A,B low; + class C,D high; +``` + +右に進むほど公式度・プロセスの厳密さが高まり、それに比例して文書化の要求レベルや、必要な準備工数も増えていきます。シラバスで定義される4種別を、観点ごとに比較します。 + +| 観点 | 非公式レビュー | ウォークスルー | テクニカルレビュー | インスペクション | +|---|---|---|---|---| +| 主な目的 | 不正の検出 | 品質評価・信頼の醸成・レビューアへの教育・合意形成・新しいアイデアの創出・作成者の改善動機づけなど、複数の目的を持ちうる | 技術的な合意形成・意思決定に加えて、不正の検出・品質評価・信頼の醸成・改善動機づけ | 不正を最大限に検出すること。加えて品質評価・信頼の醸成・改善動機づけも目的に含まれる | +| 主導者 | 特に定めなし | 作成者 | モデレーター | モデレーター（作成者は主導しない） | +| プロセスの定義・文書化 | 定義されたプロセスはなく、公式な文書化された結果も求められない | 比較的軽量。個々のレビューは事前に行われることもあるが必須ではない | ある程度形式的。個々のレビューを伴うのが一般的 | シラバスで説明される汎用プロセス（2.2節）の全工程に従う、最も公式な形式 | +| メトリクスの収集 | 通常なし | 通常なし | 行われることがある | 収集したメトリクスをSDLCやインスペクションプロセス自体の改善に活用する | +| 典型的な利用シーン | ペアプログラミングでの相互チェックなど | 設計内容の共有を兼ねたミーティング、ステークホルダーへのデモを兼ねた説明 | アーキテクチャ選定など技術的な意思決定が必要な場面 | 安全性・ミッションクリティカルな成果物に対する厳格な品質保証 | + +実務での感覚としては、非公式レビューはコードレビューツール上での気軽なコメントのやり取りに近く、インスペクションは監査証跡が必要な規制産業（医療機器・航空宇宙・金融システムなど）でよく採用される、というイメージを持つと理解しやすくなります。 + +> 出典：ISTQB® CTFL Syllabus v4.0.1, Section 3.2.4, p.36-37
+> + +### 2.5 レビューの成功要因（3.2.5） + +最後に、レビューを「やって終わり」にせず、実効性のある活動にするための成功要因を整理します。シラバスでは9つの要因が挙げられています。 + +| # | 成功要因 | 補足 | +|---|---|---| +| 1 | 明確な目的と測定可能な終了基準を定義する | **参加者個人の評価を目的に含めてはならない**。あくまで成果物の品質向上が目的であることを徹底する | +| 2 | 目的に合った適切なレビュー種別を選ぶ | 成果物の種類・参加者・プロジェクトのニーズやコンテキストに応じて、非公式レビューからインスペクションまでの中から選択する | +| 3 | 対象を小さな単位に分割して実施する | 1回のレビューで扱う範囲を絞ることで、個々のレビューやレビューミーティングで集中力が途切れるのを防ぐ | +| 4 | レビュー結果をフィードバックする | 結果をステークホルダーや作成者に返し、成果物だけでなく今後の活動そのものの改善につなげる | +| 5 | 参加者に十分な準備時間を与える | 事前に成果物を読み込んで個々のレビューを行える時間を確保する | +| 6 | マネジメントからの支援を得る | レビュープロセスが組織として正式にサポートされている状態をつくる | +| 7 | レビューを組織文化の一部にする | 学習とプロセス改善を促す文化として、レビューを特別なイベントではなく当たり前の習慣にしていく | +| 8 | 参加者に適切なトレーニングを提供する | 全員が自分の役割を理解し、果たせるようにする | +| 9 | ミーティングを適切にファシリテーションする | 議論が脱線したり停滞したりしないよう、効果的に進行を管理する | + +特に1番目の「参加者個人の評価を目的にしない」という原則は、レビュー文化を定着させるうえで最も重要なポイントだと言えます。レビューで指摘された不正の件数を個人の人事評価に直結させてしまうと、参加者は不正を見つけても報告をためらうようになり、レビュー本来の目的である品質向上が機能しなくなります。心理的安全性が確保された環境でこそ、率直な指摘とそれに対する前向きな受け止め方が成立し、レビューが効果を発揮します。 + +> 出典：ISTQB® CTFL Syllabus v4.0.1, Section 3.2.5, p.37
+> + +--- + +## 3. シラバス補足：実務における静的解析ツールの活用 + +ここからはシラバス本体の範囲を超えた補足情報として、2026年時点での静的解析ツールの実務動向を整理します。CTFL試験の直接の出題範囲ではありませんが、「静的解析」を実務でどう活用するかをイメージできると、3.1節の理解がより立体的になります。 + +### 3.1 代表的な静的解析ツールの位置づけ + +静的解析ツールは大きく「言語特化型のリンター」と「横断的な品質プラットフォーム」の2層に分かれます。リンターはエディタやコミット前のフックで即座にフィードバックを返す一方、単一ファイル単位の解析にとどまり、ファイルをまたいだ解析や品質ゲートの仕組みは持たないのが一般的です。これに対してプラットフォーム型のツールは、複数ファイル・複数言語を横断して解析し、品質の推移をダッシュボードで追跡し、しきい値を下回るコードのマージを品質ゲートでブロックするといった機能を備えています。 + +| 分類 | 代表的なツール | 主な特徴 | +|---|---|---| +| 言語特化型リンター | ESLint（JavaScript / TypeScript）、Pylint・Ruff（Python）、RuboCop（Ruby）、golangci-lint（Go） | 軽量・高速で、エディタ上やコミット前フックでのリアルタイムなフィードバックに向く。基本的に単一ファイル・単一言語の解析にとどまる | +| 横断的な品質プラットフォーム | SonarQube、Codacy、DeepSource | 複数言語・複数ファイルを横断して解析し、技術的負債やコード重複・セキュリティ脆弱性を可視化。CI/CDパイプラインに組み込み、品質ゲートとしてマージをブロックする運用が一般的 | +| セキュリティ特化型（SAST） | Semgrep、Bandit（Python） | ファイルをまたぐデータフロー解析により、インジェクション系の脆弱性などを検出する | + +実務でよく採用される組み合わせとしては、「開発中はエディタ上のリンターで即時フィードバックを得て、CI/CDパイプライン上ではプラットフォーム型ツールで品質ゲートを通す」という二段構えの運用が紹介されています。これは、エディタでの即時フィードバックとパイプライン上の包括的な解析を組み合わせることで、開発の初期段階での問題検出とリリース前の品質保証の両方を実現する考え方であり、3.1.2節で説明した「シフトレフト」の実践そのものと言えます。 + +> 出典：SonarQube vs ESLint: Code Quality Platform vs JavaScript Linter（2026）
+>
+> 12 Best Code Quality Tools in 2026
+> + +### 3.2 静的解析はレビューの代替にはならない + +ここで強調しておきたいのは、静的解析はあくまで「機械的に検出できる種類の欠陥」を効率よく洗い出すための手段であり、シラバス3.1.2で説明した「人手によるレビュー」を置き換えるものではないという点です。静的解析ツールは構文上の問題やパターン化された欠陥（未使用変数、コーディング規約違反、既知の脆弱性パターンなど）の検出には強い一方、「この設計はビジネス要件を正しく満たしているか」「このユーザーストーリーの受け入れ基準は本当に妥当か」といった、文脈理解を要する判断は依然として人手によるレビューでなければ評価できません。CTFL試験的な整理をするなら、静的解析は3.1節（静的テストの基本）の話であり、レビュープロセス（3.2節）はあくまで人を中心とした活動である、という区別を意識しておくとよいでしょう。 + +--- + +## 4. よくある誤解・試験で問われやすいポイント + +CTFL試験の過去の出題傾向や受験者の体験談を踏まえ、特に誤解されやすいポイントを整理しておきます。 + +| 誤解されがちな点 | 正しい理解 | +|---|---| +| 「静的テスト＝コードレビューのこと」 | 静的テストはコードに限らず、要件・設計・テストケース・契約書など、人が読んで理解できるあらゆる作業成果物が対象になる | +| 「静的解析にはテストケースが必要」 | 静的解析はテストケースを必要とせず、ツールによって自動的に実行できる点が静的テストの効率の良さの理由の一つ | +| 「静的テストは欠陥を見つけるだけ」 | 検証だけでなく妥当性確認にも使え、品質特性（可読性・保守性など）の評価や、ステークホルダー間の共通理解の醸成にも貢献する | +| 「インスペクションが常に最善のレビュー種別」 | 公式度が高いほど準備・実施のコストも増える。プロジェクトのリスクや成果物の重要度に見合った種別を選ぶことが重要で、常にインスペクションが正解とは限らない | +| 「レビューでの指摘＝確定した欠陥」 | レビューアが個々のレビューで見つけたものはまず「不正（anomaly）」であり、コミュニケーションと分析の活動を経て初めて欠陥かどうかが判断される | +| 「レビューの成果を担当者の評価に使ってよい」 | シラバスは明確に「参加者の評価をレビューの目的にしてはならない」としている。これを破ると心理的安全性が損なわれ、レビューが形骸化する | +| 「インスペクションでは作成者がリーダーを兼任できる」 | インスペクションでは客観性確保のため、作成者はレビューリーダーにも書記にもなれない | + +--- + +## 5. まとめ + +第3章「静的テスト」の要点を、もう一度俯瞰しておきます。 + +1. **静的テストはソフトウェアを実行せずに行うテストであり、レビュー（人手）と静的解析（ツール）の2本柱から成る。** +2. **静的テストの最大の価値は「最も早い段階で、かつ動的テストでは見つけにくい種類の欠陥を検出できる」ことにある。** 早期テストの原則・シフトレフトと直結する。 +3. **静的テストと動的テストは対立関係ではなく補完関係にあり、両方を組み合わせて初めて効果的な品質保証が成立する。** +4. **レビュープロセスは「計画→開始→個々のレビュー→コミュニケーションと分析→修正と報告」の5活動で構成され、ISO/IEC 20246がその汎用フレームワークを提供している。** +5. **レビューには6つの主要な役割（マネージャー・作成者・モデレーター・書記・レビューア・レビューリーダー）があり、特にインスペクションでは作成者がリーダーや書記を兼任できない。** +6. **レビュー種別は非公式レビュー・ウォークスルー・テクニカルレビュー・インスペクションの順に公式度が高まり、目的や成果物の重要度に応じて選択する。** +7. **レビューを成功させる鍵は、明確な終了基準・適切な種別選択・小さな単位での実施・フィードバックの還元・組織文化への定着など多岐にわたるが、「参加者を評価しない」という原則が土台になる。** + +静的テストは、動的テストに比べて地味に見えるかもしれませんが、コストパフォーマンスの高い品質向上手段として、現場での実践価値は非常に高い領域です。次章（第4章：テスト分析と設計）では、動的テストにおけるテストケースの導出技法を扱いますが、本章で学んだ「早期にレビューで欠陥を取り除く」という発想は、第4章以降のテスト設計の土台としても活きてきます。 + +--- + +## 6. 参考文献・出典一覧 + +| # | 資料名 | URL | +|---|---|---| +| 1 | ISTQB® Certified Tester Foundation Level Syllabus v4.0.1（英語版、2024-09-15） | | +| 2 | ISTQB® CTFL v4.0 認定情報ページ | | +| 3 | JSTQB テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J02（日本語版） | | +| 4 | ISO/IEC 20246:2017 Software and systems engineering — Work product reviews（概要） | | +| 5 | ISO/IEC 20246 関連解説（Stuart Reid, 2018） | | +| 6 | SonarQube vs ESLint: Code Quality Platform vs JavaScript Linter（2026） | | +| 7 | 12 Best Code Quality Tools in 2026 | | +| 8 | SonarQube 公式製品ページ（SonarSource） | | + +> 本資料はISTQB®／JSTQB®の公式シラバスの内容を独自に要約・解説したものであり、公式シラバス本文の逐語的な転載ではありません。試験対策としては必ず公式シラバス原文（上記出典1・3）を一次情報として参照してください。 diff --git a/GEMINI.md b/GEMINI.md index 5b1ae817..d0c7e5b1 100644 --- a/GEMINI.md +++ b/GEMINI.md @@ -17,7 +17,15 @@ This project is a Next.js (App Router) web application designed as a comprehensi > [!IMPORTANT] > **ビルド実行に関する重要ルール (AIエージェント用規約):** -> AIエージェントは、自律的・自動的に本番ビルドコマンド（`bun run build`、`next build` 等）を実行してはなりません。ビルド検証が必要な場合は、自らコマンドを走らせず、必ずユーザーにビルドの実行を依頼してください。勝手に実行すると、ローカル環境のビルドプロセスと競合し、開発を阻害する原因となります。 +> **Antigravityのサンドボックス環境においては**、ビルドのバックグラウンド実行が正常にハンドリングされず、 +> ビルド待ちの状態が続いてローカルメモリを過度に圧迫し、最終的にクラッシュを引き起こす問題が +> 確認されています。 +> そのため、本プロジェクトのルール（`migration-progress-sync.md` や `tdd-mandatory-cycle.md` +> などのゲート条件）でビルドの検証が義務付けられている場合であっても、AIエージェント +> （Antigravity）は**自律的・自動的に本番ビルドコマンド（`bun run build`、`next build` 等）を +> 実行してはなりません（このサンドボックス上の制約は他のあらゆるゲート条件より最優先されます）**。 +> ビルド検証が必要な場合は、自らコマンドを実行せず、必ずユーザーにビルドの実行および成否の確認を +> 依頼してください。 - **Install dependencies:** @@ -86,6 +94,7 @@ This project is a Next.js (App Router) web application designed as a comprehensi - `app/software-testing-methodologies-guide/page.tsx` (テスト手法ガイド) - `app/unit-testing-guide/page.tsx` (ユニットテスト完全ガイド) - `app/istqb-ctfl-at-complete-guide/page.tsx` (アジャイル(CTFL-AT)完全ガイド) +- `app/istqb-ctfl-complete-guide/page.tsx` (ISTQB CTFL v4.0 完全解説ガイド、`NavBar.tsx` 付き) - `app/istqb-ctal-tae-complete-guide/page.tsx` (テスト自動化 CTAL-TAE 完全ガイド) - `app/istqb-ctal-ta-complete-guide/page.tsx` (テストアナリスト CTAL-TA 完全ガイド、`NavBar.tsx` 付き) - `app/istqb-ctal-tm-complete-guide/page.tsx` (テスト管理 CTAL-TM 完全ガイド、`NavBar.tsx` 付き) @@ -172,6 +181,7 @@ This project is a Next.js (App Router) web application designed as a comprehensi | `istqb-ct-game-complete-guide.html` | `/istqb-ct-game-complete-guide` | ✅ NavBar + aria-current あり | | `istqb-ct-tas-complete-guide.html` | `/istqb-ct-tas-complete-guide` | ✅ NavBar あり | | `istqb-ct-ut-complete-guide.html` | `/istqb-ct-ut-complete-guide` | ✅ NavBar あり | +| `Istqb-ctfl.html` | `/istqb-ctfl-complete-guide` | ✅ NavBar あり | | `istqb-ctal-atlas-complete-guide.html` | `/istqb-ctal-atlas-complete-guide` | ✅ NavBar あり | | `istqb-ctal-att-complete-guide.html` | `/istqb-ctal-att-complete-guide` | ✅ NavBar あり | | `istqb-ctal-ta-complete-guide.html` | `/istqb-ctal-ta-complete-guide` | ✅ NavBar あり | diff --git a/app/globals.css b/app/globals.css index 3ab194f4..f6679961 100644 --- a/app/globals.css +++ b/app/globals.css @@ -131,6 +131,31 @@ -ms-overflow-style: none; scrollbar-width: none; } + + /* Mermaid コンポーネントの mermaid-wrapper グローバルデフォルト + 各ページ固有 CSS でスコープ付きの上書きが可能 */ + .mermaid-wrapper { + display: flex; + justify-content: center; + align-items: flex-start; + overflow-x: auto; + margin: 2rem auto; + padding: 1rem; + background: var(--color-bg-card, #131929); + border-radius: var(--radius-DEFAULT, 12px); + border: 1px solid var(--color-border, rgba(99, 179, 237, 0.12)); + box-shadow: var(--shadow-DEFAULT, 0 4px 24px rgba(0, 0, 0, 0.4)); + width: 100%; + max-width: 760px; + } + /* SVG サイズは applySvgFixups（JS）が width:${w}px + maxWidth:100% で制御する。 + CSS は「JS より広い場合に縮小」するフォールバックのみ（width は !important なし）。 */ + .mermaid-wrapper svg { + max-width: 100% !important; + height: auto !important; + display: block; + margin: 0 auto; + } } @layer utilities { @@ -205,1093 +230,1115 @@ } /* ─── BACKGROUND GRID ─── */ - body::before { - content: ''; - position: fixed; - inset: 0; - z-index: -1; - background-image: - linear-gradient(rgba(99, 179, 237, 0.03) 1px, transparent 1px), - linear-gradient(90deg, rgba(99, 179, 237, 0.03) 1px, transparent 1px); - background-size: 40px 40px; - pointer-events: none; - } +body::before { + content: ''; + position: fixed; + inset: 0; + z-index: -1; + background-image: + linear-gradient(rgba(99, 179, 237, 0.03) 1px, transparent 1px), + linear-gradient(90deg, rgba(99, 179, 237, 0.03) 1px, transparent 1px); + background-size: 40px 40px; + pointer-events: none; +} - /* ─── NAV ─── */ - .nav-header { - position: fixed; - top: 0; - left: 0; - right: 0; - z-index: 50; - height: 60px; - display: flex; - align-items: center; - gap: 1.5rem; - padding: 0 2rem; - background-color: rgba(10, 14, 26, 0.85); - backdrop-filter: blur(16px); - -webkit-backdrop-filter: blur(16px); - border-bottom: 1px solid rgba(99, 179, 237, 0.12); - } - .nav-logo { - font-family: var(--font-mono); - font-size: 13px; - font-weight: 700; - color: var(--color-accent-cyan); - letter-spacing: 0.1em; - white-space: nowrap; - margin-right: 1rem; - } - .nav-header { - justify-content: space-between; - } - .nav-hamburger { - display: inline-flex; - align-items: center; - justify-content: center; - width: 40px; - height: 40px; - background: transparent; - border: 1px solid var(--color-border); - border-radius: var(--radius-sm); - color: var(--color-text-secondary); - cursor: pointer; - transition: color 0.2s, border-color 0.2s, background 0.2s; - } - .nav-hamburger:hover { - color: var(--color-accent-cyan); - border-color: var(--color-accent-cyan); - background: rgba(99, 179, 237, 0.06); - } - .nav-hamburger:focus-visible { - outline: 2px solid var(--color-accent-cyan); - outline-offset: 2px; - } - .nav-overlay { - position: fixed; - inset: 60px 0 0 0; - background: rgba(0, 0, 0, 0.45); - backdrop-filter: blur(2px); - -webkit-backdrop-filter: blur(2px); - z-index: 40; - animation: nav-fade-in 0.18s ease-out; - } - .nav-drawer { - position: fixed; - top: 60px; - left: 0; - right: 0; - z-index: 45; - background-color: rgba(15, 20, 35, 0.98); - border-bottom: 1px solid var(--color-border); - padding: 2rem clamp(1rem, 4vw, 3rem); - display: grid; - grid-template-columns: repeat(auto-fit, minmax(240px, 1fr)); - gap: 2rem; - max-height: calc(100vh - 60px); - overflow-y: auto; - box-shadow: var(--shadow-DEFAULT); - animation: nav-slide-down 0.22s ease-out; - } - .nav-drawer-section { - display: flex; - flex-direction: column; - gap: 0.5rem; - } - .nav-drawer-heading { - font-family: var(--font-mono); - font-size: 11px; - font-weight: 600; - color: var(--color-accent-cyan); - letter-spacing: 0.12em; - text-transform: uppercase; - margin: 0 0 0.5rem; - padding-bottom: 0.4rem; - border-bottom: 1px solid var(--color-border); - } - .nav-drawer-list { - list-style: none; - padding: 0; - margin: 0; - display: flex; - flex-direction: column; - gap: 0.15rem; - } - .nav-drawer-list a { - display: block; - padding: 0.5rem 0.75rem; - color: var(--color-text-secondary); - text-decoration: none; - font-size: 13px; - line-height: 1.4; - border-left: 2px solid transparent; - border-radius: 0 var(--radius-sm) var(--radius-sm) 0; - transition: color 0.15s, background 0.15s, border-color 0.15s; - } - .nav-drawer-list a:hover { - color: var(--color-accent-blue); - background: rgba(99, 179, 237, 0.06); +/* ─── NAV ─── */ +.nav-header { + position: fixed; + top: 0; + left: 0; + right: 0; + z-index: 50; + height: 60px; + display: flex; + align-items: center; + gap: 1.5rem; + padding: 0 2rem; + background-color: rgba(10, 14, 26, 0.85); + backdrop-filter: blur(16px); + -webkit-backdrop-filter: blur(16px); + border-bottom: 1px solid rgba(99, 179, 237, 0.12); +} +.nav-logo { + font-family: var(--font-mono); + font-size: 13px; + font-weight: 700; + color: var(--color-accent-cyan); + letter-spacing: 0.1em; + white-space: nowrap; + margin-right: 1rem; +} +.nav-header { + justify-content: space-between; +} +.nav-hamburger { + display: inline-flex; + align-items: center; + justify-content: center; + width: 40px; + height: 40px; + background: transparent; + border: 1px solid var(--color-border); + border-radius: var(--radius-sm); + color: var(--color-text-secondary); + cursor: pointer; + transition: + color 0.2s, + border-color 0.2s, + background 0.2s; +} +.nav-hamburger:hover { + color: var(--color-accent-cyan); + border-color: var(--color-accent-cyan); + background: rgba(99, 179, 237, 0.06); +} +.nav-hamburger:focus-visible { + outline: 2px solid var(--color-accent-cyan); + outline-offset: 2px; +} +.nav-overlay { + position: fixed; + inset: 60px 0 0 0; + background: rgba(0, 0, 0, 0.45); + backdrop-filter: blur(2px); + -webkit-backdrop-filter: blur(2px); + z-index: 40; + animation: nav-fade-in 0.18s ease-out; +} +.nav-drawer { + position: fixed; + top: 60px; + left: 0; + right: 0; + z-index: 45; + background-color: rgba(15, 20, 35, 0.98); + border-bottom: 1px solid var(--color-border); + padding: 2rem clamp(1rem, 4vw, 3rem); + display: grid; + grid-template-columns: repeat(auto-fit, minmax(240px, 1fr)); + gap: 2rem; + max-height: calc(100vh - 60px); + overflow-y: auto; + box-shadow: var(--shadow-DEFAULT); + animation: nav-slide-down 0.22s ease-out; +} +.nav-drawer-section { + display: flex; + flex-direction: column; + gap: 0.5rem; +} +.nav-drawer-heading { + font-family: var(--font-mono); + font-size: 11px; + font-weight: 600; + color: var(--color-accent-cyan); + letter-spacing: 0.12em; + text-transform: uppercase; + margin: 0 0 0.5rem; + padding-bottom: 0.4rem; + border-bottom: 1px solid var(--color-border); +} +.nav-drawer-list { + list-style: none; + padding: 0; + margin: 0; + display: flex; + flex-direction: column; + gap: 0.15rem; +} +.nav-drawer-list a { + display: block; + padding: 0.5rem 0.75rem; + color: var(--color-text-secondary); + text-decoration: none; + font-size: 13px; + line-height: 1.4; + border-left: 2px solid transparent; + border-radius: 0 var(--radius-sm) var(--radius-sm) 0; + transition: + color 0.15s, + background 0.15s, + border-color 0.15s; +} +.nav-drawer-list a:hover { + color: var(--color-accent-blue); + background: rgba(99, 179, 237, 0.06); +} +.nav-drawer-list a[aria-current='page'] { + color: var(--color-accent-cyan); + border-left-color: var(--color-accent-cyan); + background: rgba(99, 179, 237, 0.08); + font-weight: 600; +} +@keyframes nav-fade-in { + from { + opacity: 0; } - .nav-drawer-list a[aria-current="page"] { - color: var(--color-accent-cyan); - border-left-color: var(--color-accent-cyan); - background: rgba(99, 179, 237, 0.08); - font-weight: 600; + to { + opacity: 1; } - @keyframes nav-fade-in { - from { opacity: 0; } - to { opacity: 1; } +} +@keyframes nav-slide-down { + from { + opacity: 0; + transform: translateY(-8px); } - @keyframes nav-slide-down { - from { opacity: 0; transform: translateY(-8px); } - to { opacity: 1; transform: translateY(0); } + to { + opacity: 1; + transform: translateY(0); } +} - /* ─── LAYOUT ─── */ - main { - max-width: 1100px; - margin: 0 auto; - padding: 0 1.5rem; - } +/* ─── LAYOUT ─── */ +main { + max-width: 1100px; + margin: 0 auto; + padding: 0 1.5rem; +} - section { - padding-top: 5rem; - } - section + section { - border-top: 1px solid var(--color-border); - } +section { + padding-top: 5rem; +} +section + section { + border-top: 1px solid var(--color-border); +} - /* ─── HERO ─── */ - .hero { - min-height: 100vh; - display: flex; - flex-direction: column; - justify-content: center; - padding-top: 60px; - position: relative; - overflow: hidden; - } - .hero::after { - content: ''; - position: absolute; - top: 20%; - right: -10%; - width: 600px; - height: 600px; - background: radial-gradient(circle, rgba(79, 209, 197, 0.06) 0%, transparent 60%); - pointer-events: none; - } - .hero-eyebrow { - display: inline-flex; - align-items: center; - gap: 8px; - font-family: var(--font-mono); - font-size: 12px; - font-weight: 500; - color: var(--color-accent-cyan); - letter-spacing: 0.15em; - background: rgba(79, 209, 197, 0.08); - border: 1px solid rgba(79, 209, 197, 0.25); - padding: 6px 14px; - border-radius: 20px; - margin-bottom: 1.5rem; - } - .hero-eyebrow::before { - content: '▶'; - font-size: 9px; - } - .hero h1 { - font-family: var(--font-display); - font-size: clamp(2.2rem, 5vw, 3.8rem); - font-weight: 800; - line-height: 1.15; - color: var(--color-text-primary); - margin-bottom: 1.5rem; - } - .hero h1 span { - color: var(--color-accent-cyan); - } - .hero-sub { - font-size: 1.05rem; - color: var(--color-text-secondary); - max-width: 680px; - line-height: 1.9; - margin-bottom: 2.5rem; - } - .hero-stats { - display: flex; - flex-wrap: wrap; - gap: 1.5rem; - margin-bottom: 3rem; - } - .stat { - display: flex; - flex-direction: column; - padding: 1rem 1.5rem; - background: var(--color-bg-card); - border: 1px solid var(--color-border); - border-radius: var(--radius-sm); - } - .stat-num { - font-family: var(--font-mono); - font-size: 1.5rem; - font-weight: 700; - color: var(--color-accent-cyan); - } - .stat-label { - font-size: 12px; - color: var(--color-text-secondary); - margin-top: 2px; - } +/* ─── HERO ─── */ +.hero { + min-height: 100vh; + display: flex; + flex-direction: column; + justify-content: center; + padding-top: 60px; + position: relative; + overflow: hidden; +} +.hero::after { + content: ''; + position: absolute; + top: 20%; + right: -10%; + width: 600px; + height: 600px; + background: radial-gradient(circle, rgba(79, 209, 197, 0.06) 0%, transparent 60%); + pointer-events: none; +} +.hero-eyebrow { + display: inline-flex; + align-items: center; + gap: 8px; + font-family: var(--font-mono); + font-size: 12px; + font-weight: 500; + color: var(--color-accent-cyan); + letter-spacing: 0.15em; + background: rgba(79, 209, 197, 0.08); + border: 1px solid rgba(79, 209, 197, 0.25); + padding: 6px 14px; + border-radius: 20px; + margin-bottom: 1.5rem; +} +.hero-eyebrow::before { + content: '▶'; + font-size: 9px; +} +.hero h1 { + font-family: var(--font-display); + font-size: clamp(2.2rem, 5vw, 3.8rem); + font-weight: 800; + line-height: 1.15; + color: var(--color-text-primary); + margin-bottom: 1.5rem; +} +.hero h1 span { + color: var(--color-accent-cyan); +} +.hero-sub { + font-size: 1.05rem; + color: var(--color-text-secondary); + max-width: 680px; + line-height: 1.9; + margin-bottom: 2.5rem; +} +.hero-stats { + display: flex; + flex-wrap: wrap; + gap: 1.5rem; + margin-bottom: 3rem; +} +.stat { + display: flex; + flex-direction: column; + padding: 1rem 1.5rem; + background: var(--color-bg-card); + border: 1px solid var(--color-border); + border-radius: var(--radius-sm); +} +.stat-num { + font-family: var(--font-mono); + font-size: 1.5rem; + font-weight: 700; + color: var(--color-accent-cyan); +} +.stat-label { + font-size: 12px; + color: var(--color-text-secondary); + margin-top: 2px; +} - /* ─── PYRAMID VISUAL ─── */ - .pyramid-container { - display: flex; - flex-direction: column; - align-items: center; - gap: 3px; - margin: 2rem 0; - } - .pyramid-layer { - display: flex; - align-items: center; - justify-content: center; - border-radius: 6px; - cursor: pointer; - transition: all 0.25s; - position: relative; - overflow: hidden; - } - .pyramid-layer::before { - content: ''; - position: absolute; - inset: 0; - background: rgba(255, 255, 255, 0.04); - opacity: 0; - transition: opacity 0.2s; - } - .pyramid-layer:hover::before { - opacity: 1; - } - .pyramid-layer .py-label { - font-weight: 700; - font-size: 14px; - z-index: 1; - } - .pyramid-layer .py-sub { - font-size: 11px; - opacity: 0.75; - margin-left: 8px; - z-index: 1; - } - .py-e2e { - width: 35%; - height: 52px; - background: rgba(246, 173, 85, 0.18); - border: 1px solid rgba(246, 173, 85, 0.4); - color: #ffd8a8; - } - .py-func { - width: 57%; - height: 52px; - background: rgba(183, 148, 244, 0.15); - border: 1px solid rgba(183, 148, 244, 0.35); - color: #dec9ff; - } - .py-int { - width: 74%; - height: 52px; - background: rgba(99, 179, 237, 0.13); - border: 1px solid rgba(99, 179, 237, 0.32); - color: #a5d8ff; - } - .py-unit { - width: 100%; - height: 60px; - background: rgba(79, 209, 197, 0.12); - border: 1px solid rgba(79, 209, 197, 0.32); - color: #9bf0e6; - } - .py-axis { - display: flex; - justify-content: space-between; - width: 100%; - margin-top: 8px; - font-size: 11px; - color: var(--color-text-muted); - font-family: var(--font-mono); - } +/* ─── PYRAMID VISUAL ─── */ +.pyramid-container { + display: flex; + flex-direction: column; + align-items: center; + gap: 3px; + margin: 2rem 0; +} +.pyramid-layer { + display: flex; + align-items: center; + justify-content: center; + border-radius: 6px; + cursor: pointer; + transition: all 0.25s; + position: relative; + overflow: hidden; +} +.pyramid-layer::before { + content: ''; + position: absolute; + inset: 0; + background: rgba(255, 255, 255, 0.04); + opacity: 0; + transition: opacity 0.2s; +} +.pyramid-layer:hover::before { + opacity: 1; +} +.pyramid-layer .py-label { + font-weight: 700; + font-size: 14px; + z-index: 1; +} +.pyramid-layer .py-sub { + font-size: 11px; + opacity: 0.75; + margin-left: 8px; + z-index: 1; +} +.py-e2e { + width: 35%; + height: 52px; + background: rgba(246, 173, 85, 0.18); + border: 1px solid rgba(246, 173, 85, 0.4); + color: #ffd8a8; +} +.py-func { + width: 57%; + height: 52px; + background: rgba(183, 148, 244, 0.15); + border: 1px solid rgba(183, 148, 244, 0.35); + color: #dec9ff; +} +.py-int { + width: 74%; + height: 52px; + background: rgba(99, 179, 237, 0.13); + border: 1px solid rgba(99, 179, 237, 0.32); + color: #a5d8ff; +} +.py-unit { + width: 100%; + height: 60px; + background: rgba(79, 209, 197, 0.12); + border: 1px solid rgba(79, 209, 197, 0.32); + color: #9bf0e6; +} +.py-axis { + display: flex; + justify-content: space-between; + width: 100%; + margin-top: 8px; + font-size: 11px; + color: var(--color-text-muted); + font-family: var(--font-mono); +} - /* ─── SECTION HEADERS ─── */ - .section-header { - margin-bottom: 2rem; - } - .section-num { - font-family: var(--font-mono); - font-size: 11px; - font-weight: 700; - color: var(--color-accent-cyan); - letter-spacing: 0.2em; - display: block; - margin-bottom: 0.5rem; - } - .section-header h2 { - font-family: var(--font-display); - font-size: clamp(1.6rem, 3vw, 2.2rem); - font-weight: 700; - line-height: 1.2; - } - .section-header p { - color: var(--color-text-secondary); - margin-top: 0.75rem; - max-width: 680px; - line-height: 1.8; - } - .accent-line { - width: 48px; - height: 3px; - border-radius: 2px; - background: var(--color-accent-cyan); - margin: 1rem 0; - } +/* ─── SECTION HEADERS ─── */ +.section-header { + margin-bottom: 2rem; +} +.section-num { + font-family: var(--font-mono); + font-size: 11px; + font-weight: 700; + color: var(--color-accent-cyan); + letter-spacing: 0.2em; + display: block; + margin-bottom: 0.5rem; +} +.section-header h2 { + font-family: var(--font-display); + font-size: clamp(1.6rem, 3vw, 2.2rem); + font-weight: 700; + line-height: 1.2; +} +.section-header p { + color: var(--color-text-secondary); + margin-top: 0.75rem; + max-width: 680px; + line-height: 1.8; +} +.accent-line { + width: 48px; + height: 3px; + border-radius: 2px; + background: var(--color-accent-cyan); + margin: 1rem 0; +} - /* ─── CARDS ─── */ - .card { - background: var(--color-bg-card); - border: 1px solid var(--color-border); - border-radius: var(--radius-DEFAULT); - padding: 1.5rem; - transition: all 0.25s; - } - .card:hover { - background: var(--color-bg-card-hover); - border-color: var(--color-border-bright); - box-shadow: var(--shadow-DEFAULT); - } - .card-grid { - display: grid; - grid-template-columns: repeat(auto-fit, minmax(280px, 1fr)); - gap: 1rem; - } - .card-sm { - background: var(--color-bg-card); - border: 1px solid var(--color-border); - border-radius: var(--radius-sm); - padding: 1rem 1.25rem; - transition: all 0.2s; - } - .card-sm:hover { - border-color: var(--color-border-bright); - background: var(--color-bg-card-hover); - } +/* ─── CARDS ─── */ +.card { + background: var(--color-bg-card); + border: 1px solid var(--color-border); + border-radius: var(--radius-DEFAULT); + padding: 1.5rem; + transition: all 0.25s; +} +.card:hover { + background: var(--color-bg-card-hover); + border-color: var(--color-border-bright); + box-shadow: var(--shadow-DEFAULT); +} +.card-grid { + display: grid; + grid-template-columns: repeat(auto-fit, minmax(280px, 1fr)); + gap: 1rem; +} +.card-sm { + background: var(--color-bg-card); + border: 1px solid var(--color-border); + border-radius: var(--radius-sm); + padding: 1rem 1.25rem; + transition: all 0.2s; +} +.card-sm:hover { + border-color: var(--color-border-bright); + background: var(--color-bg-card-hover); +} - .card-icon { - font-size: 1.4rem; - margin-bottom: 0.75rem; - display: block; - } - .card h3 { - font-family: var(--font-display); - font-size: 1rem; - font-weight: 600; - margin-bottom: 0.5rem; - color: var(--color-text-primary); - } - .card p { - font-size: 13.5px; - color: var(--color-text-secondary); - line-height: 1.75; - } +.card-icon { + font-size: 1.4rem; + margin-bottom: 0.75rem; + display: block; +} +.card h3 { + font-family: var(--font-display); + font-size: 1rem; + font-weight: 600; + margin-bottom: 0.5rem; + color: var(--color-text-primary); +} +.card p { + font-size: 13.5px; + color: var(--color-text-secondary); + line-height: 1.75; +} - .first-letter-badge { - display: inline-flex; - align-items: center; - justify-content: center; - width: 28px; - height: 28px; - border-radius: 6px; - background: var(--color-unit); - color: var(--color-bg-primary); - font-family: var(--font-mono); - font-size: 1.1rem; - font-weight: 800; - margin-right: 4px; - box-shadow: 0 2px 8px rgba(79, 209, 197, 0.3); - } +.first-letter-badge { + display: inline-flex; + align-items: center; + justify-content: center; + width: 28px; + height: 28px; + border-radius: 6px; + background: var(--color-unit); + color: var(--color-bg-primary); + font-family: var(--font-mono); + font-size: 1.1rem; + font-weight: 800; + margin-right: 4px; + box-shadow: 0 2px 8px rgba(79, 209, 197, 0.3); +} - /* ─── BADGES / TAGS ─── */ - .badge { - display: inline-block; - padding: 3px 10px; - border-radius: 20px; - font-size: 11px; - font-weight: 600; - font-family: var(--font-mono); - letter-spacing: 0.05em; - } - .badge-unit { - background: rgba(79, 209, 197, 0.12); - color: #9bf0e6; - border: 1px solid rgba(79, 209, 197, 0.3); - } - .badge-int { - background: rgba(99, 179, 237, 0.12); - color: #a5d8ff; - border: 1px solid rgba(99, 179, 237, 0.3); - } - .badge-func { - background: rgba(183, 148, 244, 0.12); - color: #dec9ff; - border: 1px solid rgba(183, 148, 244, 0.3); - } - .badge-e2e { - background: rgba(246, 173, 85, 0.12); - color: #ffd8a8; - border: 1px solid rgba(246, 173, 85, 0.3); - } - .badge-sec { - background: rgba(252, 129, 129, 0.12); - color: #ffc9c9; - border: 1px solid rgba(252, 129, 129, 0.3); - } - .badge-perf { - background: rgba(246, 224, 94, 0.12); - color: #fff3bf; - border: 1px solid rgba(246, 224, 94, 0.3); - } - .badge-a11y { - background: rgba(246, 135, 179, 0.12); - color: #ffdeeb; - border: 1px solid rgba(246, 135, 179, 0.3); - } - .badge-istqb { - background: rgba(99, 179, 237, 0.12); - color: #a5d8ff; - border: 1px solid rgba(99, 179, 237, 0.3); - } +/* ─── BADGES / TAGS ─── */ +.badge { + display: inline-block; + padding: 3px 10px; + border-radius: 20px; + font-size: 11px; + font-weight: 600; + font-family: var(--font-mono); + letter-spacing: 0.05em; +} +.badge-unit { + background: rgba(79, 209, 197, 0.12); + color: #9bf0e6; + border: 1px solid rgba(79, 209, 197, 0.3); +} +.badge-int { + background: rgba(99, 179, 237, 0.12); + color: #a5d8ff; + border: 1px solid rgba(99, 179, 237, 0.3); +} +.badge-func { + background: rgba(183, 148, 244, 0.12); + color: #dec9ff; + border: 1px solid rgba(183, 148, 244, 0.3); +} +.badge-e2e { + background: rgba(246, 173, 85, 0.12); + color: #ffd8a8; + border: 1px solid rgba(246, 173, 85, 0.3); +} +.badge-sec { + background: rgba(252, 129, 129, 0.12); + color: #ffc9c9; + border: 1px solid rgba(252, 129, 129, 0.3); +} +.badge-perf { + background: rgba(246, 224, 94, 0.12); + color: #fff3bf; + border: 1px solid rgba(246, 224, 94, 0.3); +} +.badge-a11y { + background: rgba(246, 135, 179, 0.12); + color: #ffdeeb; + border: 1px solid rgba(246, 135, 179, 0.3); +} +.badge-istqb { + background: rgba(99, 179, 237, 0.12); + color: #a5d8ff; + border: 1px solid rgba(99, 179, 237, 0.3); +} - /* ─── CODE BLOCKS ─── */ - .code-block { - background: #080c18; - border: 1px solid var(--color-border); - border-radius: var(--radius-sm); - overflow: hidden; - margin: 1rem 0; - } - .code-header { - display: flex; - align-items: center; - justify-content: space-between; - padding: 8px 14px; - background: rgba(255, 255, 255, 0.03); - border-bottom: 1px solid var(--color-border); - } - .code-dots { - display: flex; - gap: 5px; - } - .code-dots span { - width: 10px; - height: 10px; - border-radius: 50%; - } - .code-dots span:nth-child(1) { - background: #ff5f57; - } - .code-dots span:nth-child(2) { - background: #febc2e; - } - .code-dots span:nth-child(3) { - background: #28c840; - } - .code-lang { - font-family: var(--font-mono); - font-size: 11px; - color: var(--color-text-muted); - letter-spacing: 0.1em; - } - pre { - padding: 1.25rem 1.5rem; - overflow-x: auto; - white-space: pre; - font-family: var(--font-mono); - font-size: 12.5px; - line-height: 1.7; - color: #c9d1e0; - } - .kw { - color: #79b8ff; - } - .fn { - color: #b392f0; - } - .str { - color: #9ecbff; - } - .cm { - color: #8b949e; /* Improved contrast ratio (from #586069) to meet WCAG 2.1 AA on dark backgrounds */ - font-style: italic; - } - .cls { - color: #ffab70; - } - .num { - color: #f0e68c; - } - .dec { - color: #4fc1ff; - } - .op { - color: #e1e4e8; - } +/* ─── CODE BLOCKS ─── */ +.code-block { + background: #080c18; + border: 1px solid var(--color-border); + border-radius: var(--radius-sm); + overflow: hidden; + margin: 1rem 0; +} +.code-header { + display: flex; + align-items: center; + justify-content: space-between; + padding: 8px 14px; + background: rgba(255, 255, 255, 0.03); + border-bottom: 1px solid var(--color-border); +} +.code-dots { + display: flex; + gap: 5px; +} +.code-dots span { + width: 10px; + height: 10px; + border-radius: 50%; +} +.code-dots span:nth-child(1) { + background: #ff5f57; +} +.code-dots span:nth-child(2) { + background: #febc2e; +} +.code-dots span:nth-child(3) { + background: #28c840; +} +.code-lang { + font-family: var(--font-mono); + font-size: 11px; + color: var(--color-text-muted); + letter-spacing: 0.1em; +} +pre { + padding: 1.25rem 1.5rem; + overflow-x: auto; + white-space: pre; + font-family: var(--font-mono); + font-size: 12.5px; + line-height: 1.7; + color: #c9d1e0; +} +.kw { + color: #79b8ff; +} +.fn { + color: #b392f0; +} +.str { + color: #9ecbff; +} +.cm { + color: #8b949e; /* Improved contrast ratio (from #586069) to meet WCAG 2.1 AA on dark backgrounds */ + font-style: italic; +} +.cls { + color: #ffab70; +} +.num { + color: #f0e68c; +} +.dec { + color: #4fc1ff; +} +.op { + color: #e1e4e8; +} - /* Wrap inline code properly so they do not force horizontal scroll */ - :not(pre) > code { - white-space: pre-wrap; - overflow-wrap: anywhere; - border-radius: 4px; - } +/* Wrap inline code properly so they do not force horizontal scroll */ +:not(pre) > code { + white-space: pre-wrap; + overflow-wrap: anywhere; + border-radius: 4px; +} - /* ─── STEP INDICATORS ─── */ - .step-list { - display: flex; - flex-direction: column; - gap: 0; - } - .step-item { - display: flex; - gap: 1.25rem; - padding: 1.25rem 0; - border-bottom: 1px solid var(--color-border); - } - .step-item:last-child { - border-bottom: none; - } - .step-num-circle { - flex-shrink: 0; - width: 32px; - height: 32px; - border-radius: 50%; - display: flex; - align-items: center; - justify-content: center; - font-family: var(--font-mono); - font-size: 12px; - font-weight: 700; - background: rgba(79, 209, 197, 0.1); - border: 1px solid rgba(79, 209, 197, 0.3); - color: var(--color-accent-cyan); - margin-top: 2px; - } - .step-content h4 { - font-family: var(--font-display); - font-size: 0.95rem; - font-weight: 600; - margin-bottom: 0.35rem; - color: var(--color-text-primary); - } - .step-content p { - font-size: 13.5px; - color: var(--color-text-secondary); - line-height: 1.75; - } +/* ─── STEP INDICATORS ─── */ +.step-list { + display: flex; + flex-direction: column; + gap: 0; +} +.step-item { + display: flex; + gap: 1.25rem; + padding: 1.25rem 0; + border-bottom: 1px solid var(--color-border); +} +.step-item:last-child { + border-bottom: none; +} +.step-num-circle { + flex-shrink: 0; + width: 32px; + height: 32px; + border-radius: 50%; + display: flex; + align-items: center; + justify-content: center; + font-family: var(--font-mono); + font-size: 12px; + font-weight: 700; + background: rgba(79, 209, 197, 0.1); + border: 1px solid rgba(79, 209, 197, 0.3); + color: var(--color-accent-cyan); + margin-top: 2px; +} +.step-content h4 { + font-family: var(--font-display); + font-size: 0.95rem; + font-weight: 600; + margin-bottom: 0.35rem; + color: var(--color-text-primary); +} +.step-content p { + font-size: 13.5px; + color: var(--color-text-secondary); + line-height: 1.75; +} - /* ─── COMPARISON TABLE ─── */ - .table-wrapper { - overflow-x: auto; - margin: 1.5rem 0; - } - table { - width: 100%; - border-collapse: collapse; - font-size: 13px; - } - thead tr { - background: rgba(99, 179, 237, 0.08); - border-bottom: 1px solid var(--color-border-bright); - } - th { - padding: 11px 14px; - text-align: left; - font-family: var(--font-mono); - font-size: 11px; - font-weight: 700; - color: var(--color-accent-blue); - letter-spacing: 0.1em; - white-space: nowrap; - } - td { - padding: 10px 14px; - border-bottom: 1px solid var(--color-border); - color: var(--color-text-secondary); - vertical-align: top; - line-height: 1.6; - } - tr:hover td { - background: rgba(99, 179, 237, 0.03); - } - td strong { - color: var(--color-text-primary); - font-weight: 500; - } - td.good { - color: var(--color-accent-green); - } - td.warn { - color: var(--color-accent-yellow); - } - td.bad { - color: var(--color-accent-red); - } +/* ─── COMPARISON TABLE ─── */ +.table-wrapper { + overflow-x: auto; + margin: 1.5rem 0; +} +table { + width: 100%; + border-collapse: collapse; + font-size: 13px; +} +thead tr { + background: rgba(99, 179, 237, 0.08); + border-bottom: 1px solid var(--color-border-bright); +} +th { + padding: 11px 14px; + text-align: left; + font-family: var(--font-mono); + font-size: 11px; + font-weight: 700; + color: var(--color-accent-blue); + letter-spacing: 0.1em; + white-space: nowrap; +} +td { + padding: 10px 14px; + border-bottom: 1px solid var(--color-border); + color: var(--color-text-secondary); + vertical-align: top; + line-height: 1.6; +} +tr:hover td { + background: rgba(99, 179, 237, 0.03); +} +td strong { + color: var(--color-text-primary); + font-weight: 500; +} +td.good { + color: var(--color-accent-green); +} +td.warn { + color: var(--color-accent-yellow); +} +td.bad { + color: var(--color-accent-red); +} - /* ─── TOOL CARDS ─── */ - .tool-grid { - display: grid; - grid-template-columns: repeat(auto-fill, minmax(200px, 1fr)); - gap: 0.75rem; - } - .tool-card { - background: var(--color-bg-card); - border: 1px solid var(--color-border); - border-radius: var(--radius-sm); - padding: 1rem; - transition: all 0.2s; - cursor: default; - display: flex; - flex-direction: column; - gap: 6px; - } - .tool-card:hover { - border-color: var(--color-border-bright); - background: var(--color-bg-card-hover); - transform: translateY(-1px); - } - .tool-name { - font-weight: 600; - font-size: 13.5px; - color: var(--color-text-primary); - } - .tool-desc { - font-size: 12px; - color: var(--color-text-secondary); - line-height: 1.6; - } +/* ─── TOOL CARDS ─── */ +.tool-grid { + display: grid; + grid-template-columns: repeat(auto-fill, minmax(200px, 1fr)); + gap: 0.75rem; +} +.tool-card { + background: var(--color-bg-card); + border: 1px solid var(--color-border); + border-radius: var(--radius-sm); + padding: 1rem; + transition: all 0.2s; + cursor: default; + display: flex; + flex-direction: column; + gap: 6px; +} +.tool-card:hover { + border-color: var(--color-border-bright); + background: var(--color-bg-card-hover); + transform: translateY(-1px); +} +.tool-name { + font-weight: 600; + font-size: 13.5px; + color: var(--color-text-primary); +} +.tool-desc { + font-size: 12px; + color: var(--color-text-secondary); + line-height: 1.6; +} - /* ─── PRINCIPLES GRID ─── */ - .principle-card { - background: var(--color-bg-card); - border: 1px solid var(--color-border); - border-radius: var(--radius-sm); - padding: 1rem 1.25rem; - display: flex; - gap: 1rem; - align-items: flex-start; - transition: all 0.2s; - } - .principle-card:hover { - border-color: var(--color-border-bright); - } - .principle-num { - font-family: var(--font-mono); - font-size: 1.4rem; - font-weight: 700; - color: rgba(99, 179, 237, 0.60); - flex-shrink: 0; - line-height: 1; - margin-top: 3px; - } - .principle-text h4 { - font-size: 13.5px; - font-weight: 600; - margin-bottom: 4px; - color: var(--color-text-primary); - } - .principle-text p { - font-size: 12.5px; - color: var(--color-text-secondary); - line-height: 1.7; - } +/* ─── PRINCIPLES GRID ─── */ +.principle-card { + background: var(--color-bg-card); + border: 1px solid var(--color-border); + border-radius: var(--radius-sm); + padding: 1rem 1.25rem; + display: flex; + gap: 1rem; + align-items: flex-start; + transition: all 0.2s; +} +.principle-card:hover { + border-color: var(--color-border-bright); +} +.principle-num { + font-family: var(--font-mono); + font-size: 1.4rem; + font-weight: 700; + color: rgba(99, 179, 237, 0.6); + flex-shrink: 0; + line-height: 1; + margin-top: 3px; +} +.principle-text h4 { + font-size: 13.5px; + font-weight: 600; + margin-bottom: 4px; + color: var(--color-text-primary); +} +.principle-text p { + font-size: 12.5px; + color: var(--color-text-secondary); + line-height: 1.7; +} - /* ─── OWASP TABLE ─── */ - .owasp-row { - display: flex; - gap: 12px; - align-items: flex-start; - } - .owasp-rank { - flex-shrink: 0; - width: 36px; - height: 36px; - border-radius: 6px; - background: rgba(252, 129, 129, 0.12); - border: 1px solid rgba(252, 129, 129, 0.25); - display: flex; - align-items: center; - justify-content: center; - font-family: var(--font-mono); - font-size: 11px; - font-weight: 700; - color: var(--color-accent-red); - } +/* ─── OWASP TABLE ─── */ +.owasp-row { + display: flex; + gap: 12px; + align-items: flex-start; +} +.owasp-rank { + flex-shrink: 0; + width: 36px; + height: 36px; + border-radius: 6px; + background: rgba(252, 129, 129, 0.12); + border: 1px solid rgba(252, 129, 129, 0.25); + display: flex; + align-items: center; + justify-content: center; + font-family: var(--font-mono); + font-size: 11px; + font-weight: 700; + color: var(--color-accent-red); +} - /* ─── CERT ROADMAP ─── */ - .cert-row { - display: flex; - gap: 1rem; - align-items: stretch; - padding: 1.5rem 0; - border-bottom: 1px solid var(--color-border); - } - .cert-row:last-child { - border-bottom: none; - } - .cert-level-badge { - flex-shrink: 0; - width: 60px; - text-align: center; - display: flex; - flex-direction: column; - align-items: center; - justify-content: flex-start; - gap: 6px; - padding-top: 4px; - } - .cert-level-dot { - width: 14px; - height: 14px; - border-radius: 50%; - margin-bottom: 4px; - } - .cert-level-label { - font-family: var(--font-mono); - font-size: 10px; - writing-mode: vertical-rl; - color: var(--color-text-muted); - letter-spacing: 0.1em; - } - .cert-info h3 { - font-family: var(--font-display); - font-size: 1rem; - font-weight: 600; - color: var(--color-text-primary); - margin-bottom: 6px; - } - .cert-info p { - font-size: 13px; - color: var(--color-text-secondary); - line-height: 1.7; - } - .cert-info .cert-tags { - display: flex; - flex-wrap: wrap; - gap: 6px; - margin-top: 10px; - } +/* ─── CERT ROADMAP ─── */ +.cert-row { + display: flex; + gap: 1rem; + align-items: stretch; + padding: 1.5rem 0; + border-bottom: 1px solid var(--color-border); +} +.cert-row:last-child { + border-bottom: none; +} +.cert-level-badge { + flex-shrink: 0; + width: 60px; + text-align: center; + display: flex; + flex-direction: column; + align-items: center; + justify-content: flex-start; + gap: 6px; + padding-top: 4px; +} +.cert-level-dot { + width: 14px; + height: 14px; + border-radius: 50%; + margin-bottom: 4px; +} +.cert-level-label { + font-family: var(--font-mono); + font-size: 10px; + writing-mode: vertical-rl; + color: var(--color-text-muted); + letter-spacing: 0.1em; +} +.cert-info h3 { + font-family: var(--font-display); + font-size: 1rem; + font-weight: 600; + color: var(--color-text-primary); + margin-bottom: 6px; +} +.cert-info p { + font-size: 13px; + color: var(--color-text-secondary); + line-height: 1.7; +} +.cert-info .cert-tags { + display: flex; + flex-wrap: wrap; + gap: 6px; + margin-top: 10px; +} - /* ─── URL REFERENCE ─── */ - .url-ref { - display: inline-flex; - align-items: center; - gap: 5px; - font-family: var(--font-mono); - font-size: 11px; - color: var(--color-accent-blue); - opacity: 1.0; /* Keep at 1.0 to ensure maximum WCAG contrast ratio on dark backgrounds */ - text-decoration: none; - border-bottom: 1px dashed rgba(99, 179, 237, 0.3); - padding-bottom: 1px; - transition: opacity 0.2s; - } - .url-ref:hover { - opacity: 1; - } - .url-ref::before { - content: '🔗'; - font-size: 10px; - } +/* ─── URL REFERENCE ─── */ +.url-ref { + display: inline-flex; + align-items: center; + gap: 5px; + font-family: var(--font-mono); + font-size: 11px; + color: var(--color-accent-blue); + opacity: 1; /* Keep at 1.0 to ensure maximum WCAG contrast ratio on dark backgrounds */ + text-decoration: none; + border-bottom: 1px dashed rgba(99, 179, 237, 0.3); + padding-bottom: 1px; + transition: opacity 0.2s; +} +.url-ref:hover { + opacity: 1; +} +.url-ref::before { + content: '🔗'; + font-size: 10px; +} - /* ─── TABS ─── */ - .tabs { - margin: 1.5rem 0; - } - .tab-nav { - display: flex; - gap: 4px; - flex-wrap: wrap; - border-bottom: 1px solid var(--color-border); - padding-bottom: 0; - margin-bottom: 1.5rem; - } - .tab-btn { - background: none; - border: none; - cursor: pointer; - padding: 8px 16px; - font-family: var(--font-body); - font-size: 13px; - color: var(--color-text-secondary); - border-bottom: 2px solid transparent; - margin-bottom: -1px; - transition: all 0.2s; - border-radius: 4px 4px 0 0; - } - .tab-btn:hover { - color: var(--color-text-primary); - background: rgba(255, 255, 255, 0.03); - } - .tab-btn.active { - color: var(--color-accent-cyan); - border-bottom-color: var(--color-accent-cyan); - } - .tab-panel { - display: none; - } - .tab-panel.active { - display: block; - } +/* ─── TABS ─── */ +.tabs { + margin: 1.5rem 0; +} +.tab-nav { + display: flex; + gap: 4px; + flex-wrap: wrap; + border-bottom: 1px solid var(--color-border); + padding-bottom: 0; + margin-bottom: 1.5rem; +} +.tab-btn { + background: none; + border: none; + cursor: pointer; + padding: 8px 16px; + font-family: var(--font-body); + font-size: 13px; + color: var(--color-text-secondary); + border-bottom: 2px solid transparent; + margin-bottom: -1px; + transition: all 0.2s; + border-radius: 4px 4px 0 0; +} +.tab-btn:hover { + color: var(--color-text-primary); + background: rgba(255, 255, 255, 0.03); +} +.tab-btn.active { + color: var(--color-accent-cyan); + border-bottom-color: var(--color-accent-cyan); +} +.tab-panel { + display: none; +} +.tab-panel.active { + display: block; +} - /* ─── CALLOUT BOXES ─── */ - .callout { - border-left: 3px solid; - padding: 1rem 1.25rem; - border-radius: 0 var(--radius-sm) var(--radius-sm) 0; - margin: 1rem 0; - font-size: 13.5px; - line-height: 1.75; - } - .callout-info { - border-color: var(--color-accent-blue); - background: rgba(99, 179, 237, 0.06); - } - .callout-warn { - border-color: var(--color-accent-yellow); - background: rgba(246, 224, 94, 0.06); - } - .callout-good { - border-color: var(--color-accent-green); - background: rgba(104, 211, 145, 0.06); - } - .callout-danger { - border-color: var(--color-accent-red); - background: rgba(252, 129, 129, 0.06); - } - .callout strong { - color: var(--color-text-primary); - } - .callout p + p { - margin-top: 0.5rem; - } +/* ─── CALLOUT BOXES ─── */ +.callout { + border-left: 3px solid; + padding: 1rem 1.25rem; + border-radius: 0 var(--radius-sm) var(--radius-sm) 0; + margin: 1rem 0; + font-size: 13.5px; + line-height: 1.75; +} +.callout-info { + border-color: var(--color-accent-blue); + background: rgba(99, 179, 237, 0.06); +} +.callout-warn { + border-color: var(--color-accent-yellow); + background: rgba(246, 224, 94, 0.06); +} +.callout-good { + border-color: var(--color-accent-green); + background: rgba(104, 211, 145, 0.06); +} +.callout-danger { + border-color: var(--color-accent-red); + background: rgba(252, 129, 129, 0.06); +} +.callout strong { + color: var(--color-text-primary); +} +.callout p + p { + margin-top: 0.5rem; +} - /* ─── METRICS GRID ─── */ - .metrics-grid { - display: grid; - grid-template-columns: repeat(auto-fill, minmax(220px, 1fr)); - gap: 0.75rem; - } - .metric-card { - background: var(--color-bg-card); - border: 1px solid var(--color-border); - border-radius: var(--radius-sm); - padding: 1rem; - } - .metric-title { - font-size: 12px; - font-weight: 600; - color: var(--color-text-secondary); - margin-bottom: 4px; - } - .metric-desc { - font-size: 12.5px; - color: var(--color-text-secondary); - line-height: 1.65; - } - .metric-tag { - font-family: var(--font-mono); - font-size: 11px; - color: var(--color-accent-yellow); - display: block; - margin-bottom: 6px; - } +/* ─── METRICS GRID ─── */ +.metrics-grid { + display: grid; + grid-template-columns: repeat(auto-fill, minmax(220px, 1fr)); + gap: 0.75rem; +} +.metric-card { + background: var(--color-bg-card); + border: 1px solid var(--color-border); + border-radius: var(--radius-sm); + padding: 1rem; +} +.metric-title { + font-size: 12px; + font-weight: 600; + color: var(--color-text-secondary); + margin-bottom: 4px; +} +.metric-desc { + font-size: 12.5px; + color: var(--color-text-secondary); + line-height: 1.65; +} +.metric-tag { + font-family: var(--font-mono); + font-size: 11px; + color: var(--color-accent-yellow); + display: block; + margin-bottom: 6px; +} - /* ─── BDD SCENARIO ─── */ - .gherkin { - background: #0a0f1e; - border: 1px solid var(--color-border); - border-radius: var(--radius-sm); - padding: 1.25rem 1.5rem; - font-family: var(--font-mono); - font-size: 13px; - line-height: 1.8; - } - .gherkin .kw-given { - color: #63b3ed; - } - .gherkin .kw-when { - color: #b794f4; - } - .gherkin .kw-then { - color: #68d391; - } - .gherkin .kw-feat { - color: #f6ad55; - font-weight: 700; - } - .gherkin .kw-scen { - color: #f6e05e; - font-weight: 600; - } - .gherkin .param { - color: #f687b3; - } +/* ─── BDD SCENARIO ─── */ +.gherkin { + background: #0a0f1e; + border: 1px solid var(--color-border); + border-radius: var(--radius-sm); + padding: 1.25rem 1.5rem; + font-family: var(--font-mono); + font-size: 13px; + line-height: 1.8; +} +.gherkin .kw-given { + color: #63b3ed; +} +.gherkin .kw-when { + color: #b794f4; +} +.gherkin .kw-then { + color: #68d391; +} +.gherkin .kw-feat { + color: #f6ad55; + font-weight: 700; +} +.gherkin .kw-scen { + color: #f6e05e; + font-weight: 600; +} +.gherkin .param { + color: #f687b3; +} - /* ─── REFERENCES TABLE ─── */ - .ref-table td:first-child { - font-weight: 600; - color: var(--color-text-primary); - white-space: nowrap; - } - .ref-url { - font-family: var(--font-mono); - font-size: 11.5px; - color: var(--color-accent-blue); - text-decoration: none; - opacity: 0.8; - word-break: break-all; - } - .ref-url:hover { - opacity: 1; - } +/* ─── REFERENCES TABLE ─── */ +.ref-table td:first-child { + font-weight: 600; + color: var(--color-text-primary); + white-space: nowrap; +} +.ref-url { + font-family: var(--font-mono); + font-size: 11.5px; + color: var(--color-accent-blue); + text-decoration: none; + opacity: 0.8; + word-break: break-all; +} +.ref-url:hover { + opacity: 1; +} - /* ─── FOOTER ─── */ - footer { - margin-top: 6rem; - padding: 3rem 1.5rem; - border-top: 1px solid var(--color-border); - text-align: center; - color: var(--color-text-muted); - font-size: 13px; - font-family: var(--font-mono); - } - footer a { - color: var(--color-accent-blue); - text-decoration: underline; /* Added underline for better distinguishability without color dependency */ - } +/* ─── FOOTER ─── */ +footer { + margin-top: 6rem; + padding: 3rem 1.5rem; + border-top: 1px solid var(--color-border); + text-align: center; + color: var(--color-text-muted); + font-size: 13px; + font-family: var(--font-mono); +} +footer a { + color: var(--color-accent-blue); + text-decoration: underline; /* Added underline for better distinguishability without color dependency */ +} - /* ─── ANIMATIONS ─── */ - @keyframes fade-up { - from { - opacity: 0; - transform: translateY(20px); - } - to { - opacity: 1; - transform: translateY(0); - } - } - @keyframes pulse-border { - 0%, - 100% { - border-color: rgba(79, 209, 197, 0.2); - } - 50% { - border-color: rgba(79, 209, 197, 0.5); - } +/* ─── ANIMATIONS ─── */ +@keyframes fade-up { + from { + opacity: 0; + transform: translateY(20px); } - .hero-content { - animation: fade-up 0.7s ease forwards; + to { + opacity: 1; + transform: translateY(0); } - .hero-eyebrow { - animation: fade-up 0.5s ease forwards; +} +@keyframes pulse-border { + 0%, + 100% { + border-color: rgba(79, 209, 197, 0.2); } - - /* ─── RESPONSIVE ─── */ - @media (max-width: 768px) { - nav { - padding: 0 1rem; - } - .nav-drawer { - padding: 1.5rem 1rem; - gap: 1.5rem; - } - .hero { - padding-top: 80px; - padding-bottom: 2rem; - } - .cert-row { - flex-direction: column; - } - .cert-level-badge { - flex-direction: row; - width: auto; - } - .cert-level-label { - writing-mode: horizontal-tb; - } + 50% { + border-color: rgba(79, 209, 197, 0.5); } +} +.hero-content { + animation: fade-up 0.7s ease forwards; +} +.hero-eyebrow { + animation: fade-up 0.5s ease forwards; +} - /* ─── UTILITY ─── */ - .mt-1 { - margin-top: 0.5rem; - } - .mt-2 { - margin-top: 1rem; - } - .mt-3 { - margin-top: 1.5rem; - } - .mt-4 { - margin-top: 2rem; +/* ─── RESPONSIVE ─── */ +@media (max-width: 768px) { + nav { + padding: 0 1rem; } - .flex { - display: flex; + .nav-drawer { + padding: 1.5rem 1rem; + gap: 1.5rem; } - .flex-wrap { - flex-wrap: wrap; + .hero { + padding-top: 80px; + padding-bottom: 2rem; } - .gap-1 { - gap: 0.5rem; + .cert-row { + flex-direction: column; } - .gap-2 { - gap: 1rem; + .cert-level-badge { + flex-direction: row; + width: auto; } - .items-start { - align-items: flex-start; + .cert-level-label { + writing-mode: horizontal-tb; } +} + +/* ─── UTILITY ─── */ +.mt-1 { + margin-top: 0.5rem; +} +.mt-2 { + margin-top: 1rem; +} +.mt-3 { + margin-top: 1.5rem; +} +.mt-4 { + margin-top: 2rem; +} +.flex { + display: flex; +} +.flex-wrap { + flex-wrap: wrap; +} +.gap-1 { + gap: 0.5rem; +} +.gap-2 { + gap: 1rem; +} +.items-start { + align-items: flex-start; +} +.grid-2 { + display: grid; + grid-template-columns: 1fr 1fr; + gap: 1rem; +} +@media (max-width: 600px) { .grid-2 { - display: grid; - grid-template-columns: 1fr 1fr; - gap: 1rem; - } - @media (max-width: 600px) { - .grid-2 { - grid-template-columns: 1fr; - } - } - hr.divider { - border: none; - border-top: 1px solid var(--color-border); - margin: 2rem 0; - } - .text-mono { - font-family: var(--font-mono); - } - .text-accent { - color: var(--color-accent-cyan); - } - .text-muted { - color: var(--color-text-muted); - } - .text-sm { - font-size: 13px; + grid-template-columns: 1fr; } +} +hr.divider { + border: none; + border-top: 1px solid var(--color-border); + margin: 2rem 0; +} +.text-mono { + font-family: var(--font-mono); +} +.text-accent { + color: var(--color-accent-cyan); +} +.text-muted { + color: var(--color-text-muted); +} +.text-sm { + font-size: 13px; +} - /* ─── ACCESSIBILITY FIXES ─── */ - /* Ensure links inside body paragraphs, alerts, footers, and other text structures have underlines to pass link-in-text-block audit */ - p a, footer a, .alert a, .callout a, .ulink, .ref-url, .__cf_email__ { - text-decoration: underline; - text-underline-offset: 2px; - } +/* ─── ACCESSIBILITY FIXES ─── */ +/* Ensure links inside body paragraphs, alerts, footers, and other text structures have underlines to pass link-in-text-block audit */ +p a, +footer a, +.alert a, +.callout a, +.ulink, +.ref-url, +.__cf_email__ { + text-decoration: underline; + text-underline-offset: 2px; +} /* Mobile-specific disclaimer banner height to prevent Cumulative Layout Shift (CLS) */ @media (max-width: 768px) { @@ -1308,5 +1355,3 @@ transform: none !important; } } - - diff --git a/app/istqb-ctfl-complete-guide/NavBar.tsx b/app/istqb-ctfl-complete-guide/NavBar.tsx new file mode 100644 index 00000000..a846eff3 --- /dev/null +++ b/app/istqb-ctfl-complete-guide/NavBar.tsx @@ -0,0 +1,134 @@ +'use client'; + +import { useEffect } from 'react'; + +/** + * 左固定の章ナビゲーションを表示します。 + * + * スクロール位置に応じて、表示中のセクションに対応するリンクへ `active` クラスと `aria-current="location"` を設定します。 + */ +export default function NavBar() { + useEffect(() => { + const links = document.querySelectorAll('.sidebar .nav-link'); + const sections = Array.from(links) + .map((link) => { + const href = link.getAttribute('href'); + if (href && href.startsWith('#')) { + return document.getElementById(href.slice(1)); + } + return null; + }) + .filter(Boolean) as HTMLElement[]; + + const observer = new IntersectionObserver( + (entries) => { + const intersectingEntry = entries.find((entry) => entry.isIntersecting); + if (intersectingEntry) { + const id = intersectingEntry.target.getAttribute('id'); + links.forEach((link) => { + if (link.getAttribute('href') === `#${id}`) { + link.classList.add('active'); + link.setAttribute('aria-current', 'location'); + } else { + link.classList.remove('active'); + link.removeAttribute('aria-current'); + } + }); + } + }, + { rootMargin: '-10% 0px -70% 0px' } + ); + + sections.forEach((section) => observer.observe(section)); + + return () => { + observer.disconnect(); + }; + }, []); + + return ( + + ); +} diff --git a/app/istqb-ctfl-complete-guide/istqb-ctfl-complete-guide.css b/app/istqb-ctfl-complete-guide/istqb-ctfl-complete-guide.css new file mode 100644 index 00000000..247f769f --- /dev/null +++ b/app/istqb-ctfl-complete-guide/istqb-ctfl-complete-guide.css @@ -0,0 +1,699 @@ +/* app/istqb-ctfl-complete-guide/istqb-ctfl-complete-guide.css */ + +.istqb-ctfl-layout { + --color-background-primary: #0f1117; + --color-background-secondary: #161b27; + --color-background-tertiary: #1e2536; + --color-background-info: #0d1f3c; + --color-background-danger: #2d1014; + --color-background-success: #0d2218; + --color-background-warning: #2d2210; + --color-text-primary: #e8eaf0; + --color-text-secondary: #d3ddf4; + --color-text-tertiary: #c6d3f8; + --color-text-info: #60a5fa; + --color-text-danger: #f87171; + --color-text-success: #34d399; + --color-text-warning: #fbbf24; + --color-border-primary: #2e3650; + --color-border-secondary: #242c42; + --color-border-tertiary: #1a2035; + --font-sans: 'Hiragino Kino ProN', 'Hiragino Sans', 'Noto Sans JP', system-ui, sans-serif; + --font-mono: 'JetBrains Mono', 'Fira Code', 'Source Code Pro', monospace; + --border-radius-md: 8px; + --border-radius-lg: 12px; + --border-radius-xl: 16px; + --c-purple-50: #f5f3ff; + --c-purple-100: #ede9fe; + --c-purple-200: #ddd6fe; + --c-purple-300: #c4b5fd; + --c-purple-400: #a78bfa; + --c-purple-500: #8b5cf6; + --c-purple-600: #7c3aed; + --c-purple-700: #6d28d9; + --c-purple-800: #5b21b6; + --c-purple-900: #4c1d95; + --c-teal-50: #f0fdfa; + --c-teal-100: #ccfbf1; + --c-teal-200: #99f6e4; + --c-teal-300: #5eead4; + --c-teal-400: #2dd4bf; + --c-teal-500: #14b8a6; + --c-teal-600: #0d9488; + --c-teal-700: #0f766e; + --c-teal-800: #115e59; + --c-teal-900: #134e4a; + --c-coral-50: #fff7ed; + --c-coral-100: #ffedd5; + --c-coral-200: #fed7aa; + --c-coral-300: #fdba74; + --c-coral-400: #fb923c; + --c-coral-500: #f97316; + --c-coral-600: #ea580c; + --c-coral-700: #c2410c; + --c-coral-800: #9a3412; + --c-coral-900: #7c2d12; + --c-pink-50: #fdf2f8; + --c-pink-100: #fce7f3; + --c-pink-200: #fbcfe8; + --c-pink-300: #f9a8d4; + --c-pink-400: #f472b6; + --c-pink-500: #ec4899; + --c-pink-600: #db2777; + --c-pink-700: #be185d; + --c-pink-800: #9d174d; + --c-pink-900: #831843; + --c-blue-500: #3b82f6; + --c-blue-700: #1d4ed8; + --c-blue-200: #bfdbfe; + --c-green-500: #22c55e; + --c-green-700: #15803d; + --c-green-200: #bbf7d0; + --c-amber-500: #f59e0b; + --c-amber-700: #b45309; + --c-amber-200: #fde68a; + --c-red-500: #ef4444; + --c-red-700: #b91c1c; + --c-red-200: #fecaca; +} + +.istqb-ctfl-layout { + display: flex; + min-height: 100vh; + width: 100%; + margin-top: 60px; /* グローバルヘッダー分 */ + background: var(--color-background-primary); + color: var(--color-text-primary); + font-family: var(--font-sans); + font-size: 16px; + line-height: 1.7; + font-weight: 400; +} + +.istqb-ctfl-layout .sidebar { + width: 260px; + min-width: 260px; + background: var(--color-background-secondary); + border-right: 1px solid var(--color-border-secondary); + padding: 24px 0; + height: calc(100vh - 60px - var(--disclaimer-height, 0px)); + overflow-y: auto; + position: sticky; + top: calc(60px + var(--disclaimer-height, 0px)); + scrollbar-width: thin; + scrollbar-color: var(--color-border-primary) transparent; + z-index: 40; +} + +.istqb-ctfl-layout .sidebar-logo { + padding: 0 20px 20px; + border-bottom: 1px solid var(--color-border-tertiary); + margin-bottom: 16px; +} + +.istqb-ctfl-layout .sidebar-logo h2 { + font-size: 13px; + font-weight: 500; + color: var(--c-purple-400); + letter-spacing: 0.04em; + text-transform: uppercase; + line-height: 1.4; +} + +.istqb-ctfl-layout .sidebar-logo span { + font-size: 11px; + color: var(--color-text-tertiary); + display: block; + margin-top: 4px; +} + +.istqb-ctfl-layout .nav-section { + padding: 0 12px 8px; +} + +.istqb-ctfl-layout .nav-label { + font-size: 11px; + font-weight: 500; + color: var(--color-text-tertiary); + text-transform: uppercase; + letter-spacing: 0.06em; + padding: 8px 8px 4px; +} + +.istqb-ctfl-layout .nav-link { + display: block; + padding: 6px 8px; + font-size: 13px; + color: var(--color-text-secondary); + text-decoration: none; + border-radius: var(--border-radius-md); + transition: + background 0.15s, + color 0.15s; + line-height: 1.4; +} + +.istqb-ctfl-layout .nav-link:hover { + background: var(--color-background-tertiary); + color: var(--color-text-primary); +} + +.istqb-ctfl-layout .nav-link.active, +.istqb-ctfl-layout .nav-link[aria-current='location'] { + background: var(--color-background-tertiary); + color: var(--c-purple-300); + font-weight: 500; +} + +.istqb-ctfl-layout .nav-sub { + padding-left: 12px; +} + +.istqb-ctfl-layout .nav-sub .nav-link { + font-size: 12px; + padding: 4px 8px; + color: var(--color-text-tertiary); +} + +.istqb-ctfl-layout .nav-sub .nav-link:hover { + color: var(--color-text-secondary); +} + +.istqb-ctfl-layout .main { + flex: 1; + min-width: 0; + padding: 40px 32px; + overflow-x: hidden; + background: var(--color-background-primary); +} + +.istqb-ctfl-layout .hero { + margin-bottom: 48px; + padding-bottom: 32px; + border-bottom: 1px solid var(--color-border-secondary); +} + +.istqb-ctfl-layout .hero-badge { + display: inline-flex; + align-items: center; + gap: 6px; + background: var(--color-background-tertiary); + border: 1px solid var(--c-purple-800); + color: var(--c-purple-300); + font-size: 12px; + font-weight: 500; + padding: 4px 10px; + border-radius: 20px; + margin-bottom: 16px; +} + +.istqb-ctfl-layout h1 { + font-size: 22px; + font-weight: 500; + color: var(--color-text-primary); + line-height: 1.3; + margin-bottom: 12px; +} + +.istqb-ctfl-layout h2 { + font-size: 18px; + font-weight: 500; + color: var(--color-text-primary); + margin-top: 48px; + margin-bottom: 16px; + padding-bottom: 8px; + border-bottom: 1px solid var(--color-border-secondary); + scroll-margin-top: calc(60px + var(--disclaimer-height, 0px)); /* 固定ヘッダー + 免責バナー分 */ +} + +/* ナビゲーションのハッシュリンクは section/div のラッパー id を指すため、 + ラッパー自体にもスクロールオフセットを付与して見出しが固定ヘッダー下に隠れないようにする。 */ +.istqb-ctfl-layout section[id], +.istqb-ctfl-layout div[id] { + scroll-margin-top: calc(60px + var(--disclaimer-height, 0px)); +} + +.istqb-ctfl-layout h3 { + font-size: 16px; + font-weight: 500; + color: var(--color-text-primary); + margin-top: 28px; + margin-bottom: 12px; + scroll-margin-top: calc(60px + var(--disclaimer-height, 0px)); /* 固定ヘッダー + 免責バナー分 */ +} + +.istqb-ctfl-layout h4 { + font-size: 14px; + font-weight: 500; + color: var(--c-teal-400); + margin-top: 20px; + margin-bottom: 8px; + text-transform: uppercase; + letter-spacing: 0.04em; +} + +.istqb-ctfl-layout p { + margin-bottom: 14px; + color: var(--color-text-primary); +} + +.istqb-ctfl-layout a { + color: var(--c-purple-400); + text-decoration: none; +} + +.istqb-ctfl-layout a:hover { + color: var(--c-purple-300); + text-decoration: underline; +} + +.istqb-ctfl-layout .meta-grid { + display: grid; + grid-template-columns: repeat(3, 1fr); + gap: 12px; + margin-bottom: 24px; +} + +.istqb-ctfl-layout .meta-card { + background: var(--color-background-secondary); + border: 1px solid var(--color-border-secondary); + border-radius: var(--border-radius-lg); + padding: 16px; +} + +.istqb-ctfl-layout .meta-card .label { + font-size: 11px; + font-weight: 500; + color: var(--color-text-tertiary); + text-transform: uppercase; + letter-spacing: 0.05em; + margin-bottom: 6px; +} + +.istqb-ctfl-layout .meta-card .value { + font-size: 20px; + font-weight: 500; + color: var(--c-purple-300); +} + +.istqb-ctfl-layout .meta-card .sub { + font-size: 12px; + color: var(--color-text-tertiary); + margin-top: 2px; +} + +.istqb-ctfl-layout table { + width: 100%; + border-collapse: collapse; + font-size: 14px; + margin: 16px 0 24px; +} + +.istqb-ctfl-layout th { + background: var(--color-background-tertiary); + color: var(--color-text-secondary); + font-weight: 500; + font-size: 12px; + text-transform: uppercase; + letter-spacing: 0.04em; + padding: 10px 14px; + text-align: left; + border-bottom: 1px solid var(--color-border-primary); +} + +.istqb-ctfl-layout td { + padding: 9px 14px; + border-bottom: 1px solid var(--color-border-tertiary); + color: var(--color-text-primary); + vertical-align: top; +} + +.istqb-ctfl-layout tr:last-child td { + border-bottom: none; +} + +.istqb-ctfl-layout tr:hover td { + background: var(--color-background-secondary); +} + +.istqb-ctfl-layout .mermaid { + background: var(--color-background-secondary); + border: 1px solid var(--color-border-secondary); + border-radius: var(--border-radius-lg); + padding: 24px; + margin: 16px 0 24px; + overflow-x: auto; + display: flex; + justify-content: center; + align-items: flex-start; + width: 100%; +} + +/* Mermaid コンポーネントが出力する mermaid-wrapper を CTFL ページ専用でリセット。 + グローバルデフォルト（globals.css）の card 背景・border・shadow を除去し、 + .mermaid ラッパーのスタイルを活かす。 + SVG サイズは applySvgFixups（JS）が width:${w}px + maxWidth:100% で制御するため + CSS 側では max-width を上書きしない。 */ +.istqb-ctfl-layout .mermaid-wrapper { + width: 100%; + max-width: 100%; + margin: 0 auto !important; + padding: 0 !important; + background: transparent !important; + border: none !important; + border-radius: 0 !important; + box-shadow: none !important; + display: flex; + justify-content: center; + overflow-x: auto; +} + +/* SVG はスキルの正準 applySvgFixups が width:${w}px + maxWidth:100% を設定済み。 + CSS は縮小フォールバックのみ（!important なし）。 */ +.istqb-ctfl-layout .mermaid-wrapper svg { + max-width: 100%; + height: auto; + display: block; + margin: 0 auto; +} + +.istqb-ctfl-layout .callout { + border-radius: var(--border-radius-lg); + padding: 14px 18px; + margin: 16px 0; + font-size: 14px; + border-left: 3px solid; +} + +.istqb-ctfl-layout .callout-info { + background: var(--color-background-info); + border-color: var(--c-blue-500); + color: var(--c-blue-200); +} + +.istqb-ctfl-layout .callout-warning { + background: var(--color-background-warning); + border-color: var(--c-amber-500); + color: var(--c-amber-200); +} + +.istqb-ctfl-layout .callout-success { + background: var(--color-background-success); + border-color: var(--c-green-500); + color: var(--c-green-200); +} + +.istqb-ctfl-layout .callout-danger { + background: var(--color-background-danger); + border-color: var(--c-red-500); + color: var(--c-red-200); +} + +.istqb-ctfl-layout .callout strong { + font-weight: 500; +} + +.istqb-ctfl-layout .tag { + display: inline-block; + font-size: 11px; + font-weight: 500; + padding: 2px 8px; + border-radius: 4px; +} + +.istqb-ctfl-layout .tag-purple { + background: var(--c-purple-800); + color: var(--c-purple-200); +} + +.istqb-ctfl-layout .tag-teal { + background: var(--c-teal-800); + color: var(--c-teal-200); +} + +.istqb-ctfl-layout .tag-coral { + background: var(--c-coral-800); + color: var(--c-coral-200); +} + +.istqb-ctfl-layout .tag-amber { + background: var(--c-amber-700); + color: var(--c-amber-200); +} + +.istqb-ctfl-layout .tag-red { + background: var(--c-red-700); + color: var(--c-red-200); +} + +.istqb-ctfl-layout .tag-green { + background: var(--c-green-700); + color: var(--c-green-200); +} + +.istqb-ctfl-layout .principle-grid { + display: grid; + grid-template-columns: repeat(2, 1fr); + gap: 12px; + margin: 16px 0 24px; +} + +.istqb-ctfl-layout .principle-card { + background: var(--color-background-secondary); + border: 1px solid var(--color-border-secondary); + border-radius: var(--border-radius-lg); + padding: 16px; +} + +.istqb-ctfl-layout .principle-card .num { + font-size: 11px; + font-weight: 500; + color: var(--c-purple-400); + text-transform: uppercase; + letter-spacing: 0.05em; + margin-bottom: 6px; +} + +.istqb-ctfl-layout .principle-card h4 { + font-size: 14px; + font-weight: 500; + color: var(--color-text-primary); + margin: 0 0 6px 0; + text-transform: none; + letter-spacing: 0; +} + +.istqb-ctfl-layout .principle-card p { + font-size: 13px; + color: var(--color-text-secondary); + margin: 0; + line-height: 1.5; +} + +.istqb-ctfl-layout .chapter-bar { + display: flex; + align-items: center; + gap: 12px; + background: var(--color-background-secondary); + border: 1px solid var(--color-border-secondary); + border-radius: var(--border-radius-md); + padding: 10px 16px; + margin: 8px 0; +} + +.istqb-ctfl-layout .chapter-bar .ch-name { + font-size: 13px; + color: var(--color-text-primary); + flex: 1; +} + +.istqb-ctfl-layout .chapter-bar .ch-count { + font-size: 12px; + font-weight: 500; + color: var(--c-purple-300); + min-width: 40px; + text-align: right; +} + +.istqb-ctfl-layout .progress-bar { + height: 4px; + background: var(--color-border-secondary); + border-radius: 2px; + flex: 2; + overflow: hidden; +} + +.istqb-ctfl-layout .progress-fill { + height: 100%; + border-radius: 2px; +} + +.istqb-ctfl-layout .section-sep { + border: none; + border-top: 1px solid var(--color-border-tertiary); + margin: 40px 0; +} + +.istqb-ctfl-layout code { + font-family: var(--font-mono); + font-size: 13px; + background: var(--color-background-tertiary); + color: var(--c-coral-300); + padding: 2px 6px; + border-radius: 4px; +} + +.istqb-ctfl-layout pre { + background: var(--color-background-tertiary); + border: 1px solid var(--color-border-secondary); + border-radius: var(--border-radius-md); + padding: 16px; + overflow-x: auto; + margin: 12px 0 20px; +} + +.istqb-ctfl-layout pre code { + background: none; + padding: 0; + color: var(--color-text-primary); + font-size: 13px; +} + +.istqb-ctfl-layout .url-list { + background: var(--color-background-secondary); + border: 1px solid var(--color-border-secondary); + border-radius: var(--border-radius-lg); + padding: 16px 20px; + margin: 16px 0; +} + +.istqb-ctfl-layout .url-item { + display: flex; + align-items: flex-start; + gap: 10px; + padding: 8px 0; + border-bottom: 1px solid var(--color-border-tertiary); + font-size: 13px; +} + +.istqb-ctfl-layout .url-item:last-child { + border-bottom: none; +} + +.istqb-ctfl-layout .url-item .url-title { + color: var(--color-text-primary); + font-weight: 500; + min-width: 200px; + flex-shrink: 0; +} + +.istqb-ctfl-layout .url-item a { + color: var(--c-teal-400); + font-size: 12px; + word-break: break-all; +} + +.istqb-ctfl-layout .two-col { + display: grid; + grid-template-columns: 1fr 1fr; + gap: 16px; + margin: 16px 0; +} + +.istqb-ctfl-layout .box { + background: var(--color-background-secondary); + border: 1px solid var(--color-border-secondary); + border-radius: var(--border-radius-lg); + padding: 16px; +} + +.istqb-ctfl-layout .box h4 { + font-size: 13px; + font-weight: 500; + color: var(--c-teal-400); + margin: 0 0 10px 0; + text-transform: uppercase; + letter-spacing: 0.04em; +} + +.istqb-ctfl-layout .box ul { + list-style: none; + padding: 0; +} + +.istqb-ctfl-layout .box ul li { + font-size: 13px; + color: var(--color-text-secondary); + padding: 4px 0; + padding-left: 14px; + position: relative; +} + +.istqb-ctfl-layout .box ul li::before { + content: ''; + position: absolute; + left: 0; + top: 12px; + width: 4px; + height: 4px; + border-radius: 50%; + background: var(--c-teal-600); +} + +.istqb-ctfl-layout .klevel { + display: inline-flex; + align-items: center; + justify-content: center; + width: 28px; + height: 28px; + border-radius: 50%; + font-size: 12px; + font-weight: 500; +} + +.istqb-ctfl-layout .k1 { + background: var(--c-teal-800); + color: var(--c-teal-200); +} + +.istqb-ctfl-layout .k2 { + background: var(--c-purple-800); + color: var(--c-purple-200); +} + +.istqb-ctfl-layout .k3 { + background: var(--c-coral-800); + color: var(--c-coral-200); +} + +.istqb-ctfl-layout .footer-note { + margin-top: 64px; + padding: 20px; + background: var(--color-background-secondary); + border: 1px solid var(--color-border-secondary); + border-radius: var(--border-radius-lg); + font-size: 13px; + color: var(--color-text-tertiary); + text-align: center; +} + +@media (max-width: 900px) { + .istqb-ctfl-layout { + margin-top: 60px; + } + .istqb-ctfl-layout .sidebar { + display: none; + } + .istqb-ctfl-layout .main { + padding: 24px 20px; + } + .istqb-ctfl-layout .meta-grid { + grid-template-columns: 1fr 1fr; + } + .istqb-ctfl-layout .principle-grid { + grid-template-columns: 1fr; + } + .istqb-ctfl-layout .two-col { + grid-template-columns: 1fr; + } +} diff --git a/app/istqb-ctfl-complete-guide/page.tsx b/app/istqb-ctfl-complete-guide/page.tsx new file mode 100644 index 00000000..326ad794 --- /dev/null +++ b/app/istqb-ctfl-complete-guide/page.tsx @@ -0,0 +1,1686 @@ +import NavBar from './NavBar'; +import Mermaid from '../../components/Mermaid'; +import './istqb-ctfl-complete-guide.css'; + +export const metadata = { + title: 'ISTQB CTFL v4.0 完全解説ガイド | Certified Tester Foundation Level', + description: 'ISTQB Certified Tester Foundation Level (CTFL) v4.0 のシラバス v4.0.1 に完全準拠した日本語解説ガイド。', +}; + +/** + * Renders the ISTQB CTFL v4.0.1 complete guide page. + */ +export default function IstqbCtflCompleteGuide() { + return ( +
+ +
+ +
+
ISTQB Syllabus v4.0.1 準拠 | 2026年6月更新
+

ISTQB Certified Tester Foundation Level (CTFL) v4.0
完全解説ガイド

+

+ 中級者〜上級者向け。試験配点・技法の実践計算・よく混同される用語まで、 + シラバス v4.0.1 の全6章をステップバイステップで解説します。 +

+
+ +
+

概要・試験情報

+

+ CTFL v4.0 は 2023年4月21日にリリースされた ISTQB + フラッグシップ資格の完全再設計版です。 旧 Foundation + Agile Extension + を統合し、ウォーターフォール・アジャイル・DevOps・ + 継続的デリバリーに横断的に適用できる現代的なシラバスへと生まれ変わりました。 + 2024年11月に保守更新版 v4.0.1 が公開されましたが試験内容の変更はありません。 +

+ +
+

試験仕様

+
+
+
問題数
+
40問
+
多肢選択式・各1点
+
+
+
合格スコア
+
26 / 40
+
65% 以上
+
+
+
試験時間
+
60分
+
非母国語受験者 +25% = 75分
+
+
+
形式
+
クローズドブック
+
持ち込み不可
+
+
+
有効期限
+
終身有効
+
更新不要
+
+
+
前提条件
+
なし
+
誰でも受験可能
+
+
+
+ +
+

章別出題配分

+
+ Chapter 1: テストの基礎 +
+
+
+ 8問 (20%) +
+
+ Chapter 2: SDLCでのテスト +
+
+
+ 6問 (15%) +
+
+ Chapter 3: 静的テスト +
+
+
+ 4問 (10%) +
+
+ Chapter 4: テスト分析・設計 + 最重要 +
+
+
+ 11問 (27.5%) +
+
+ Chapter 5: テスト活動の管理 +
+
+
+ 9問 (22.5%) +
+
+ Chapter 6: テストツール +
+
+
+ 2問 (5%) +
+
+ 試験戦略上の要点: Chapter 4（27.5%）と Chapter + 5（22.5%）の2章だけで試験全体の50%を占めます。 特に Chapter 4 の + K3（適用）レベル問題は実際に計算を行う必要があるため、反復練習が必須です。 +
+
+ +
+

認定スキームにおける位置付け

+
+ TA +CTFL --> TTA +CTFL --> TM +CTFL --> TAE +CTFL --> AGILE +CTFL --> AI +CTFL --> GENAI +style CTFL fill:#5b21b6,stroke:#7c3aed,color:#ede9fe +style TA fill:#1e2536,stroke:#2e3650,color:#9ba3b8 +style TTA fill:#1e2536,stroke:#2e3650,color:#9ba3b8 +style TM fill:#1e2536,stroke:#2e3650,color:#9ba3b8 +style TAE fill:#1e2536,stroke:#2e3650,color:#9ba3b8 +style AGILE fill:#1e2536,stroke:#2e3650,color:#9ba3b8 +style AI fill:#1e2536,stroke:#2e3650,color:#9ba3b8 +style GENAI fill:#1e2536,stroke:#2e3650,color:#9ba3b8`} /> +
+
+ 2026年最新動向: CT-AI v2.0 が + 2026年4月にリリース（v1.0は2027年4月21日に英語試験終了）。 CT-GenAI v1.1 + も並行して提供中。CTAL-TA v4.0 が 2025年5月リリース、旧 v3.1 英語試験は + 2026年5月に終了。 +
+
+
+ +
+ +
+

Chapter 1: テストの基礎

+

+ Chapter 1 + は試験全体の語彙と概念的土台を提供します。ここを曖昧にすると他の章の問題でも + 「言葉の罠」に引っかかります。定義を正確に暗記するだけでなく、各概念の境界線を理解することが重要です。 +

+ +

テストとは何か

+

+ CTFL v4.0 における「テスト」は単なるバグ探しではありません。 + 動的テスト（ソフトウェアを実行してテスト）と + 静的テスト（実行せずにテスト）の両方を含み、 + 検証（Verification） と + 妥当性確認（Validation） を包含します。 +

+ + + + + + + + + + + + + + + + + + + + +
概念問い内容
検証 (Verification)「正しく作っているか？」仕様通りに実装されているか確認
妥当性確認 (Validation)「正しいものを作っているか？」ユーザーのニーズを満たしているか確認
+ +
+

エラー・欠陥・障害の連鎖

+
+ |引き起こす| D +D -->|引き起こす可能性がある| F +R -->|特定することで| E +style E fill:#134e4a,stroke:#14b8a6,color:#99f6e4 +style D fill:#4c1d95,stroke:#8b5cf6,color:#ddd6fe +style F fill:#7c2d12,stroke:#f97316,color:#fed7aa +style R fill:#1e2536,stroke:#2e3650,color:#9ba3b8`} /> +
+
+ 重要: + テストとデバッグは別の活動。テストは障害を特定し、デバッグはその原因（欠陥）を除去する。 + また、欠陥は必ずしも障害を引き起こすとは限りません（デッドコード、条件分岐で実行されない欠陥など）。 +
+ +

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

+ + + + + + + + + + + + + + + + + + + + + + + + + +
観点テスト (QC)品質保証 (QA)
目的欠陥を検出する（是正措置）プロセスを改善する（予防措置）
対象成果物 (Product)プロセス (Process)
関係QC の一部組織レベルの活動
+
+ +
+

テストの7原則

+
+ 試験必出: 7原則は K1（定義の再現）と + K2（概念の説明）レベルで問われます。 + 特に「殺虫剤のパラドックス」「欠陥ゼロの誤謬」などの逆説的な原則は引っかけ問題の定番です。 +
+
+
+
原則 1
+

テストは欠陥の存在を示す

+

+ 欠陥があることは示せるが、欠陥がないことは証明できない。テストは欠陥ゼロの証明手段ではない。 +

+
+
+
原則 2
+

網羅的テストは不可能

+

+ すべての入力・条件の組み合わせをテストするのは現実不可能。リスクベース・優先度付けで対応する。 +

+
+
+
原則 3
+

早期テスト（シフトレフト）

+

+ テストは早期に開始すべき。後工程での欠陥修正は指数的にコスト増大する。要件段階からレビューを実施。 +

+
+
+
原則 4
+

欠陥クラスタリング

+

+ 欠陥は少数のモジュールに集中する傾向がある（80:20則）。リスクの高いモジュールを重点的にテスト。 +

+
+
+
原則 5
+

殺虫剤のパラドックス

+

+ 同じテストを繰り返すと新たな欠陥を見つけられなくなる。テストケースを定期的に見直し・更新する。 +

+
+
+
原則 6
+

テストはコンテキスト依存

+

+ テスト手法は開発方法論・ドメイン・リスクによって変わる。汎用的な「最良のテスト」は存在しない。 +

+
+
+
原則 7
+

欠陥ゼロの誤謬 (Absence-of-defects fallacy)

+

+ 欠陥が見つからなくてもユーザーのニーズを満たすとは限らない。品質は「欠陥ゼロ」ではなく妥当性確認で判断する。 +

+
+
+
+ +
+

テストプロセスの7アクティビティ

+
+ TM +TM -.-> TA +TA --> TD +TD --> TI +TI --> TE +TE --> TC +style TP fill:#134e4a,stroke:#14b8a6,color:#99f6e4 +style TM fill:#4c1d95,stroke:#8b5cf6,color:#ddd6fe +style TA fill:#134e4a,stroke:#14b8a6,color:#99f6e4 +style TD fill:#134e4a,stroke:#14b8a6,color:#99f6e4 +style TI fill:#134e4a,stroke:#14b8a6,color:#99f6e4 +style TE fill:#134e4a,stroke:#14b8a6,color:#99f6e4 +style TC fill:#134e4a,stroke:#14b8a6,color:#99f6e4`} /> +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
アクティビティ主な成果物 (Testware)
テスト計画テスト計画書、リスク登録簿
テスト分析テスト条件、テストベースの欠陥レポート
テスト設計テストケース、テストチャーター
テスト実装テスト手順、自動化スクリプト、テストスイート
テスト実行テスト結果ログ、欠陥レポート
テスト完了テスト完了レポート、改善アクションリスト
+
+
+ +
+ +
+

Chapter 2: SDLCとテスト

+ +

SDLCモデルとテストアプローチの対応

+
+ SEQ +SDLC --> ITER +SEQ --> WF +SEQ --> VM +ITER --> AGILE +ITER --> DEVOPS +style SDLC fill:#4c1d95,stroke:#7c3aed,color:#ede9fe +style SEQ fill:#1e2536,stroke:#2e3650,color:#9ba3b8 +style ITER fill:#1e2536,stroke:#2e3650,color:#9ba3b8 +style WF fill:#134e4a,stroke:#14b8a6,color:#99f6e4 +style VM fill:#134e4a,stroke:#14b8a6,color:#99f6e4 +style AGILE fill:#7c2d12,stroke:#f97316,color:#fed7aa +style DEVOPS fill:#7c2d12,stroke:#f97316,color:#fed7aa`} /> +
+ +
+

シフトレフトと DevOps

+
+ D +D --> C +C --> T +T --> DEP +style R fill:#134e4a,stroke:#14b8a6,color:#99f6e4 +style D fill:#134e4a,stroke:#14b8a6,color:#99f6e4 +style C fill:#134e4a,stroke:#14b8a6,color:#99f6e4 +style T fill:#4c1d95,stroke:#8b5cf6,color:#ddd6fe +style DEP fill:#1e2536,stroke:#2e3650,color:#9ba3b8`} /> +
+ + + + + + + + + + + + + + + + + + + + + + + + + +
DevOps の特徴テストへの影響
継続的インテグレーション (CI)自動回帰テストが必須、プッシュごとに実行
継続的デリバリー (CD)テストの高速化・安定化が必要、パイプラインゲート
全員オーナーシップテストがチーム全員の責任（Whole Team Approach）
フィードバックループの短縮テスト結果の即時可視化・ダッシュボードの整備
+
+ +
+

テストレベル（5段階）

+
+ CIT +CIT --> ST +ST --> SIT +SIT --> AT +style CT fill:#134e4a,stroke:#14b8a6,color:#99f6e4 +style CIT fill:#134e4a,stroke:#14b8a6,color:#99f6e4 +style ST fill:#4c1d95,stroke:#8b5cf6,color:#ddd6fe +style SIT fill:#4c1d95,stroke:#8b5cf6,color:#ddd6fe +style AT fill:#7c2d12,stroke:#f97316,color:#fed7aa`} /> +
+ +

受け入れテストの4種類（試験頻出）

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
種別実施者目的
UAT（ユーザー受け入れテスト）実ユーザー実業務での動作確認
OAT（運用受け入れテスト）運用チームインフラ・運用観点での検証
契約・規制テスト顧客・監査人契約条件・法規制への準拠確認
アルファ・ベータテスト限定ユーザーα=開発環境、β=本番相当環境での早期検証
+
+ +
+

テストタイプ

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
タイプ観点主な技法・例
機能テスト「何ができるか」EP・BVA・デシジョンテーブル
非機能テスト「どのように動くか」パフォーマンス・セキュリティ・使用性
ホワイトボックステストコード構造ベースステートメント・ブランチカバレッジ
確認テスト欠陥修正後の再確認修正された欠陥を直接再テスト
回帰テスト変更による影響確認変更した機能以外への副作用チェック
+
+ ISO/IEC 25010 非機能品質特性: + パフォーマンス効率・使用性 (Usability)・ 信頼性 + (Reliability)・セキュリティ・保守性 (Maintainability)・移植性 + (Portability) など。 Chapter 2 と Chapter 5 の両方で問われます。 +
+
+
+ +
+ +
+

Chapter 3: 静的テスト

+

+ 静的テストはソフトウェアを実行せずに欠陥を検出する手法です。 + 動的テストでは発見しにくい、要件の曖昧さ・設計の脆弱性・デッドコードなどを早期に発見できます。 +

+ +
+

レビュープロセス

+
+ IN +IN --> IR +IR --> CA +CA --> FR +style PL fill:#134e4a,stroke:#14b8a6,color:#99f6e4 +style IN fill:#134e4a,stroke:#14b8a6,color:#99f6e4 +style IR fill:#4c1d95,stroke:#8b5cf6,color:#ddd6fe +style CA fill:#4c1d95,stroke:#8b5cf6,color:#ddd6fe +style FR fill:#7c2d12,stroke:#f97316,color:#fed7aa`} /> +
+
+ +
+

レビュータイプの比較

+
+ 試験最頻出: + 4種類のレビューの「形式度」「誰がリーダーか」「ドキュメントが必須か」を正確に覚えてください。 + 特に「ウォークスルーは著者がリーダー、インスペクションはモデレーターがリーダー」は頻繁に出題されます。 +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
タイプ形式度リーダー主目的ドキュメント
インフォーマルレビュー最低—欠陥検出（非公式）不要
ウォークスルー低〜中著者理解・フィードバック収集軽度
テクニカルレビュー中訓練されたモデレーター合意形成・技術的欠陥検出要
インスペクション最高訓練されたモデレーター欠陥検出・プロセス改善必須（メトリクス含む）
+ +

レビュー技法

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
技法特徴適用場面
アドホックレビュー事前準備なし、経験依存簡易・非公式なレビュー
チェックリストベース定型チェックリストに従う繰り返し実施する成果物のレビュー
シナリオベース想定シナリオ・ユースケースから確認要件・設計のレビュー
パースペクティブベース特定ステークホルダーの視点から確認多角的なレビューが必要な複雑な成果物
ロールベース特定の役割（セキュリティ専門家等）の観点セキュリティ・コンプライアンスレビュー
+
+
+ +
+ +
+

Chapter 4: テスト分析・設計

+

+ 試験の27.5%（11問）を占める最重要章です。 + K3（適用）レベルの問題が集中しており、具体的な仕様から実際にテストケースを導出できる + 実践力が問われます。EP・BVA の計算問題は必ず手を動かして練習してください。 +

+ +
+ BB +TT --> WB +TT --> EB +TT --> CB +BB --> EP["同値分割 (EP)"] +BB --> BVA["境界値分析 (BVA) 2値 / 3値"] +BB --> DT["デシジョンテーブル"] +BB --> ST["状態遷移テスト"] +WB --> SC["ステートメントカバレッジ"] +WB --> BC["ブランチカバレッジ"] +EB --> EXP["探索的テスト"] +EB --> CL["チェックリストベース"] +CB --> US["ユーザーストーリー共同作成"] +CB --> ATDD2["ATDD / GWT"] +style TT fill:#4c1d95,stroke:#7c3aed,color:#ede9fe +style BB fill:#134e4a,stroke:#14b8a6,color:#99f6e4 +style WB fill:#7c2d12,stroke:#f97316,color:#fed7aa +style EB fill:#831843,stroke:#ec4899,color:#fbcfe8 +style CB fill:#1e2536,stroke:#8b5cf6,color:#ddd6fe`} /> +
+ +
+

同値分割（Equivalence Partitioning: EP）

+

+ 入力値を「同じ動作をする」グループ（同値クラス）に分割し、各グループから代表値を1つだけ選んでテストする技法。 + テストケース数を削減しながら、効率的なカバレッジを達成します。 +

+

具体例: 年齢入力フィールド（有効: 18〜65歳）

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
同値クラス範囲種別代表値の例
EP118未満無効0, 10, 17
EP218〜65有効30, 45
EP365超無効66, 100
+
+ カバレッジ計算:
+ EP カバレッジ = テスト済み同値クラス数 ÷ 全同値クラス数 × 100%
+ 上記の例で EP1 と EP2 のみテスト済み → 2 ÷ 3 = 66.7%（100%達成には EP3 + も必要） +
+
+ +
+

境界値分析（Boundary Value Analysis: BVA）

+

+ 境界付近の値に欠陥が集中するという経験則を活用した技法。 開発者が + <= を < と誤記するような境界の + off-by-one エラーを 効率的に検出します。BVA + は順序付きパーティション（数値・日付・文字列長など）にのみ適用可能です。 +

+
+
+

2値 BVA（2-value BVA）

+
    +
  • 各境界値と、隣接パーティションの最近傍値をテスト
    • +
  • 範囲 18〜65 の場合: 17, 18, 65, 66
    • +
  • 各境界につき2つの値 → 境界数 × 2
    • +
  • 100% カバレッジ = 全境界値を網羅
    • +
+
+
+

3値 BVA（3-value BVA）

+
    +
  • 境界値・外側の隣接値・内側の隣接値をテスト
    • +
  • + 範囲 18〜65 の場合: 17, 18, 19, 64, 65, 66 +
    • +
  • 各境界につき3つの値 → より厳密なカバレッジ
    • +
  • 2値BVAでは検出できない欠陥も検出可能
    • +
+
+
+
+ K3 試験問題の典型: 「範囲 1〜100 + の入力フィールドに対して、3値BVAで必要なテスト値の数はいくつか？」
+ → 下限境界: 0, 1, 2（3値）、上限境界: 99, 100, 101（3値）= 合計 + 6値 +
+
+ +
+

デシジョンテーブルテスト

+

+ 複数の条件の組み合わせによるシステム動作を体系的に網羅します。 n個の条件 + → 最大 2n + のルールが存在（同一アクションのルールは統合可能）。 +

+

具体例: ローン審査（収入 × 信用スコア）

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ルール 1ルール 2ルール 3ルール 4
条件
収入 ≥ 500万円TTFF
信用スコア ≥ 700TFTF
アクション
ローン承認✓———
再審査—✓✓—
否決———✓
+

+ ルール 2 と 3 が同じアクション（再審査）→ 収入条件を「Don't + Care」に統合して最小化可能。 +

+
+ +
+

状態遷移テスト

+

+ システムの状態変化をモデル化してテストケースを設計します。 + ATM・ログイン・注文ライフサイクルなど、状態依存の動作を持つシステムに有効です。 +

+
+ ロック中 +ロック中 --> ロック中 : 誤ったPIN（残り2回以上） +ロック中 --> ロック解除 : 正しいPIN +ロック中 --> アカウント停止 : 誤ったPINを3回入力 +ロック解除 --> ロック中 : タイムアウト / ログアウト +ロック解除 --> [*] : セッション終了 +アカウント停止 --> [*]`} /> +
+ + + + + + + + + + + + + + + + + + + + + +
カバレッジ基準内容
全状態カバレッジすべての状態を少なくとも1回通過
全遷移カバレッジ（0スイッチ）すべての遷移を少なくとも1回通過（最低基準）
nスイッチカバレッジ長さ n+1 の遷移シーケンスをすべてカバー（コスト高）
+
+ +
+

ホワイトボックステスト技法

+

ステートメントテスト vs ブランチテスト

+
+
def check_discount(age, is_member):
+
discount = 0 # Line 1: 常に実行
+
if age > 60: # Line 2: 判定
+
discount = 10 # Line 3: True ブランチ
+
if is_member: # Line 4: 判定
+
discount += 5 # Line 5: True ブランチ
+
return discount # Line 6: 常に実行
+
+ + + + + + + + + + + + + + + + + + + + +
カバレッジ基準必要なテスト達成条件
100% ステートメントLine 3 と Line 5 の両方を実行age > 60 かつ is_member のケースを含む
100% ブランチ各 if の True / False を両方実行age > 60 の T/F × is_member の T/F = 最低3テスト
+
+ 試験頻出の罠: 100% ブランチカバレッジ ⊃ 100% + ステートメントカバレッジ（包含関係）。 + 逆（ステートメント100%→ブランチ100%）は成立しません。 例: + if (condition) { action(); } で condition が常に True + のケースのみ実行しても ステートメントは100%になるが、False + ブランチはカバーされない。 +
+
+ +
+

探索的テスト

+

+ テストの設計・実行・学習を同時並行で行う動的なアプローチ。 + テスターの知識・経験・好奇心を最大限に活用し、形式的なテストでは見逃しやすい欠陥を発見します。 +

+ + + + + + + + + + + + + + + + + + + + + +
要素説明
テストチャーター + 「[ターゲット] を [リソース] を使って [発見すべき情報] + を探索する」という形式の目的定義文書 +
セッション時間制約のあるテスト実施単位（通常 30〜120 分）
デブリーフィングセッション後の振り返り・所見の共有・次回方針決定
+
+ +
+

ATDD・コラボレーションベース技法（v4.0 新追加）

+

INVEST 原則（ユーザーストーリー品質評価）

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
頭文字意味確認ポイント
Independent独立している他のストーリーに依存せずにデリバリー可能か
Negotiable交渉可能実装の詳細は柔軟に変更できるか
Valuable価値があるステークホルダーに明確なビジネス価値があるか
Estimable見積もり可能チームがサイズを見積もれるか
Small小さい1スプリントで完成できるサイズか
Testableテスト可能明確な受け入れ基準があるか
+ +

Given-When-Then (GWT) 形式

+
+
Given: ユーザーがログイン画面にいる
+
When: 有効なユーザーIDとパスワードを入力し「ログイン」ボタンを押す
+
Then: ダッシュボード画面に遷移し、ユーザー名が表示される
+
+ +
+ DIST +DIST --> DEV +DEV --> DISC +style DISC fill:#134e4a,stroke:#14b8a6,color:#99f6e4 +style DIST fill:#4c1d95,stroke:#8b5cf6,color:#ddd6fe +style DEV fill:#7c2d12,stroke:#f97316,color:#fed7aa`} /> +
+
+
+ +
+ +
+

Chapter 5: テスト活動の管理

+ +
+

テスト計画

+

テストピラミッドとテスト四象限

+
+
+

テストピラミッド

+
    +
  • 下段: ユニットテスト（多数・低コスト・高速）
    • +
  • 中段: 統合テスト（中程度）
    • +
  • 上段: E2E / UIテスト（少数・高コスト・低速）
    • +
  • 自動化投資はピラミッドの下段に集中
    • +
+
+
+

テスト推定技法

+
    +
  • メトリクスベース: 過去データから推定
    • +
  • エキスパートベース: デルファイ法・専門家集約
    • +
  • プランニングポーカー: アジャイルチームの合意ベース
    • +
  • WBS: 作業分解構造から積み上げ
    • +
+
+
+ +

テスト四象限（Brian Marick モデル）

+ + + + + + + + + + + + + + + + + + + + +
ビジネスを支援技術を評価
チームを支援（開発ガイド）Q2: 機能テスト・ストーリーテスト（自動 / 手動）Q1: 自動単体・統合テスト
製品を批評（評価）Q3: 探索的テスト・UAT・使用性テストQ4: パフォーマンス・セキュリティ・信頼性テスト
+
+ +
+

リスク管理

+

リスクの分類

+ + + + + + + + + + + + + + + + + + + + +
種別定義例
プロジェクトリスクプロジェクト目標達成を脅かすリスクスケジュール遅延・リソース不足・ベンダー問題
プロダクトリスクソフトウェアの品質特性に関するリスクセキュリティ脆弱性・パフォーマンス問題・データ損失
+
+ RA +RA --> RC +RC --> RI +style RI fill:#134e4a,stroke:#14b8a6,color:#99f6e4 +style RA fill:#4c1d95,stroke:#8b5cf6,color:#ddd6fe +style RC fill:#7c2d12,stroke:#f97316,color:#fed7aa`} /> +
+
+ リスクレベルの公式: リスクレベル = 発生確率 + (Likelihood) × 影響度 (Impact)
+ 高リスク → 広いカバレッジ・早期テスト・頻繁な確認
+ 低リスク → 最小限のテストまたは実施を省略 +
+
+ +
+

テストモニタリング・コントロール・完了

+

主要テストメトリクス

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
カテゴリメトリクス例
進捗テストケース実行率・消化率・残テスト数
欠陥欠陥検出数・欠陥密度・修正率・エスケープ率
カバレッジ要件カバレッジ・コードカバレッジ・リスクカバレッジ
リスク残存リスクレベル・リスク軽減率
コスト予算消化率・テストコスト対欠陥発見数
+ +

テストレポートの種類

+ + + + + + + + + + + + + + + + + + + + +
種別目的主な読者
テスト進捗レポート定期的な状況報告（日次・週次）テストマネージャー・PM
テスト完了レポートフェーズ・プロジェクト完了時の総括全ステークホルダー
+
+ +
+

欠陥管理

+
+ 新規New +新規New --> 確認中Assigned : 担当者アサイン +確認中Assigned --> 修正中InProgress : 開発者が対応開始 +修正中InProgress --> 確認待ちFixed : 修正完了 +確認待ちFixed --> クローズClosed : 確認テスト成功 +確認待ちFixed --> 再オープンReopen : 確認テスト失敗 +再オープンReopen --> 修正中InProgress : 再修正 +新規New --> 棄却Rejected : 欠陥でないと判断 +棄却Rejected --> [*] +クローズClosed --> [*] +新規New : 新規 (New) +確認中Assigned : 確認中 (Assigned) +修正中InProgress : 修正中 (In Progress) +確認待ちFixed : 確認待ち (Fixed) +クローズClosed : クローズ (Closed) +再オープンReopen : 再オープン (Reopen) +棄却Rejected : 棄却 (Rejected)`} /> +
+
+ 頻出の混同ポイント — 重要度 vs 優先度:
+ 重要度 (Severity): 技術的影響度。Critical / Major / + Minor / Trivial
+ 優先度 (Priority): ビジネス修正緊急度。High / Medium / + Low
+ 例: UIの誤字（重要度 Trivial）でも、トップページならば優先度 High + になる場合がある。 この2つは完全に独立した概念です。 +
+
+
+ +
+ +
+

Chapter 6: テストツール

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ツールカテゴリ例目的
テスト管理Jira, TestRail, Zephyr Scaleテスト計画・実行・追跡
静的テストSonarQube, Checkstyle, ESLint静的解析・コードレビュー支援
テスト実行・カバレッジJUnit, pytest, JaCoCo, Coverage.pyテスト自動実行・カバレッジ計測
パフォーマンスJMeter, Gatling, k6負荷・スループット・応答時間テスト
セキュリティOWASP ZAP, Burp Suite脆弱性スキャン・ペネトレーションテスト
BDD / ATDDCucumber, SpecFlow, FitNesseGWT 形式のテスト実装
CI/CD 統合Jenkins, GitHub Actions, GitLab CIパイプライン組み込み自動テスト
+ +

テスト自動化のメリット vs リスク

+
+
+

メリット

+
    +
  • 回帰テストの繰り返し実行コスト削減
    • +
  • CI/CDパイプラインで夜間も継続実行
    • +
  • 人的ミスの排除・再現性の確保
    • +
  • 大量データを使ったデータ駆動テスト
    • +
  • パフォーマンス・負荷テストの実現
    • +
+
+
+

リスク

+
    +
  • 初期開発・保守コストの過小評価
    • +
  • アプリ変更のたびにスクリプト更新が必要
    • +
  • フォルスポジティブ / ネガティブのリスク
    • +
  • 探索的テストは自動化できない
    • +
  • 「自動化すれば解決する」という誤解
    • +
+
+
+
+ 試験ポイント: + 自動化は手動テストの補完であり、置き換えではありません。 + 特に探索的テスト・ユーザビリティテスト・一度しか実行しないテストは手動が適切です。 +
+
+ +
+ +
+

試験対策・学習戦略

+ +

K-Level 別の出題傾向

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
K-Level要求レベル主な章問題例
K1 覚える定義・用語を再現するCh.1, Ch.3「欠陥クラスタリングの定義は？」
K2 理解する概念を自分の言葉で説明Ch.2, Ch.5, Ch.6 + 「ブランチカバレッジ100%のとき、ステートメントカバレッジは？」 +
K3 適用する具体的な状況に技法を適用Ch.4, Ch.5「以下の仕様から3値BVAテストケースを導出せよ」
+ +

よく混同される用語ペア

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
用語 A用語 B区別の核心
検証 (Verification)妥当性確認 (Validation)仕様準拠 vs ユーザーニーズ充足
欠陥 (Defect)障害 (Failure)コードの誤り vs 実行時の誤動作
重要度 (Severity)優先度 (Priority)技術的影響度 vs ビジネス修正緊急度
ウォークスルーインスペクション著者主導・非公式 vs モデレーター主導・最公式
ステートメントカバレッジブランチカバレッジ命令網羅 vs 分岐網羅（後者が上位）
プロジェクトリスクプロダクトリスクスケジュール等 vs 品質特性
確認テスト回帰テスト修正欠陥の直接確認 vs 変更による副作用確認
テスト計画 (Planning)テストコントロール (Control)計画立案 vs 乖離時の是正措置
+ +

推奨学習ステップ

+
+ S2 +S2 --> S3 +S3 --> S4 +S4 --> S5 +S5 --> S6 +S6 --> S7 +style S1 fill:#134e4a,stroke:#14b8a6,color:#99f6e4 +style S2 fill:#134e4a,stroke:#14b8a6,color:#99f6e4 +style S3 fill:#134e4a,stroke:#14b8a6,color:#99f6e4 +style S4 fill:#4c1d95,stroke:#8b5cf6,color:#ddd6fe +style S5 fill:#4c1d95,stroke:#8b5cf6,color:#ddd6fe +style S6 fill:#7c2d12,stroke:#f97316,color:#fed7aa +style S7 fill:#0f766e,stroke:#14b8a6,color:#99f6e4`} /> +
+
+ +
+ +
+

参考文献・公式リソース

+

+ 本ガイドの作成にあたり参照したすべての URL + を掲載しています。試験前には必ず公式サイトで最新情報を確認してください。 +

+ +

公式一次情報（ISTQB）

+
+ + +
+ 公式用語集 (Glossary) + + https://glossary.istqb.org/en_US/search + +
+ + + +
+ サンプル試験 C（解答付き） + + istqb.org / Sample Exam C Answers v1.6 PDF + +
+ +
+ +

補助学習リソース（2026年確認済み）

+
+
+ ISTQB.com 試験ガイド（2026版） + + https://www.istqb.com/ctfl-v4-0/ + +
+
+ ISTQB Guru — チートシート 2026 + + https://www.istqb.guru/istqb-ctfl-cheat-sheet/ + +
+ +
+ ISTQB Guru — 認定レベル全体ロードマップ 2026 + + https://www.istqb.guru/istqb-certification-levels-roadmap/ + +
+
+ istqb.com — 認定一覧 2026 + + https://www.istqb.com/certifications/ + +
+
+ Mock Exam Network — 無料模擬試験（1855問） + + https://mockexamnetwork.com/exams/istqb-foundation/ + +
+ +
+ SoftwareTestingHelp — EP/BVA 演習問題 + + https://www.softwaretestinghelp.com / EP-BVA ISTQB Questions (2026) + +
+
+ CTAL-TA v4.0 ガイド（上位認定参考） + + https://www.istqb.com/ctal-ta-v4-0/ + +
+
+ +

次のステップ（上位認定）

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
認定対象者試験
+ CTAL-TA v4.0 + 機能テスト・ブラックボックス専門家45問 / 78点満点 / 65%合格
CTAL-TTAホワイトボックス・非機能テスト専門家45問 / 120分
CTAL-TM v3.0テスト管理・マネジメント職50問 / 90分
CTAL-TAE自動化フレームワーク設計者—
+ CT-AI v2.0 + AIシステムのテスト専門家（2026年4月リリース）—
CT-GenAI v1.1生成AIツールを使ったテスト専門家—
+
+ +
+ 本ガイドは ISTQB CTFL Syllabus v4.0.1（2024年11月公開）および + 2026年6月時点の公式サイト情報に基づいて作成しています。
+ 試験仕様・ダウンロードリンクは変更される場合があります。受験前に必ず + istqb.org + で最新情報を確認してください。
+ 作成日: 2026年6月 | 対応バージョン: ISTQB CTFL Syllabus v4.0.1 +
+
+
+ ); +} diff --git a/archive/html-archive/Istqb-ctfl.html b/archive/html-archive/Istqb-ctfl.html new file mode 100644 index 00000000..5a102082 --- /dev/null +++ b/archive/html-archive/Istqb-ctfl.html @@ -0,0 +1,2402 @@ + + + + + + ISTQB CTFL v4.0 完全解説ガイド + + + + + + +
+ + +
+
+
ISTQB Syllabus v4.0.1 準拠 | 2026年6月更新
+

ISTQB Certified Tester Foundation Level (CTFL) v4.0
完全解説ガイド

+

+ 中級者〜上級者向け。試験配点・技法の実践計算・よく混同される用語まで、 + シラバス v4.0.1 の全6章をステップバイステップで解説します。 +

+
+ +
+

概要・試験情報

+

+ CTFL v4.0 は 2023年4月21日にリリースされた ISTQB + フラッグシップ資格の完全再設計版です。 旧 Foundation + Agile Extension + を統合し、ウォーターフォール・アジャイル・DevOps・ + 継続的デリバリーに横断的に適用できる現代的なシラバスへと生まれ変わりました。 + 2024年11月に保守更新版 v4.0.1 が公開されましたが試験内容の変更はありません。 +

+ +
+

試験仕様

+
+
+
問題数
+
40問
+
多肢選択式・各1点
+
+
+
合格スコア
+
26 / 40
+
65% 以上
+
+
+
試験時間
+
60分
+
非母国語受験者 +25% = 75分
+
+
+
形式
+
クローズドブック
+
持ち込み不可
+
+
+
有効期限
+
終身有効
+
更新不要
+
+
+
前提条件
+
なし
+
誰でも受験可能
+
+
+
+ +
+

章別出題配分

+
+ Chapter 1: テストの基礎 +
+
+
+ 8問 (20%) +
+
+ Chapter 2: SDLCでのテスト +
+
+
+ 6問 (15%) +
+
+ Chapter 3: 静的テスト +
+
+
+ 4問 (10%) +
+
+ Chapter 4: テスト分析・設計 + 最重要 +
+
+
+ 11問 (27.5%) +
+
+ Chapter 5: テスト活動の管理 +
+
+
+ 9問 (22.5%) +
+
+ Chapter 6: テストツール +
+
+
+ 2問 (5%) +
+
+ 試験戦略上の要点: Chapter 4（27.5%）と Chapter + 5（22.5%）の2章だけで試験全体の50%を占めます。 特に Chapter 4 の + K3（適用）レベル問題は実際に計算を行う必要があるため、反復練習が必須です。 +
+
+ +
+

認定スキームにおける位置付け

+
+
+ 2026年最新動向: CT-AI v2.0 が + 2026年4月にリリース（v1.0は2027年4月に英語試験終了）。 CT-GenAI v1.1 + も並行して提供中。CTAL-TA v4.0 が 2025年5月リリース、旧 v3.1 英語試験は + 2026年5月に終了。 +
+
+
+ +
+ +
+

Chapter 1: テストの基礎

+

+ Chapter 1 + は試験全体の語彙と概念的土台を提供します。ここを曖昧にすると他の章の問題でも + 「言葉の罠」に引っかかります。定義を正確に暗記するだけでなく、各概念の境界線を理解することが重要です。 +

+ +

テストとは何か

+

+ CTFL v4.0 における「テスト」は単なるバグ探しではありません。 + 動的テスト（ソフトウェアを実行してテスト）と + 静的テスト（実行せずにテスト）の両方を含み、 + 検証（Verification） と + 妥当性確認（Validation） を包含します。 +

+ + + + + + + + + + + + + + + + + + + + +
概念問い内容
検証 (Verification)「正しく作っているか？」仕様通りに実装されているか確認
妥当性確認 (Validation)「正しいものを作っているか？」ユーザーのニーズを満たしているか確認
+ +
+

エラー・欠陥・障害の連鎖

+
+
+ 重要: + テストとデバッグは別の活動。テストは障害を特定し、デバッグはその原因（欠陥）を除去する。 + また、欠陥は必ずしも障害を引き起こすとは限りません（デッドコード、条件分岐で実行されない欠陥など）。 +
+ +

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

+ + + + + + + + + + + + + + + + + + + + + + + + + +
観点テスト (QC)品質保証 (QA)
目的欠陥を検出する（是正措置）プロセスを改善する（予防措置）
対象成果物 (Product)プロセス (Process)
関係QC の一部組織レベルの活動
+
+ +
+

テストの7原則

+
+ 試験必出: 7原則は K1（定義の再現）と + K2（概念の説明）レベルで問われます。 + 特に「殺虫剤のパラドックス」「欠陥ゼロの誤謬」などの逆説的な原則は引っかけ問題の定番です。 +
+
+
+
原則 1
+

テストは欠陥の存在を示す

+

+ 欠陥があることは示せるが、欠陥がないことは証明できない。テストは欠陥ゼロの証明手段ではない。 +

+
+
+
原則 2
+

網羅的テストは不可能

+

+ すべての入力・条件の組み合わせをテストするのは現実不可能。リスクベース・優先度付けで対応する。 +

+
+
+
原則 3
+

早期テスト（シフトレフト）

+

+ テストは早期に開始すべき。後工程での欠陥修正は指数的にコスト増大する。要件段階からレビューを実施。 +

+
+
+
原則 4
+

欠陥クラスタリング

+

+ 欠陥は少数のモジュールに集中する傾向がある（80:20則）。リスクの高いモジュールを重点的にテスト。 +

+
+
+
原則 5
+

殺虫剤のパラドックス

+

+ 同じテストを繰り返すと新たな欠陥を見つけられなくなる。テストケースを定期的に見直し・更新する。 +

+
+
+
原則 6
+

テストはコンテキスト依存

+

+ テスト手法は開発方法論・ドメイン・リスクによって変わる。汎用的な「最良のテスト」は存在しない。 +

+
+
+
原則 7
+

欠陥ゼロの誤謬 (Absence-of-defects fallacy)

+

+ 欠陥が見つからなくてもユーザーのニーズを満たすとは限らない。品質は「欠陥ゼロ」ではなく妥当性確認で判断する。 +

+
+
+
+ +
+

テストプロセスの7アクティビティ

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
アクティビティ主な成果物 (Testware)
テスト計画テスト計画書、リスク登録簿
テスト分析テスト条件、テストベースの欠陥レポート
テスト設計テストケース、テストチャーター
テスト実装テスト手順、自動化スクリプト、テストスイート
テスト実行テスト結果ログ、欠陥レポート
テスト完了テスト完了レポート、改善アクションリスト
+
+
+ +
+ +
+

Chapter 2: SDLCとテスト

+ +

SDLCモデルとテストアプローチの対応

+
+ +
+

シフトレフトと DevOps

+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
DevOps の特徴テストへの影響
継続的インテグレーション (CI)自動回帰テストが必須、プッシュごとに実行
継続的デリバリー (CD)テストの高速化・安定化が必要、パイプラインゲート
全員オーナーシップテストがチーム全員の責任（Whole Team Approach）
フィードバックループの短縮テスト結果の即時可視化・ダッシュボードの整備
+
+ +
+

テストレベル（5段階）

+
+ +

受け入れテストの4種類（試験頻出）

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
種別実施者目的
UAT（ユーザー受け入れテスト）実ユーザー実業務での動作確認
OAT（運用受け入れテスト）運用チームインフラ・運用観点での検証
契約・規制テスト顧客・監査人契約条件・法規制への準拠確認
アルファ・ベータテスト限定ユーザーα=開発環境、β=本番相当環境での早期検証
+
+ +
+

テストタイプ

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
タイプ観点主な技法・例
機能テスト「何ができるか」EP・BVA・デシジョンテーブル
非機能テスト「どのように動くか」パフォーマンス・セキュリティ・使用性
ホワイトボックステストコード構造ベースステートメント・ブランチカバレッジ
確認テスト欠陥修正後の再確認修正された欠陥を直接再テスト
回帰テスト変更による影響確認変更した機能以外への副作用チェック
+
+ ISO/IEC 25010 非機能品質特性: + パフォーマンス効率・使用性 (Usability)・ 信頼性 + (Reliability)・セキュリティ・保守性 (Maintainability)・移植性 + (Portability) など。 Chapter 2 と Chapter 5 の両方で問われます。 +
+
+
+ +
+ +
+

Chapter 3: 静的テスト

+

+ 静的テストはソフトウェアを実行せずに欠陥を検出する手法です。 + 動的テストでは発見しにくい、要件の曖昧さ・設計の脆弱性・デッドコードなどを早期に発見できます。 +

+ +
+

レビュープロセス

+
+
+ +
+

レビュータイプの比較

+
+ 試験最頻出: + 4種類のレビューの「形式度」「誰がリーダーか」「ドキュメントが必須か」を正確に覚えてください。 + 特に「ウォークスルーは著者がリーダー、インスペクションはモデレーターがリーダー」は頻繁に出題されます。 +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
タイプ形式度リーダー主目的ドキュメント
インフォーマルレビュー最低—欠陥検出（非公式）不要
ウォークスルー低〜中著者理解・フィードバック収集軽度
テクニカルレビュー中訓練されたモデレーター合意形成・技術的欠陥検出要
インスペクション最高訓練されたモデレーター欠陥検出・プロセス改善必須（メトリクス含む）
+ +

レビュー技法

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
技法特徴適用場面
アドホックレビュー事前準備なし、経験依存簡易・非公式なレビュー
チェックリストベース定型チェックリストに従う繰り返し実施する成果物のレビュー
シナリオベース想定シナリオ・ユースケースから確認要件・設計のレビュー
パースペクティブベース特定ステークホルダーの視点から確認多角的なレビューが必要な複雑な成果物
ロールベース特定の役割（セキュリティ専門家等）の観点セキュリティ・コンプライアンスレビュー
+
+
+ +
+ +
+

Chapter 4: テスト分析・設計

+

+ 試験の27.5%（11問）を占める最重要章です。 + K3（適用）レベルの問題が集中しており、具体的な仕様から実際にテストケースを導出できる + 実践力が問われます。EP・BVA の計算問題は必ず手を動かして練習してください。 +

+ +
+ +
+

同値分割（Equivalence Partitioning: EP）

+

+ 入力値を「同じ動作をする」グループ（同値クラス）に分割し、各グループから代表値を1つだけ選んでテストする技法。 + テストケース数を削減しながら、効率的なカバレッジを達成します。 +

+

具体例: 年齢入力フィールド（有効: 18〜65歳）

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
同値クラス範囲種別代表値の例
EP118未満無効0, 10, 17
EP218〜65有効30, 45
EP365超無効66, 100
+
+ カバレッジ計算:
+ EP カバレッジ = テスト済み同値クラス数 ÷ 全同値クラス数 × 100%
+ 上記の例で EP1 と EP2 のみテスト済み → 2 ÷ 3 = 66.7%（100%達成には EP3 + も必要） +
+
+ +
+

境界値分析（Boundary Value Analysis: BVA）

+

+ 境界付近の値に欠陥が集中するという経験則を活用した技法。 開発者が + <= を < と誤記するような境界の + off-by-one エラーを 効率的に検出します。BVA + は順序付きパーティション（数値・日付・文字列長など）にのみ適用可能です。 +

+
+
+

2値 BVA（2-value BVA）

+
    +
  • 各境界値と、隣接パーティションの最近傍値をテスト
    • +
  • 範囲 18〜65 の場合: 17, 18, 65, 66
    • +
  • 各境界につき2つの値 → 境界数 × 2
    • +
  • 100% カバレッジ = 全境界値を網羅
    • +
+
+
+

3値 BVA（3-value BVA）

+
    +
  • 境界値・外側の隣接値・内側の隣接値をテスト
    • +
  • + 範囲 18〜65 の場合: 17, 18, 19, 64, 65, 66 +
    • +
  • 各境界につき3つの値 → より厳密なカバレッジ
    • +
  • 2値BVAでは検出できない欠陥も検出可能
    • +
+
+
+
+ K3 試験問題の典型: 「範囲 1〜100 + の入力フィールドに対して、3値BVAで必要なテスト値の数はいくつか？」
+ → 下限境界: 0, 1, 2（3値）、上限境界: 99, 100, 101（3値）= 合計 + 6値 +
+
+ +
+

デシジョンテーブルテスト

+

+ 複数の条件の組み合わせによるシステム動作を体系的に網羅します。 n個の条件 + → 最大 2n + のルールが存在（同一アクションのルールは統合可能）。 +

+

具体例: ローン審査（収入 × 信用スコア）

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ルール 1ルール 2ルール 3ルール 4
条件
収入 ≥ 500万円TTFF
信用スコア ≥ 700TFTF
アクション
ローン承認✓———
再審査—✓✓—
否決———✓
+

+ ルール 2 と 3 が同じアクション（再審査）→ 収入条件を「Don't + Care」に統合して最小化可能。 +

+
+ +
+

状態遷移テスト

+

+ システムの状態変化をモデル化してテストケースを設計します。 + ATM・ログイン・注文ライフサイクルなど、状態依存の動作を持つシステムに有効です。 +

+
+ + + + + + + + + + + + + + + + + + + + + +
カバレッジ基準内容
全状態カバレッジすべての状態を少なくとも1回通過
全遷移カバレッジ（0スイッチ）すべての遷移を少なくとも1回通過（最低基準）
nスイッチカバレッジ長さ n+1 の遷移シーケンスをすべてカバー（コスト高）
+
+ +
+

ホワイトボックステスト技法

+

ステートメントテスト vs ブランチテスト

+ 
def check_discount(age, is_member):
+    discount = 0           # Line 1: 常に実行
+    if age > 60:           # Line 2: 判定
+        discount = 10      # Line 3: True ブランチ
+    if is_member:          # Line 4: 判定
+        discount += 5      # Line 5: True ブランチ
+    return discount        # Line 6: 常に実行
+ + + + + + + + + + + + + + + + + + + + +
カバレッジ基準必要なテスト達成条件
100% ステートメントLine 3 と Line 5 の両方を実行age > 60 かつ is_member のケースを含む
100% ブランチ各 if の True / False を両方実行age > 60 の T/F × is_member の T/F = 最低3テスト
+
+ 試験頻出の罠: 100% ブランチカバレッジ ⊃ 100% + ステートメントカバレッジ（包含関係）。 + 逆（ステートメント100%→ブランチ100%）は成立しません。 例: + if (condition) { action(); } で condition が常に True + のケースのみ実行しても ステートメントは100%になるが、False + ブランチはカバーされない。 +
+
+ +
+

探索的テスト

+

+ テストの設計・実行・学習を同時並行で行う動的なアプローチ。 + テスターの知識・経験・好奇心を最大限に活用し、形式的なテストでは見逃しやすい欠陥を発見します。 +

+ + + + + + + + + + + + + + + + + + + + + +
要素説明
テストチャーター + 「[ターゲット] を [リソース] を使って [発見すべき情報] + を探索する」という形式の目的定義文書 +
セッション時間制約のあるテスト実施単位（通常 30〜120 分）
デブリーフィングセッション後の振り返り・所見の共有・次回方針決定
+
+ +
+

ATDD・コラボレーションベース技法（v4.0 新追加）

+

INVEST 原則（ユーザーストーリー品質評価）

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
頭文字意味確認ポイント
Independent独立している他のストーリーに依存せずにデリバリー可能か
Negotiable交渉可能実装の詳細は柔軟に変更できるか
Valuable価値があるステークホルダーに明確なビジネス価値があるか
Estimable見積もり可能チームがサイズを見積もれるか
Small小さい1スプリントで完成できるサイズか
Testableテスト可能明確な受け入れ基準があるか
+ +

Given-When-Then (GWT) 形式

+ 
Given（前提条件）: ユーザーがログイン画面にいる
+When（操作）:      有効なユーザーIDとパスワードを入力し「ログイン」ボタンを押す
+Then（期待結果）:  ダッシュボード画面に遷移し、ユーザー名が表示される
+ +
+
+
+ +
+ +
+

Chapter 5: テスト活動の管理

+ +
+

テスト計画

+

テストピラミッドとテスト四象限

+
+
+

テストピラミッド

+
    +
  • 下段: ユニットテスト（多数・低コスト・高速）
    • +
  • 中段: 統合テスト（中程度）
    • +
  • 上段: E2E / UIテスト（少数・高コスト・低速）
    • +
  • 自動化投資はピラミッドの下段に集中
    • +
+
+
+

テスト推定技法

+
    +
  • メトリクスベース: 過去データから推定
    • +
  • エキスパートベース: デルファイ法・専門家集約
    • +
  • プランニングポーカー: アジャイルチームの合意ベース
    • +
  • WBS: 作業分解構造から積み上げ
    • +
+
+
+ +

テスト四象限（Brian Marick モデル）

+ + + + + + + + + + + + + + + + + + + + +
ビジネスを支援技術を評価
チームを支援（開発ガイド）Q2: 機能テスト・ストーリーテスト（自動 / 手動）Q1: 自動単体・統合テスト
製品を批評（評価）Q3: 探索的テスト・UAT・使用性テストQ4: パフォーマンス・セキュリティ・信頼性テスト
+
+ +
+

リスク管理

+

リスクの分類

+ + + + + + + + + + + + + + + + + + + + +
種別定義例
プロジェクトリスクプロジェクト目標達成を脅かすリスクスケジュール遅延・リソース不足・ベンダー問題
プロダクトリスクソフトウェアの品質特性に関するリスクセキュリティ脆弱性・パフォーマンス問題・データ損失
+
+
+ リスクレベルの公式: リスクレベル = 発生確率 + (Likelihood) × 影響度 (Impact)
+ 高リスク → 広いカバレッジ・早期テスト・頻繁な確認
+ 低リスク → 最小限のテストまたは実施を省略 +
+
+ +
+

テストモニタリング・コントロール・完了

+

主要テストメトリクス

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
カテゴリメトリクス例
進捗テストケース実行率・消化率・残テスト数
欠陥欠陥検出数・欠陥密度・修正率・エスケープ率
カバレッジ要件カバレッジ・コードカバレッジ・リスクカバレッジ
リスク残存リスクレベル・リスク軽減率
コスト予算消化率・テストコスト対欠陥発見数
+ +

テストレポートの種類

+ + + + + + + + + + + + + + + + + + + + +
種別目的主な読者
テスト進捗レポート定期的な状況報告（日次・週次）テストマネージャー・PM
テスト完了レポートフェーズ・プロジェクト完了時の総括全ステークホルダー
+
+ +
+

欠陥管理

+
+
+ 頻出の混同ポイント — 重要度 vs 優先度:
+ 重要度 (Severity): 技術的影響度。Critical / Major / + Minor / Trivial
+ 優先度 (Priority): ビジネス修正緊急度。High / Medium / + Low
+ 例: UIの誤字（重要度 Trivial）でも、トップページならば優先度 High + になる場合がある。 この2つは完全に独立した概念です。 +
+
+
+ +
+ +
+

Chapter 6: テストツール

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ツールカテゴリ例目的
テスト管理Jira, TestRail, Zephyr Scaleテスト計画・実行・追跡
静的テストSonarQube, Checkstyle, ESLint静的解析・コードレビュー支援
テスト実行・カバレッジJUnit, pytest, JaCoCo, Coverage.pyテスト自動実行・カバレッジ計測
パフォーマンスJMeter, Gatling, k6負荷・スループット・応答時間テスト
セキュリティOWASP ZAP, Burp Suite脆弱性スキャン・ペネトレーションテスト
BDD / ATDDCucumber, SpecFlow, FitNesseGWT 形式のテスト実装
CI/CD 統合Jenkins, GitHub Actions, GitLab CIパイプライン組み込み自動テスト
+ +

テスト自動化のメリット vs リスク

+
+
+

メリット

+
    +
  • 回帰テストの繰り返し実行コスト削減
    • +
  • CI/CDパイプラインで夜間も継続実行
    • +
  • 人的ミスの排除・再現性の確保
    • +
  • 大量データを使ったデータ駆動テスト
    • +
  • パフォーマンス・負荷テストの実現
    • +
+
+
+

リスク

+
    +
  • 初期開発・保守コストの過小評価
    • +
  • アプリ変更のたびにスクリプト更新が必要
    • +
  • フォルスポジティブ / ネガティブのリスク
    • +
  • 探索的テストは自動化できない
    • +
  • 「自動化すれば解決する」という誤解
    • +
+
+
+
+ 試験ポイント: + 自動化は手動テストの補完であり、置き換えではありません。 + 特に探索的テスト・ユーザビリティテスト・一度しか実行しないテストは手動が適切です。 +
+
+ +
+ +
+

試験対策・学習戦略

+ +

K-Level 別の出題傾向

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
K-Level要求レベル主な章問題例
K1 覚える定義・用語を再現するCh.1, Ch.3「欠陥クラスタリングの定義は？」
K2 理解する概念を自分の言葉で説明Ch.2, Ch.5, Ch.6 + 「ブランチカバレッジ100%のとき、ステートメントカバレッジは？」 +
K3 適用する具体的な状況に技法を適用Ch.4, Ch.5「以下の仕様から3値BVAテストケースを導出せよ」
+ +

よく混同される用語ペア

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
用語 A用語 B区別の核心
検証 (Verification)妥当性確認 (Validation)仕様準拠 vs ユーザーニーズ充足
欠陥 (Defect)障害 (Failure)コードの誤り vs 実行時の誤動作
重要度 (Severity)優先度 (Priority)技術的影響度 vs ビジネス修正緊急度
ウォークスルーインスペクション著者主導・非公式 vs モデレーター主導・最公式
ステートメントカバレッジブランチカバレッジ命令網羅 vs 分岐網羅（後者が上位）
プロジェクトリスクプロダクトリスクスケジュール等 vs 品質特性
確認テスト回帰テスト修正欠陥の直接確認 vs 変更による副作用確認
テスト計画 (Planning)テストコントロール (Control)計画立案 vs 乖離時の是正措置
+ +

推奨学習ステップ

+
+
+ +
+ +
+

参考文献・公式リソース

+

+ 本ガイドの作成にあたり参照したすべての URL + を掲載しています。試験前には必ず公式サイトで最新情報を確認してください。 +

+ +

公式一次情報（ISTQB）

+
+
+ CTFL v4.0 公式ページ + + https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/ + +
+
+ シラバス v4.0.1 PDF + + https://istqb.org/?sdm_process_download=1&download_id=3345 + +
+
+ 公式用語集 (Glossary) + + https://glossary.istqb.org/en_US/search + +
+
+ サンプル試験 A（問題） + + https://istqb.org/?sdm_process_download=1&download_id=3352 + +
+
+ サンプル試験 A（解答） + + https://istqb.org/?sdm_process_download=1&download_id=3357 + +
+
+ サンプル試験 B（問題） + + https://istqb.org/?sdm_process_download=1&download_id=3359 + +
+
+ サンプル試験 C（解答付き） + + istqb.org / Sample Exam C Answers v1.6 PDF + +
+
+ CTFL v4.0 リリースニュース + + https://istqb.org/istqb-releases-certified-tester-foundation-level-v4-0-ctfl/ + +
+
+ +

補助学習リソース（2026年確認済み）

+
+
+ ISTQB.com 試験ガイド（2026版） + + https://www.istqb.com/ctfl-v4-0/ + +
+
+ ISTQB Guru — チートシート 2026 + + https://www.istqb.guru/istqb-ctfl-cheat-sheet/ + +
+
+ ISTQB Guru — EP/BVA/デシジョンテーブル詳解 + + https://www.istqb.guru/decision-tables-equivalence-partitioning-boundary-value-analysis/ + +
+
+ ISTQB Guru — 認定レベル全体ロードマップ 2026 + + https://www.istqb.guru/istqb-certification-levels-roadmap/ + +
+
+ istqb.com — 認定一覧 2026 + + https://www.istqb.com/certifications/ + +
+
+ Mock Exam Network — 無料模擬試験（1855問） + + https://mockexamnetwork.com/exams/istqb-foundation/ + +
+
+ Medium — BVA 詳解（2026年4月） + + https://medium.com — Boundary Value Analysis BVA (April 2026) + +
+
+ SoftwareTestingHelp — EP/BVA 演習問題 + + https://www.softwaretestinghelp.com / EP-BVA ISTQB Questions (2026) + +
+
+ CTAL-TA v4.0 ガイド（上位認定参考） + + https://www.istqb.com/ctal-ta-v4-0/ + +
+
+ +

次のステップ（上位認定）

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
認定対象者試験
+ CTAL-TA v4.0 + 機能テスト・ブラックボックス専門家45問 / 78点満点 / 65%合格
CTAL-TTAホワイトボックス・非機能テスト専門家45問 / 120分
CTAL-TM v3.0テスト管理・マネジメント職50問 / 90分
CTAL-TAE自動化フレームワーク設計者—
+ CT-AI v2.0 + AIシステムのテスト専門家（2026年4月リリース）—
CT-GenAI v1.1生成AIツールを使ったテスト専門家—
+
+ +
+ 本ガイドは ISTQB CTFL Syllabus v4.0.1（2024年11月公開）および + 2026年6月時点の公式サイト情報に基づいて作成しています。
+ 試験仕様・ダウンロードリンクは変更される場合があります。受験前に必ず + istqb.org + で最新情報を確認してください。
+ 作成日: 2026年6月 | 対応バージョン: ISTQB CTFL Syllabus v4.0.1 +
+
+
+ + + + diff --git a/components/Mermaid.tsx b/components/Mermaid.tsx index 45422029..376ea6b1 100644 --- a/components/Mermaid.tsx +++ b/components/Mermaid.tsx @@ -1,121 +1,125 @@ 'use client'; -import React, { useEffect, useState } from 'react'; +import React, { useEffect, useRef, useState } from 'react'; import mermaid from 'mermaid'; mermaid.initialize({ - startOnLoad: false, - theme: 'dark', // サイトに合わせてダークテーマかベーステーマを使用 - fontFamily: 'var(--font-body)', - fontSize: 16, - securityLevel: 'loose', - htmlLabels: true, + startOnLoad: false, + theme: 'dark', + securityLevel: 'loose', + themeVariables: { + primaryColor: '#1a73e8', + primaryTextColor: '#e8f0fe', + primaryBorderColor: '#1a73e8', + lineColor: '#5f7fb8', + secondaryColor: '#0f9d58', + tertiaryColor: '#0d1a2e', + background: '#060b14', + mainBkg: '#0f2040', + nodeBorder: '#1a73e8', + clusterBkg: '#0d1a2e', + titleColor: '#e8f0fe', + edgeLabelBackground: '#0d1a2e', + fontFamily: "'Noto Sans JP', sans-serif", + fontSize: '13px', + }, + flowchart: { curve: 'basis', padding: 20 }, + sequence: { actorMargin: 60, mirrorActors: true }, }); interface MermaidProps { - chart: string; + chart: string; } /** - * Mermaidダイアグラムのソーステキストを調整されたSVGにレンダリングし、ページに挿入します。 + * Adjusts a rendered Mermaid SVG for layout and sizing. * - * Mermaidが生成したSVGをパースし、検出されたダイアグラムの種類（シーケンス図、左右フローチャート、 - * 上下フローチャート、またはフォールバック）に基づいてインラインサイズとレイアウトを調整し、 - * 得られたSVGをレスポンシブなコンテナ内に表示します。SVGのパースに失敗した場合は生のMermaid出力が - * そのまま使用され、レンダリングエラー時にはエラーメッセージが表示されます。 + * @param chart - The Mermaid diagram source, used to determine the extra bottom padding for some diagram types. + */ +function applySvgFixups(svgEl: SVGSVGElement, chart: string): void { + svgEl.removeAttribute('width'); + svgEl.removeAttribute('height'); + svgEl.style.height = 'auto'; + svgEl.style.overflow = 'visible'; + svgEl.style.display = 'block'; + svgEl.style.margin = '0 auto'; + svgEl.style.marginBottom = '10px'; + + const viewBox = svgEl.getAttribute('viewBox'); + if (!viewBox) return; + const parts = viewBox.split(/\s+/).map(Number); + if (parts.length !== 4 || !parts.every((n) => Number.isFinite(n))) return; + + const [x, y, w, h] = parts as [number, number, number, number]; + const trimmed = chart.trim(); + const isSequenceOrState = + trimmed.startsWith('sequenceDiagram') || trimmed.startsWith('stateDiagram'); + const extraHeight = isSequenceOrState ? 110 : 15; + + // ⚠️ SVG 幅の鉄則: + // viewBox 由来の自然 px 幅 + maxWidth:100% を使う。 + // width:'100%' は viewBox のみで intrinsic サイズを持たない SVG をコンテナ全幅へ + // 伸ばし、小さい図を異常拡大させるため使わない。 + // width:${w}px + maxWidth:100% なら「親より広い図のみ縮小、小さい図は自然サイズ」となる。 + svgEl.style.width = `${w}px`; + svgEl.style.maxWidth = '100%'; + svgEl.setAttribute('viewBox', `${x} ${y} ${w} ${h + extraHeight}`); +} + +/** + * Renders a Mermaid diagram from a chart definition. * - * @param chart - Mermaidダイアグラムのソーステキスト - * @returns レンダリング・調整されたSVGまたはエラーメッセージを含むコンポーネントのJSX要素 + * @param chart - Mermaid diagram source code */ export default function Mermaid({ chart }: MermaidProps) { - const [svgStr, setSvgStr] = useState(''); + const [svgStr, setSvgStr] = useState(''); + const wrapperRef = useRef(null); - useEffect(() => { - let isMounted = true; + // Step 1: mermaid.render() で SVG 文字列を生成して state へ格納 + useEffect(() => { + let isMounted = true; + if (!chart) { + setSvgStr(''); + return; + } - const renderMermaid = async () => { - if (chart) { - try { - // ユニークなIDを付けて同一ページ内の複数図表に対応 - const id = `mermaid-svg-${Date.now()}-${Math.floor(Math.random() * 1000)}`; - const { svg } = await mermaid.render(id, chart); - - // DOMParserを使ってSVGのスタイルをインテリジェントに調整 - const parser = new DOMParser(); - const doc = parser.parseFromString(svg, 'image/svg+xml'); - const parserError = doc.querySelector('parsererror'); - const svgEl = doc.querySelector('svg'); - - if (!parserError && svgEl) { - const isSequence = chart.includes('sequenceDiagram'); - const isFlowchartLR = chart.includes('flowchart LR') || chart.includes('graph LR'); - const isFlowchartTD = chart.includes('flowchart TD') || chart.includes('graph TD') || chart.includes('flowchart TB') || chart.includes('graph TB'); - - if (svgEl.style) { - svgEl.style.height = 'auto'; - svgEl.style.display = 'block'; - svgEl.style.margin = '0 auto'; - - if (isSequence) { - svgEl.style.width = '100%'; - svgEl.style.maxWidth = '650px'; - } else if (isFlowchartLR) { - const originalWidth = svgEl.getAttribute('width'); - if (originalWidth && !originalWidth.includes('%')) { - const widthVal = parseFloat(originalWidth); - if (widthVal > 720) { - svgEl.style.minWidth = originalWidth; - svgEl.style.width = originalWidth; - } else { - svgEl.style.width = '100%'; - svgEl.style.maxWidth = originalWidth; - } - } else { - svgEl.style.maxWidth = '100%'; + const renderMermaid = async () => { + try { + // Web フォント（Noto Sans JP 等）の読み込み完了を待ってから描画する。 + // 未読込のフォールバックフォントで mermaid.render() するとノード幅が + // 誤計算され、確定後に文字がはみ出す/見切れるため。 + if (typeof document !== 'undefined' && 'fonts' in document) { + await document.fonts.ready; } - } else if (isFlowchartTD) { - svgEl.style.width = '100%'; - svgEl.style.maxWidth = '480px'; - } else { - svgEl.style.maxWidth = '100%'; - } - } - - // 図表は開発者が直書きした静的定数のみ（外部入力なし）のため - // 外側サニタイズは不要。サイズ調整済み SVG をそのまま描画する。 - // 外側 DOMPurify(svg プロファイル)は htmlLabel の
や