SHOEISHA iD

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

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

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

テスト文書の「テスト項目仕様」および「テスト手続き仕様」

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

  • X ポスト
  • このエントリーをはてなブックマークに追加

 前回に引き続き、IEEE(アイ・トリプル・イー)のテスト関連の仕様です。IEEEの文書では用語、テスト文書、要件仕様、設計を参考にします。

  • X ポスト
  • このエントリーをはてなブックマークに追加

1. IEEE(アイ・トリプル・イー)(続き)

 前回に引き続き、IEEE(アイ・トリプル・イー)のテスト関連の仕様です。IEEEの文書では用語テスト文書要件仕様設計を参考にします。

 いつもと同様にテンプレート(template007.doc)はダウンロード文書として用意しました。その他、今回は使用するテスト文書のエクセル(TestItem.xlsおよびTestProcedure.xls)を用意しました。

2.「テスト文書」の全体図(再掲)

 図1にテスト文書の全体図を再掲しました。

図1: IEEEテスト文書全体図(再掲)
図1: IEEEテスト文書全体図(再掲)

 この図では、左から

計画 ⇒ 設計 ⇒ 手続き ⇒ ログ ⇒ インシデント

という開発にも似た流れがあるということを学びましたね。個々の文書は、その文書を使うところで詳しく解説します。

  • テスト計画(Test Plan): テスト活動の範囲、方法、資源、スケジュールを定める。テストされる項目、実施されるテストの仕事(task)、それぞれの仕事に責任を持つ人、この計画に伴うリスクを特定する。
  • テスト計画項目参照(Test Plan Item Ref)
  • テスト設計仕様(Test Design): 前回述べました
  • テスト計画イントロ参照(Test Plan Intro Ref)
  • テスト計画成果物参照(Test Plan Deliverable Ref)
  • テストケース仕様(Test Case)
  • テスト項目仕様(Test Item): 下記で詳しく述べます
  • テスト手続き仕様(Test Procedure): 下記で詳しく述べます
  • テストログ(Test Log)
  • テストインシデントレポート(Test Incident Report)
  • テストインシデント(Test Incident)
  • テスト項目伝達レポート(Test Item Transmittal Report)
  • テスト要約レポート(Test Summary Report)

 今回使うのは「テスト項目仕様」と「テスト手続き仕様」です。

3.「テスト項目仕様」

 テンプレート1に「テスト項目仕様」の各項目を掲げました。項目は沢山ありますが、「テスト項目仕様」の実体はテスト項目(TestItem)です。名前のままです。

 前述の図1では「テスト項目仕様」は「テスト・ケース仕様」から呼ばれるように見えます。「テスト・ケース仕様」は「テスト項目仕様」を参照するので、実はこの2つのテーブルは相互参照しています(これは「テスト・ケース仕様」を説明する時に詳しく述べます)。つまり「テスト・ケース」ごとに「テスト項目」があるわけではありません。

テンプレート1: 「テスト項目仕様」
テンプレート1: 「テスト項目仕様」

 各項目は以下の通りです。

  • 「ID(識別子)」は表の要素(エントリー)を識別するために、用意します。
  • 「TestItemID(テスト項目番号)」はテスト項目(この表)を他の表から参照する時に使います。
  • 「TestCaseID(テスト・ケース仕様番号)」はテスト・ケース仕様を参照しています。
  • 「TestItem(テスト項目)」はテスト項目そのものです。第1章「単体テスト」節1.2「内容」で列挙した内容ごとに分解して記入します。テンプレート2に再掲します。
  • テンプレート2: 再掲「1.2 内容」
    テンプレート2: 再掲「1.2 内容」
  • 「Date」は4項目あって、プロジェクト管理用に使います。
    • DateInPlanned(予定開始日)
    • DateOutPlanned(予定完了日)
    • DateInActual(実開始日)
    • DateOutActual(実完了日)

3.1. テスト項目

 現在、説明しているのは「単体テスト」の中の「ホワイト・ボックス・テスト」です。この時の「テスト項目」はプログラムの内部構造で制御を表す変数を見ていると洗い出すことができます。

 先になって「ブラック・ボックス・テスト」になっても「テスト項目」を使います。その時は仕様から「テスト項目」を洗い出すことになります。

会員登録無料すると、続きをお読みいただけます

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

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

メールバックナンバー

次のページ
4.「テスト手続き仕様」

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

  • X ポスト
  • このエントリーをはてなブックマークに追加
テンプレートから学ぶ 受注する開発者のためのテスト仕様書連載記事一覧

もっと読む

この記事の著者

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

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

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

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

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/4791 2010/04/06 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

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

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

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

メールバックナンバー

アクセスランキング

アクセスランキング