ISTQB Foundation Level 4.0 チュートリアル第24回では、
「静的テスト（Static Testing）」と「動的テスト（Dynamic Testing）」の違いについて学びます。
この2つはどちらも欠陥（Defects）を発見するためのテスト手法ですが、
アプローチの方法と検出できる欠陥の種類が大きく異なります。
この記事では、両者の特徴・違い・見つけやすい欠陥の例を、初心者向けに整理して解説します。
🔍 静的テストと動的テストの基本的な違い
|
比較項目 |
静的テスト（Static Testing） |
動的テスト（Dynamic Testing） |
|---|---|---|
|
目的 |
ドキュメントやソースコードを「読む」ことで欠陥を発見する |
実際に「実行」して挙動を確認する |
|
対象 |
要件定義書、設計書、ソースコード、ユーザーマニュアルなど |
実行可能なソフトウェア（プログラム、アプリ） |
|
実施タイミング |
コーディング前・実装初期 |
ソフトウェア完成後、実行可能になってから |
|
主な手法 |
レビュー、ウォークスルー、静的解析 |
単体テスト、結合テスト、システムテストなど |
|
メリット |
早期に欠陥を発見でき、修正コストが低い |
実際の動作を確認できる |
|
欠点 |
実行時のエラーは検出できない |
実行しないと欠陥が見つからないためコストが高い |
💡 静的テストの特徴とメリット
静的テストは、ソフトウェアを実行せずに行うテストです。
レビューや静的解析ツールを活用して、ドキュメントやソースコードの品質をチェックします。
主なメリットは以下の通りです。
-
早期に欠陥を検出できる：開発初期の段階で問題を見つけることで、修正コストを大幅に削減できる。
-
ドキュメント上の不整合や矛盾を発見できる：実装前に設計や要件の問題を防ぐ。
-
実行不要なのでリスクが少ない：コードを動かさずにレビューできる。
例：
「要件書に曖昧な表現がある」「変数が未定義」「コードの複雑度が高すぎる」などは、静的テストで発見可能です。
⚙️ 動的テストの特徴とメリット
一方、動的テストは実際にソフトウェアを動かしてテストする方法です。
主に機能やUIの動作確認、パフォーマンス、セキュリティなどを評価します。
特徴としては：
-
ユーザー視点の不具合発見に有効（操作時のエラーや挙動不良など）
-
非機能要件（性能・セキュリティ）の検証が可能
-
実行結果から欠陥を特定する（失敗＝欠陥の存在を示す）
ただし、欠陥の原因を突き止めるにはRoot Cause Analysis（根本原因分析）が必要となるため、
静的テストよりも発見～修正までに時間がかかるというデメリットもあります。
🧭 静的テストと動的テストの関係性
両者は「どちらか一方だけを使う」ものではありません。
静的テストと動的テストは補完関係にあり、
プロジェクト全体の品質を向上させるためには、両方を適切に組み合わせることが重要です。
-
静的テスト → 設計段階での欠陥を早期に発見
-
動的テスト → 実行段階での不具合を検出
この2つをバランスよく実施することで、テストコストの最適化と品質の向上が実現します。
🧩 静的テストで見つかりやすい欠陥の例
静的テストでは、主に次のような欠陥を効率的に見つけることができます。
1️⃣ 要件関連の欠陥
-
曖昧な表現、不整合、重複、矛盾、抜け漏れ
2️⃣ 設計関連の欠陥
-
非効率なデータベース設計
-
不適切なモジュール構造や高い結合度（coupling）
3️⃣ コーディング関連の欠陥
-
未定義または未宣言の変数
-
到達不能コード、重複コード
-
複雑すぎるロジック構造
4️⃣ コーディング規約違反
-
命名規則の不統一、コーディングスタイルの逸脱
5️⃣ インターフェース関連
-
APIパラメータの型・順序の不一致
-
呼び出し先の仕様とのミスマッチ
6️⃣ セキュリティ関連
-
バッファオーバーフローなどの脆弱性
7️⃣ テストベースやトレーサビリティの欠陥
-
要件とテストケースのリンクが欠落している
-
受け入れ基準を満たしていないテストケースの存在
🧠 まとめ：静的と動的、どちらも欠かせない！
静的テストと動的テストは、まったく異なるアプローチを取りますが、
どちらもソフトウェア品質向上に不可欠なテスト手法です。
-
静的テスト → 「読む」ことで欠陥を早期発見
-
動的テスト → 「実行」して動作を確認
プロジェクトの初期段階から両方を組み合わせることで、
欠陥の早期発見・修正コストの削減・品質向上という好循環を生み出すことができます。
コメント