ご承知のとおり試験項目書（テストスペックやテスト仕様書とも呼ばれますが本稿は試験項目書で統一します）とは開発したシステムを確認するための前提や試験項目を明確にした文書です。
今回はその試験項目書の書式を紹介します。
試験項目書の書式を通して品質の維持・向上を考えたいと思います。

試験項目書に限りませんが、書式化された文書を埋めることにより担当者に依存せず最低限の考慮がされた文書を作ることが出来ます。
そのため担当者による品質のバラつきが少なくなり、会社として一定以上の品質を保てるようになります。
これが書式を使う効果です。
さらに、書式そのものを振り返って改善することによって、品質の向上に繋げることが出来ると考えています。

では次に当社で使っている試験項目書の書式を紹介します。
なお、当社はISO9001を取得しており、品質マニュアルで試験項目書を作成することを定めています。そのため全社で使う試験項目書の標準ファイル（書式）があります。
その書式と私が携わる開発で用いた試験項目書の書式を紹介します。

書式のポイントは、

• いちいち考えなくても検討しておくことや最低限必要な記録が残せること。
• 誰でも同じ条件で同じようにテストが出来ること。

です。

書式は以下のa)〜e)で構成します。

書式 概要 ポイント a)表紙 文書を識別するための情報（タイトル、文書番号など）を書きます。 文書を管理するためのキーになる情報です。 b)変更履歴 いつ・誰がどんな変更をしたのか記録します。 変更内容をあとからでもわかりやすく書くのがポイントです。 c)試験実施記録 試験を実施した期間を書きます。 試験を実施した期間をあとから把握できるようにします。 再試験にどのくらいかかるかの情報としても利用できます。 d)試験前提 システムのハード構成とソフト構成、用意するデータ、各ソフトのバージョンなどテストの前提を書きます。 どういう前提で試験をしたかが後からでも分かる内容を書きます。前提が違うと試験結果も違ってきますから大変重要な情報です。 e)試験項目 試験内容と試験結果を書きます。 試験内容は、操作や入力とそれに対する表示・動作などの出力（期待される結果）を書きます。試験結果は、判定、実施者、実施日を書きます。 試験内容はシステムによって異なりますが、ポイントは、 ・試験を担当した担当者以外でも試験ができる ・後からでも同じ試験ができる 内容を書くことです。

表1. 書式一覧

「表紙」と「変更履歴」は会社で決めているところが多いと思いますので詳細な説明は省略します。また「試験実施記録」も項目を挙げるのはそれほど面倒ではないと思います。
当社ISO9001の書式は以上ですが、以降では私が携わる開発で使っている試験項目書の書式から「試験前提」と「試験項目」について詳しく説明します。

以下に項目を挙げます。
ポイントは、あとからでも試験環境を再現できる内容が書けることです。

項目 記載内容 メリット システム構成 確認に用いるハードウェアとソフトウェアの名称・数量・接続関係を記載します。 わかりやすくするために出来るだけ図表で示すようにします。 この項目を埋めることで、ハード・ソフトの手配（依頼先や数量）を具体的に細かく検討することになります。 テスト環境を正しく早く構築することに繋がります。 また、構築した構成のチェックリストにもなります。 ソフトウェア構成とバージョン テストで使うソフトウェアとそのバージョンを記載します。 開発したソフトだけではなく、OSのバージョン、使っている市販ソフトやDLL・OCXのバージョンなど試験環境を構成するソフトのバージョンも記載します。 この項目を埋めることで、時間が経ってからでも開発時と同じテスト環境を構築出来るようになります。 確認用データの前提 テストに用いるデータの前提を記載します。 具体的にはデータを識別する名称やデータのバージョン、保管場所などを書きます。 品質確認に用いたデータの記録を残すのが目的です。 同じ試験項目でもデータが異なると結果も異なる可能性があるため、試験に使ったデータを記録に残す必要があります。 システムテストでOKの内容が運用中NGになったときに、前提を比較した調査範囲を絞ることが出来ます。

表2. 試験前提

どんな試験をするのかを書きます。

項目 記載内容 メリット 確認できること 確認する機能や仕様の概要を書きます。 システムを全体的に見てどの仕様を確認するのか考えることが出来ます。また確認対象に漏れが無いかどうかのチェックもし易くなります。 前提・入力・操作・確認方法 テスト前提の準備、操作、入力情報など確認に必要なことを書きます。 確認内容だけではなく、その準備も書くことで、テスト方法を具体的に考えることになります。 左記以外にも入力範囲を通常・境界・異常と分類したフォーマットにしておくことで意識的にテスト項目に入れられるメリットがあります。 出来るだけ詳しく書くことで、後からでも正確にテストすることが出来ます。また誰でもテストができるようになります。 ポイントは操作、入力情報を出来るだけ具体的に書くことです。 テスト担当者に意図したテストをしてもらえないことを防ぐことになります。 出力 上記の入力に対して確認することを書きます。 出力結果の検討が出来ます。 記載するときは、判定ミスが起こらないよう注意して書きます。 例えばLEDが点滅する場合は、点滅周期や点灯・消灯の比率も書くようにします。 判定 試験項目を実施して仕様に適合しているかどうかを判定した結果をOK・NG等で書きます。 あとから試験した結果がわかります。 OKなのかNGなのかわからないときは備考にその旨を書きます。 確認者 確認した担当者の名前を書きます。 問題があったときに試験をした担当者がわかるようにしておきます。 確認日 いつ確認したかを書きます。 あとから試験した日がわかります。 備考 気付いたことを書く欄です。 気付いたことが記録に残ります。

表3. 試験項目

試験項目をシナリオ形式で書くことに私はメリットを感じていますのでここで紹介します。
シナリオはテストする前の準備から書きはじめ、操作手順とそれに対する出力を順番に書いていきます。下図にイメージを載せます。
いちいちテストの前提や操作手順を書くのは面倒で時間が掛かるのですが、様々なメリットがあると感じています。

• テストが出来ないときは仕様が不明確
  シナリオになっていると、操作手順がわからないなどということがなくなり迷わずにテストが出来るようになります。
  なおテストをしていて迷うということはテスト前提やテスト方法などが曖昧ということを示しています。曖昧ということはシナリオが不十分なだけかもしれませんが、仕様が不明確なままという可能性もあります。それを明確にする機会になります。

• 不適合の再現確認がしやすい
  確認項目がシナリオになっていると「不適合を発見したものの操作手順はうろ覚えで再現できなくなってしまう」という状況になりません。
  試行錯誤の無駄を減らし効率よく不適合修正することに繋がります。

• 属人性を減らせる（ことにつながる）
  シナリオ形式で書かれていると、仕様を知らない社員にでもテストを依頼出来るようになります（全ては無理でも一部だけでも依頼できるでしょう）。
  テスト作業によりシステム仕様を把握してもらえます。
  このようにシナリオ化によって開発担当者以外の社員が関わり易くなるため、属人性を減らす方法の1つになると考えます。

今回は試験項目書の書式を通して品質を維持・向上させる視点で、当社のISO書式と私が携わる開発で使っている書式を紹介しました。
この書式の見直しを繰り返すことにより長期的な品質の維持・向上に繋がると考えています。
世の中に試験項目の書式はたくさんあると思いますが、その1つとして見て頂き、品質向上のお役になれば幸いです。