静的テストでは、動的テストと異なり、テスト対象のソフトウェアを実行する必要はない。コード、処理仕様、システムアーキテクチャー仕様、または他の作業成果物は、人手による確認（例えば、レビュー）によって、またはツール（例えば、静的解析）の力を借りて評価する。テスト目的は、品質向上、欠陥検出、可読性、完全性、正確性、試験性、一貫性などの特性の評価を含む。静的テストは、検証、および妥当性確認の両方に適用することができる。

テスト担当者、ビジネス側の代表者、開発者は、実例マッピングに一緒に取り組み、ユーザーストーリーを共同で書き、バックログリファインメントセッションにおいて協力し、ユーザーストーリーと関連作業成果物が、定義された基準、例えば「準備完了（Ready）の定義」（5.1.3 項参照）を満たすことを確認する。レビューの技法は、ユーザーストーリーが完全で理解しやすく、テスト可能な受け入れ基準を含むことを確認するために適用できる。テスト担当者は、適切な質問をすることで、提案されたユーザーストーリーを探索し、課題を挙げて、改善を支援する。

静的解析は、テストケースが不要であり、典型的にはツール（第 6 章参照）を使用することにより、動的テストの前に問題を識別できるため、より少ない労力で済む場合が多い。静的解析は、CI フレームワークへ組み込むことが多い（2.1.4 項参照）。静的解析は、主にコードの特定の欠陥を検出するために使用するが、保守性やセキュリティを評価するためにも使用する。スペルチェッカーや可読性を上げるツールも、静的解析ツールの一例である。

1.静的テストで確認可能な作業成果物

ほとんどの作業成果物は静的テストを使用して確認できる。例えば、要件仕様書、ソースコード、テスト計画書、テストケース、プロダクトバックログアイテム、テストチャーター、プロジェクトドキュメント、契約書、モデルが含まれる。

読んで理解できるあらゆる作業成果物はレビューの対象になりうる。しかし、静的解析では、作業成果物をチェックするための構造（例えば、モデル、コード、および正式な構文を持つテキスト）が必要である。

静的テストに適さない作業成果物は、人間による解釈が困難なもの、ツールで解析してはいけないもの（例えば法規制がある第三者の実行可能コード）を含む。

2.静的テストの価値

静的テストは SDLC の初期段階で欠陥を検出することができるため、早期テストの原則を満たす（1.3 節参照）。また、動的テストでは検出できない欠陥（例えば、到達できないコード、狙い通りに実装されていないデザインパターン、実行不可能な作業成果物に内在する欠陥）を検出することもできる。

静的テストは、作業成果物の品質を評価し、作業成果物に対する信頼性を高めることができる。文書化した要件を検証することで、ステークホルダーは、要件が実際のニーズを表していることを確認することもできる。静的テストは SDLC の早期に実施できるので、ステークホルダーの間で共通の理解を得ることができる。また、ステークホルダー間のコミュニケーションも改善できる。このため、静的テストには、さまざまなステークホルダーが参加することを推奨する。

レビューを実装するにはコストがかかるが、プロジェクトの後半で欠陥を修正するために費やす時間と労力が少なくて済むため、通常、プロジェクト全体のコストはレビューを実施しない場合よりもはるかに安価となる。

静的解析は動的テストよりも効率的にコードの欠陥を検出することができ、通常、コードの欠陥の減少と開発工数の削減の両方を実現することができる。

3.静的テストと動的テストの違い

静的テストと動的テストの実践は、互いに補完し合っている。両者の目的は、作業成果物の欠陥検出を支援する（1.1.1 項参照）といったように似てはいるが、以下のような違いもある：

・静的テストと（故障の分析を含む）動的テストは、どちらも欠陥の発見につながるが、欠陥の種類によっては、静的テスト、および動的テストのどちらかでしか発見できない。

・静的テストでは、欠陥を直接発見するが、動的テストでは故障を引き起こし、その後の分析によって関連する欠陥を特定する。

・静的テストでは、動的テストではほとんど実行されない、あるいは到達しにくいコード内のパスに潜む欠陥を、より簡単に検出することがある。

・静的テストは実行不可能な作業成果物に適用でき

1.早期かつ頻繁なステークホルダーからのフィードバックの利点

早期かつ頻繁なフィードバックは、潜在的な品質問題を早期に伝えることができる。SDLC の中でステークホルダーの関与が少ない場合、開発中のプロダクトは、ステークホルダーの当初、または現在のビジョンを満たさないかもしれない。ステークホルダーが望むものを提供できない場合、コストのかかる手直し、納期の遅れ、責任のなすり合いが発生し、さらにはプロジェクトの完全な失敗につながる可能性がある。

SDLC を通じてステークホルダーのフィードバックを頻繁に行うことで、要件に関する誤解を防ぎ、要件の変更をより早く理解し実装することができる。これは、開発チームが自分たちで構築しているものに対する理解を深めるのに役立つ。これにより、開発チームは、ステークホルダーに最大の価値を与え、かつ識別したリスクに最もよい影響を与えるフィーチャーに焦点を当てることができる。

2.作業成果物のレビュープロセス

ISO/IEC 20246 標準は、特定の状況に応じて具体的なレビュープロセスを調整できる、構造化されているが柔軟な枠組みを提供する汎用的なレビュープロセスを定義している。必要となるレビューがより形式的なものである場合、さまざまな活動に対して標準に記載がある、より多くのタスクが必要となる。

多くの作業成果物は、そのサイズが大きすぎるため、1 回のレビューではカバーしきれない。作業成果物全体のレビューを完了させるために、レビュープロセスを 2、3 回行うことがある。
レビュープロセスの活動は以下がある。

・計画 計画フェーズでは、目的、レビュー対象となる作業成果物、評価対象の品質特性、重点を置く領域、終了基準、標準などの裏付け情報、レビューの工数と時間枠からなるレビューの範囲を定義する。

・レビューの立ち上げ レビューの立ち上げでは、レビュー開始までに関係者や物事が準備できたことの明確化がゴールとなる。これには、すべての参加者がレビュー対象の作業成果物にアクセスできること、自分の役割と責務を理解していること、レビューの実行に必要なすべてのものを受け取っていることを確認することが含まれる。

・個々人のレビュー すべてのレビューアは、レビュー対象の作業成果物の品質を精査し、1 つ以上のレビュー技法（チェックリストベースドレビュー、シナリオベースドレビューなど）を適用して、不正、推奨、および質問を識別するために個人のレビューを実施する。ISO/IEC20246 標準では、さまざまなレビュー技法についてより詳しく説明している。レビューアは、特定されたすべての不正、推奨、および質問を記録する。

・共有と分析 レビュー中に識別した不正が必ずしも欠陥であるとは限らないため、これらすべての不正を分析して議論する必要がある。すべての不正について、そのステータス、オーナー、必要なアクションを決めるべきである。これは通常、レビューミーティングで行われ、参加者はレビューした作業成果物の品質レベルと必要なフォローアップのアクションも決める。
アクションを完了するには、フォローアップのレビューが必要になる場合がある。

・修正と報告 是正処置をフォローアップできるように、すべての欠陥に対して欠陥レポートを作成すべきである。終了基準に達すれば、作業成果物を受け入れることができる。レビュー結果はレポートする。

3.レビューでの役割と責務

レビューにはさまざまなステークホルダーが関与しており、彼らはいくつかの役割を担っている可能性がある。主な役割とその責任は以下の通りである：

・マネージャー-何をレビューするかを決定し、レビューのための人員や時間などのリソースを提供する

・作成者-レビュー対象の作業成果物を作成し、修正する

・モデレーター（ファシリテーターとも呼ばれる）-調整、時間のマネジメント、誰もが自由に発言できる安全なレビュー環境など、レビューミーティングを効果的に運営する

・書記（記録係とも呼ばれる）-レビューアからの不正を取りまとめ、決定事項やレビューミーティング中に発見された新たな不正などのレビュー情報を記録する

・レビューア-レビューを行う。レビューアは、プロジェクトに携わっている人、特定分野の専門家、その他のステークホルダーである場合がある

・レビューリーダー-誰が参加するか、いつ、どこでレビューが行われるかを決