（※当記事は、2024年12月10日時点での最新版(2023V4.0.J02)のシラバスを元に作成しています。）
この記事では、JSQTB (Japan Software Testing Qualifications Board) の Foundation Level のシラバスを分かりやすくかみ砕いて解説していきます。
6記事に分けて、全ての章を解説していきますので、シラバスのなかの要点を押さえたい、ここが分からないという際に参考にしてください。
この記事では、【JSTQB】3章 静的テスト を解説します。
その他の章の解説は下記よりご参照ください。
| 各章 | リンク |
|---|---|
| 1章 | 【JSTQB】1章 テストの基礎｜解説 |
| 2章 | 【JSTQB】2章 ソフトウェア開発ライフサイクル全体を通してのテスト｜解説 |
| 3章 | 【JSTQB】3章 静的テスト｜解説 |
| 4章 | 【JSTQB】4章 テスト分析と設計｜解説 |
| 5章 | 【JSTQB】5章 テスト活動のマネジメント｜解説 |
| 6章 | 【JSTQB】6章 テストツール｜解説 |
3 静的テスト
3.1 静的テストの基本
静的テストとは…
ソフトウェアを実行せずに、コードや仕様、アーキテクチャなどの作業成果物をレビューやツール（静的解析）を用いて評価する方法。
目的は品質向上や特性の評価（可読性、完全性、一貫性など）で、検証と妥当性確認の両方に利用される。
特徴
静的テストの特徴は下記の2点です。
- レビュー：テスト担当者や開発者が協力して、作業成果物が基準を満たすか確認する
- 静的解析：ツールを使用し、動的テスト前に欠陥を発見する
（保守性やセキュリティの評価するために用いることが多い）
確認可能な作業成果物
静的テストの作業成果物としては、要件仕様書、ソースコード、テスト計画書、プロダクトバックログ、テストチャーター、プロジェクトドキュメント、契約書など、構造化されたものが対象となります。
※ツールで解析してはいけないものや非構造的なものや人間が解釈困難なものは対象外となる点に注意しましょう！
3.1.2 静的テストの価値
静的テストはコードの実行を伴わず、ドキュメントを含むため、SDLCの各段階の初期に実行できる点が重要です。これにより早期テストの原則を満たします。
他にも多くのメリットをもたらすため押さえておきましょう。
メリット
- 早期欠陥検出：動的テスト前に欠陥を発見し、修正コストを削減。
- 動的テストでは検出困難な欠陥の発見：到達不能コードや非効率な設計など。
- 作業成果物の品質向上：ステークホルダー間の共通理解を促進。
- コスト削減：プロジェクト後半の修正コストを削減。
- 効率性：コードの欠陥を動的テストより効率的に検出。
3.1.3 静的テストと動的テストの違い
静的テストと動的テストの違いは下記表の通りです。
| 項目 | 静的テスト | 動的テスト |
|---|---|---|
| 作業成果物 | 実行不可能なものに適用可能 | 実行可能なものに適用可能 |
| 検出する欠陥の種類 | 要件の曖昧さ、一貫性の欠如、到達不能コードなど | 実行時の故障による欠陥 |
| 測定する品質特性 | 保守性など、コードの実行に依存しない特性 | 性能効率性など、コードの実行に依存する特性 |
| コスト効率 | 早期に安価に欠陥を検出可能 | 修正に手間とコストがかかる場合が多い |
※コードの実行をしないテストが静的テストであると覚えると覚えやすいです。
検出可能な欠陥
- 要件の曖昧さや欠落
- 設計の非効率やモジュール化不足
- コーディング標準の逸脱
- セキュリティ脆弱性（例：バッファオーバーフロー）
- 不十分なテストベースのカバレッジ
静的テストは動的テストを補完し、プロジェクト全体の効率を高める重要な手法である。
3.2 フィードバックとレビュープロセスの要約
3.2.1 早期かつ頻繁なステークホルダーからのフィードバックの利点
- 早期フィードバックにより品質問題を早期発見可能。
- ステークホルダーの関与不足は、プロダクトが期待に応えられない原因となり、コスト増やプロジェクト失敗のリスクを伴う。
- 頻繁なフィードバックで要件の誤解を防ぎ、変更対応が迅速化。価値あるフィーチャーに集中できる。
3.2.2 作業成果物のレビュープロセス
多くの作業成果物は、サイズが大きすぎるため1回のレビューではカバーしきれません。
そのため、大規模な成果物では複数回のレビューが必要になる場合がある点を押さえておきましょう。
レビュープロセスの活動
- 計画：目的、範囲、終了基準、リソースを定義。
- 立ち上げ：必要な準備が整ったことを確認。
- 個々人のレビュー：品質を精査し、不正や推奨を記録。
- 共有と分析：不正を分析し、対応アクションを決定。
- 修正と報告：欠陥レポートを作成し、終了基準に達すれば成果物を受け入れる。
3.2.3 レビューでの役割と責務
- マネージャー：レビュー対象やリソースを決定。
- 作成者：成果物の作成・修正。
- モデレーター：レビューを円滑に進行。
- 書記：記録を担当。
- レビューア：成果物をレビュー。
- レビューリーダー：全体的な責任を負う。
プロジェクトメンバーには限りがあるため兼任する場面が多くみられるが、必要に応じてさらに役割を細分化できます。
3.2.4 レビュー種別
| 非形式的レビュー | 簡易的で、不正検出が主目的 |
| ウォークスルー | 作成者主導で、合意形成や信頼構築が目的 |
| テクニカルレビュー | 技術的な問題を議論し、品質向上や合意形成を目指す |
| インスペクション | 最も形式的で、不正検出とプロセス改善が目的 |
3.2.5 レビューの成功要因
レビューを成功させる要因は数多くありますが、今回はシラバスに挙げられている具体例をご紹介します。
- 明確な目的と終了基準の設定。
- 適切なレビュー種別の選択。
- 集中力維持のため小規模に分割して実施。
- 十分な準備時間を確保。
- フィードバック提供で学習と改善を促進。
- マネジメントの支援とトレーニングの提供。
- 組織文化としてレビューを定着させる。
他の章を確認する
| 各章 | リンク |
|---|---|
| 1章 | 【JSTQB】1章 テストの基礎｜解説 |
| 2章 | 【JSTQB】2章 ソフトウェア開発ライフサイクル全体を通してのテスト｜解説 |
| 3章 | 【JSTQB】3章 静的テスト｜解説 |
| 4章 | 【JSTQB】4章 テスト分析と設計｜解説 |
| 5章 | 【JSTQB】5章 テスト活動のマネジメント｜解説 |
| 6章 | 【JSTQB】6章 テストツール｜解説 |
