品質

日本システム開発株式会社から品質に関するコラムをお届けします。

品質向上サービスを提供し続けて十数年の弊社から、品質を高めるための様々な情報を発信します。

日本システム開発の技術、
覗いてみませんか。

品質コラム第4回「単体テストにおける「詳細設計書」はどうあるべきか」

2014.11.05

ここでは、単体テストにおける「詳細設計書はどうあるべきか」をテーマに話し合った内容を数回にわたって連載していきます。

「詳細設計書」を取り巻く３種類の人

「詳細設計書」と一言で言っても関わる人は様々です。

関わる人をグループ分けすると「詳細設計書」を取り巻く人は、次の３種類になります。

詳細設計書を書かせる人
詳細設計書を書く人
詳細設計書を見る人(コーディング者/単体テスト実施者)

本連載では、「詳細設計書を見る人(コーディング者/単体テスト実施者)」の視点で検討していきます。

「詳細設計書を見る人」にとっての「詳細設計書」の存在理由

「詳細設計書を見る人」にとっての詳細設計書の存在理由は、次の２つです。

コーディングをするため
単体テスト項目を作成するため

「詳細設計書を見る人」にとっての「良い詳細設計」とは

「詳細設計を見る人」にとって、コーディングするときや単体テストを設計するときに質問をしなくていいものが「良い詳細設計」といえます。

きちんと書かれていなければ「詳細設計書を見る人」は次の成果物を作れるわけがありません。

しかし、実際には後工程の人が質問することが前提で設計書が作られていることが多いのです。

「詳細設計書」の単体テスト工程での必要性

オーバーフロー/アンダーフローなど危険コードのチェックはソースコードで問題ないか判断できます。

しかし、コーディングされている「値」や「処理」が正しいかを判断するためには、正しいと裏づける根拠が必要です。

その根拠が「詳細設計書」になります。

例えば、ソースコードに次の分岐があった場合を見てみましょう。

if( 3 == a ){

処理１

}

「3」という値は正しい値なのでしょうか。

ソースを見ただけではこの値が正しいか判断できません。

詳細設計書に「aが3の場合に処理１を行う」と記載があれば、この値は正しいといえます。

「詳細設計書」でよくあること

「詳細設計書」の定義は、会社によって様々なのが現実です。

どのレベルまで書いてあるか違うことがよくあります。

A社の例

詳細設計者は関数のインターフェイスの決定までを行い、他はコーディング者に任せている。

または、インターフェイスもコーディング者に任せる。

この場合の詳細設計書は実に簡易なものになるでしょう。

B社の例

詳細設計者が関数のインターフェイスから処理の詳細まで細かく決め、コーディング者はプログラムに落とすだけ。

この場合の詳細設計書は密なものになるでしょう。

「コーディングするため」には問題なくても「テスト項目を作成するため」の詳細設計書としてはこの違いは重要です。

今日の結論

単体テストでテスト項目を作成するために「詳細設計書」は必要
形式ではなく情報量が重要。コーディング者とテスト実施者が質問をするようではダメ
まずは「詳細設計書を見る人」の視点で検討していく
詳細設計書の存在理由を満たす内容を明確にしていきたい

次回はサンプルとなる詳細設計書を用意して具体的な検討をしていきます。

品質コラム 第4回「単体テストにおける「詳細設計書」はどうあるべきか」