テストをイメージできない設計は、必ず品質が低下する

テストをイメージできない設計または設計書は非常に危険です。

現在、世の中のたいていの開発方法論はＶ字モデル（Ｖモデル）をベースにした開発モデルを利用して設計されています。これは、ウォーターフォールのように設計→製造→試験の工程の流れを遡ることなく進み続ける考え方もＶ字モデルをベースにした考え方の１つですが、ウォーターフォールであれ、アジャイルであれ、最も重要なのはプロセス指向において

　各プロセス間／各成果物間のトレーサビリティが保証される

ことにあります。

自らが作り上げたプログラム、ソフトウェアが正しく作られていること、正しく動作することを確認するために、ＩＴの現場では必ず「テスト」と言う工程を含みます。と言うか、どのようなモノであれ、作成したものを確認、テストするのは、「製造」「作成」する業界では必須です。

この時、「テスト」では、いったい何を確認するのでしょう。

　・動くこと
　・正しく動くこと
　・想定通りに動くこと

どれも正しいと思います。ですが、その抽象的な表現をより具体的に、より網羅的に確認できなければ、プロダクトの品質を保証することはできません。

たとえば、「動く」とは具体的にどのような状況を指すのでしょうか。「スイッチを押したら起動した」ら、すべてに対して「動く」が保証されるのでしょうか。

たとえば「正しく」と言うのは、どのような条件下で動くことを指すのでしょうか。「正しくない」使い方をした時の動作は確認しなくていいのでしょうか。

このような、様々なシチュエーションに従って、どのように動くかを定義したものが、仕様書であり、設計書です。ですから、テストの観点やチェック事項は、必ず「仕様書」「設計書」をベースにして作成されていくことになります。