テスト計画の攻略法

テスト計画の攻略法

　テスト計画書のインスペクションにおいては、インスペクションをどのように行うかよりも「テスト計画書をみんなでインスペクションすることそのもの」が大きな効果をもたらします。

　設計書からどのようにしてテストケースが導出されるかという追跡性のインスペクション、選択した技法や網羅性が確保されているか、十分に単純な作業に落とせているか、チェック観点が統一されているか、といった個々の技術要素・技術的な観点はもちろん重要なのです。

　しかし、最も注意すべきインスペクションの最優先の観点は、「テスト計画書は開発関係者全員でインスペクションしたか」に尽きます。基本的に開発者としての資質の差よりもテスト技術やテストへの知識・経験はばらつきがあるといわれており、個々の担当者にテストの各作業を丸投げ・お任せしておくと、テストフェーズの終盤に何もテストされていないことが確認されても文句は言えません。

　言い換えれば、テストフェーズ開始の時点で全員でテストの方針、技法、標準プロセスの共有を通じて均質化を図らなければ、テストの妥当性・十分性を議論するまで至らないでしょう。

　全員でテスト計画書上の抜け漏れ・矛盾・無理・無駄を検出し、全員納得した上でテストフェーズを乗り越えるためには、わいわいとみんなでインスペクションが一番のオススメです。

同一工程内でのばらつき

　ここまでに様々なコツを述べましたが、総じてどのフェーズのインスペクションでも「同一フェーズ内部でばらつき」を見るようにしましょう。実に様々なことがわかります。

　例えば、時系列変化を追いかけることなどは、一般的なインスペクションでは行われない有効な手段です。要求定義書や設計書などが典型的な例ですが、一般的に設計は段階的詳細化を経るため、文章の記述粒度が粗い状態から詳細な記述へ変化していきます。これに伴い文書量（すなわち仕様書のページ数や行数）が増えていくことを意味します。

　ところが、時間がなくなったりプレッシャーがきつい環境下で作成された仕様書は、前フェーズもしくはフェーズ初期に作られた仕様書より、文字数・単語数・行数が少なくなったりします。このことは「時間がないので略記・メモ書き程度」となる開発者の心理を表しており、仕様の抜け漏れや実装不可能な仕様を作り出してしまう原因になります。

　仕様書を書くときの開発者心理として「理解しているものから書く」「主要な業務から書く」のが一般的ですので、分かりにくい例外系の処理は、仕様書バインダーの後ろ、末尾に記載されています。換言すれば、最初の1件面の機能仕様書と、最後の機能仕様書とが同じ詳細度／粒度で記載されているプロジェクトは、まず時間ギリギリで粗くなったりしていない、と判断してもよいでしょう（図3参照）。これも一種のサンプリングテクニックですね。

　次回は、より深いインスペクション専門家の洞察ポイントをご紹介します。前回お話した「エンピリカル」についても触れながら、簡単な測定とインスペクション速度を向上させるテクニックについて考えてみたいと思います。