SHOEISHA iD

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

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

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

IEEEが定めるテスト設計仕様
― 用語/テスト文書/要求仕様/設計

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

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

 アメリカの電気電子学会であるIEEE(アイ・トリプル・イー)はコンピュータの標準を多く出しています。ソフトウェア関連の標準も充実しており、今回はそのうち、用語、テスト文書、要件仕様、設計を参考にします。

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

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

 アメリカの電気電子学会であるIEEE(アイ・トリプル・イー)はコンピュータの標準を多く出しています。ソフトウェア関連の標準も充実しており、今回はそのうち、用語テスト文書要件仕様設計を参考にします。

 いつもと同様にテンプレート(template006.doc)はダウンロード文書として用意しました。その他、今回はテスト文書の全体図(TestDoc.pdf)、使用するテスト文書のExcelファイル(TestDesign.xls)を同梱しています。

2. 「テスト文書」の全体図

図1:IEEEテスト文書全体図
図1:IEEEテスト文書全体図

 図1にテスト文書の全体図を載せました。この図では、左から

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

という開発にも似た流れがあることが分かりますね。

 個々の文書は、その文書を使うところで詳しく解説します。

  • テスト計画(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. 「テスト設計仕様」

 テスト設計仕様の目的は「テスト方法を明確にし、この設計に関連するテストで行われる『機構(feature)』を特定する」ことです。

3.1. 機構(feature)とは何か

 「機構」という言葉は大事です。漠然とした日本語の感覚で分かった気になりがちですが、ここではIEEEが出している用語で定義を見てみましょう。

機構(feature):

 「ソフトウェア機構(software feature)」参照のこと。

ソフトウェア機構(software feature):

  1. ソフトウェア項目の特徴(例えば、性能、移植性、機能)
  2. 要件文書に指定または暗示されたソフトウェアの特徴(例えば、機能、性能、属性、設計上の制約)

 これは前回解説した要件仕様の目次に載っていましたね(図2に再掲します)。結局これは要件仕様で書かれた要件そのものでした。

 テストする機構とは要件仕様で書かれた要件ということが分かりました。要件仕様で書かれた要件は、設計記述で分割されて設計要素になります。従って、設計要素もテストする機構となります。さらに設計要素はプログラム、パラメータ、等で実現されます。従って、それら実現もテストする機構となります。

図2:再掲「要件仕様の目次」
図2:再掲「要件仕様の目次」

3.2. テスト設計仕様のサンプル

 サンプル1に実際に使った「テスト設計仕様(ドラフト)」を載せました。個々の用語の解説は下記で詳しく述べるとしてざっと目を通してみましょう。

 サンプル中、赤字で「TBD」と書いてあるのは「To Be Determined(決めなければならない)」の略で、今は決められないけど後でちゃんと決めないといけない、ということを示しています。

サンプル1: 「テスト設計仕様」
サンプル1: 「テスト設計仕様」

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

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

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

メールバックナンバー

次のページ
4. テスト設計仕様の各項目

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

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

もっと読む

この記事の著者

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

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

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

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

この記事をシェア

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

おすすめ

アクセスランキング

アクセスランキング

イベント

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

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

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

メールバックナンバー

アクセスランキング

アクセスランキング