SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

テンプレートから学ぶ 受注する開発者のためのテスト仕様書

単体テスト計画書 (1)
― 表紙・目次・第1部・第1章

開発者のためのテスト仕様書テンプレート(2)


1.5. 第1章

 第1章では下記を書きます。

  • 目的
  • 内容
  • 開始基準
  • 完了基準

1.5.A. 「目的」

テンプレート6: 「1.1 目的」
テンプレート6: 「1.1 目的」
「『最終』成果物」

 前回「図1 ソフトウェア開発プロジェクトと品質・生産性・納期」を図示しました(図2として再掲しました)。図2で、発注者が求めるのは「要件に応じた品質の、妥当なコストで、納期に間に合う成果物」でした。ここで「成果物」とは、開発者がプロジェクトには必要かもしれないが納品対象ではないさまざまなプログラムを除いたものです。それを最終成果物と呼びます。これがテスト対象となります。

図2: 「最終」成果物
図2: 「最終」成果物
『注意深い』目的

 テンプレート6は図2に照らして正しいのですが、開発者からするとちょっとリスクを含んでいます。最終成果物の範囲が広過ぎるかもしれないのです。ここは大事なところなので、ちょっと詳しく見てみましょう。

図3: 「最終成果物」=「開発した成果物」
図3: 「最終成果物」=「開発した成果物」

 図3では、発注者に納品する「最終成果物」は開発者が開発した成果物と同じです。この場合、テンプレート6の文言で特に問題はありません。

図4: 「最終成果物」not=「開発した成果物」
図4: 「最終成果物」not=「開発した成果物」

 図4では受注者が自ら開発した成果物もありますが、他社製品を調達して統合し、それを最終成果物として納品することが描かれています。この場合、発注者は最終成果物に対してすべてテストして欲しいので、テンプレート6の文言は当然です。一方、開発者は単体テストでは今回開発した部分のテストだけを行いたいのです(単体テスト局面では、他社製品の単体テストを行いたくはないですね)。従って、注意深い「目的」は図3のようになるでしょう。

図3: 注意深い「1.1 目的」
図3: 注意深い「1.1 目的」
注記

 このシリーズで後述しますが、最終成果物全体のテストは必要です。今回は単体テストがテーマですので、単体テストでは行わないということを言っているに過ぎません。念のため。

最小構成要素

 これは次に述べる「内容」のことです。

1.5.B. 「内容」

テンプレート7: 「1.2 内容」
テンプレート7: 「1.2 内容」

 「ホワイトボックステスト」は第2章、「ブラックボックステスト」は第3章のテーマです。そこでそれぞれ詳しく述べます。

 「内容」の各項目は最終成果物、あるいは、今回開発した成果物の構成要素です。つまり、成果物として発注側に渡すもの、もしくは、今回開発したものはテストする「内容」です。

テストすべき内容
項目 説明
コンパイルされる通常のプログラム(C、VB、Java、など) プログラムそのものです。テストする項目です。ホワイトボックステストではプログラムの内部の情報を使いますから、ソースコードを使います。また、このシリーズのどこかで、「プログラムを目視してテストする静的テスト」について触れるでしょうが、その静的テストでもソースコードを使います。一方、そもそもテストではプログラムを実行して入出力の関係を調べるので、プログラムのロード・モジュールも使います。
フレームワークで利用される個々の構成要素(JSP、class、など) 例えば、Tomcatなど、最近の開発では実行環境としてさまざまなフレームワークを使うようになりました。フレームワークを使った開発では、JSPやclassもテスト対象です。
設定パラメータ フレームワークに限らず、設定パラメータは多いものです。ハードウェアやOS、通信ソフトウェア、ミドルウェアなどの設定パラメータや、業務固有に使っている制御テーブル上のパラメータなど、テスト対象です。
データベース データベース・システムを使うにはさまざまな定義が必要です。データ定義はテスト対象です。
ファイル データベース以外のファイルもテスト対象です。作業ファイル、中間ファイルもテスト対象です。
画面 画面はスクリーン上に出ている画面というよりは画面定義、画面遷移、など、極めて多くの情報を持っています。それらがテスト対象です。
帳票 最終的にプリンタで印刷される帳票に限らず、印刷ボタンで印刷可能なものは帳票としてテストします。
メッセージ 多くのシステムは他システムと通信しながら稼働するものです。他システムとのメッセージ、自システム内でのメッセージはテスト対象です。
その他、プログラムに類するもの IT業界は日々進化していくので、テスト対象を網羅し尽くすことは難しいものです。ということで、「その他」の項目が入っています。

1.5.C. 「開始基準」

テンプレート8: 「1.3 開始基準」
テンプレート8: 「1.3 開始基準」

 「単体テスト計画書」は最後の設計局面(「詳細設計」と言ったり「内部設計」と言ったりします)で書きます。ですから単体テストを実施するには最後の設計局面(ここでは「詳細設計」という言葉を使っています)が完了していることが必要です。

1.5.D. 「完了基準」

テンプレート9: 「1.4 完了基準」
テンプレート9: 「1.4 完了基準」

 テンプレート9は完了基準です。なる程、潔いです。ただ、ちょっと厳し過ぎるかもしれません。なんらかの理由でテストの一部が未済かもしれないからです。

図4: 現実的な完了基準
図4: 現実的な完了基準

 結局、これを考慮すると、現実的な対応は図4で示した「現実的な完了基準」となります。

参考文献

この記事は参考になりましたか?

連載通知を行うには会員登録(無料)が必要です。
既に会員の方はを行ってください。
テンプレートから学ぶ 受注する開発者のためのテスト仕様書連載記事一覧

もっと読む

この記事の著者

山村 吉信(ヤマムラ ヨシノブ)

同志社大学大学院・電気工学専攻修了(工学修士)。プリンストン大学大学院・計算機科学科修了(MSE)。1978年、日本アイ・ビー・エム(IBM)入社。システムズ・エンジニア(SE)として、性能評価モデルの営業支援に従事。1983年、IBMサイエンス・インスティチュート(現東京基礎研究所)にて研究員とし...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/4154 2009/08/17 16:33

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー