コメントの重要性

「UT.Browser」は単体テスト項目表をソースのコメントから一括出力します。
なぜ、コメントから出力することが重要なのでしょうか。

ドキュメント管理の工数の大きさと間に合わない対応

システム開発は、基本設計→詳細設計→プログラミング→単体テスト→結合テスト→総合テストと工程が進みます。 設計、開発の工程では、具現化されるシステムの内容についてレビューが行われ、ユーザーの承認が必要な場合はその承認を得て次の工程に進んで行きます。

工程が順番に進んでいるときはよいのですが、途中で仕様の変更が入った場合、変更の内容は、1番はじめの工程まで遡って、修正を行います。

プログラミングの途中で発見された仕様のバグは、基本設計書の修正し、レビュー、ユーザー承認。詳細設計書の修正し、レビュー。プログラムの修正と手順を追って行っていきます。

テスト工程で仕様のバグが発見されたとしても同様です。基本設計の修正からはじまって修正を行います。
基本設計、詳細設計は、一つの修正に関して重複する箇所も多く(詳細設計書が基本設計をより具現化であるため書かれているレベルが違いますが、内容自体は同じシステムに対しての内容です)

設計工程が完了した後に見つかるバグについては、プログラムの修正箇所、内容が決定している上で、重複される記述が多い各設計書を漏れなく修正していくことが必要になります。

しかし、現実問題としてはどうでしょうか?

プログラムの修正、スケジュール納期、設計書の修正を並べて、優先順位を考えた際、設計書のメンテナンスが後回しになってしまったり、手順が漏れてしまうなど、この状況で起こることを想像することは、難しくないと思います。

開発する際の膨大な設計書は、ドキュメントを最新に保つためには、時間的にも、人員的にも多大な工数が必要です。

また、ドキュメントは最新の状況を表したものでなければ、意味がありません。

システムのリプレイスを受注した際、最新のソースは頂けますが、設計書などのドキュメントはありませんというお話が少なくありません。

設計書がなくシステムを作れるわけがないので、ドキュメント管理の難しさを物語っているのではないでしょうか。


システムの最新のドキュメントはどこにあるか

プログラマやSEの方々は、プログラム自体を直接に解読することができるので、ソースから直接解析することが求められます。

そして、その時のヒントとなるのがソースのコメントです。

処理の内容だけでなく、何を目的としてそのプログラムが書かれたのまでが最新のソースに対して記述されています。

コメントが正確に漏れなく記述されているということは、開発の精度の高さの裏付けになるだけでなく、システムのメンテナンスの効率は大幅に上がります。

プログラマやSEの方々はコメントの正確な記述の重要性を理解いただけると思います。

コメントの漏れや、正確な記述についてチェックするのは、ソースレビューで行われます。

「UT.Browser」は単体テスト項目を出力するだけか?

「UT.Browser」は、IF文等の条件分岐、LOOP文等の反復処理、例外処理を解析してテスト項目を作成します。

IF文、LOOP文については、そのブロックで行なわれるコメントの有無、場合分け条件の内容の有無を確認することができます。 入力がない項目は、未出力項目としてその件数と、その行数を検索することができます。

また、テスト項目表をエクセル出力する際、項目を整形した形で出力できます。
整形して出力することで、コメントの内容の確認が効率的にできます。


最終更新日:2012年09月05日