みなさん、こんにちは。
テスト仕様書の作り方大公開の第２回です。前回はテスト設計の手順とセオリーについてご説明しましたが、そろそろ痺れを切らす頃かと思いますので、「個人登録画面」（図-1）を例として『テスト条件一覧』を作成してみましょう。
前回記事はこちら
テスト条件＝機能×観点
まずは、設計書から機能（何ができるか、どう振舞うか）を洗い出し、詳細化していきます。 個人登録画面の場合、「初期画面を表示する」「入力を受付けチェックする」「画面遷移する」の３つの主要な機能があります。そして、その機能は具体的に『どの項目』に作用するのか（画面、帳票、ファイル、DBなど）、どういう見方をするのか（観点）を対応付けます。それらをテスト区分～区分3に割りつけていきます。区分はもっと細かくしてもよいでしょう。結果の例を図-2に示しますので参考にしてください。
さらに、それぞれの機能に対して「何を確認するのか」を当てはめ、確認項目欄に記入していきます。要件レベルの概念的な表現でかまいません。例えば「～～の妥当性」「～～の整合性」といった具合です。
この辺が第一関門となるわけで、「どうやればうまくいきますか？」「やり方の決まりはあるのですか？」と質問を受けることがよくあるのですが、正直なところ正解はありません。まさにケースバイケースです。機能をどう捉え観点をどう組み合わせるか、にかかってくると思います。 一度で完成させようとせず、何度か違った角度（切り口）から考えてみることをお勧めします。
パターン分けが必要か考える
テスト区分～区分3まで細分化した要素について、確認項目欄の内容を確認するうえで条件やデータのバリエーションによる処理の分岐（結果の違い）があるかどうかによって、パターン分けをする（デシジョンテーブルを作る）かそうでないかを決めます。
例えば、画面遷移で[戻る]ボタンを押下した時の期待される動作は「メニューに戻ること」と一意に決まりますので、パターン分けの必要はありません。それに対して、生年月日の項目チェックは日付妥当性と一口に言っても「カレンダー的な正しさ」「未来日付・過去日付」「他の日付との前後関係」といったいろいろなパターンがあります。そのような場合はデシジョンテーブルを作って条件を整理しないと、抜け漏れが出てしまいます。
デシジョンテーブルの作り方及びパターン番号、パターン説明の書き方は第４回の記事で説明します。
次回（第３回）は期待値の書き方と、ありがちな失敗例をご紹介します。ご期待ください。
ご愛読、ありがとうございました。
テストに関するお役立ち資料
テスト設計・仕様書の作り方に役立つ資料を多数ご用意しています。ぜひDLしてご利用下さい。
資料一覧は【こちら】
