検証エキスパートコラム

みなさん、こんにちは。
テスト仕様書の作り方大公開の第２回です。前回blog-No.36はテスト設計の手順とセオリーについてご説明しましたが、そろそろ痺れを切らす頃かと思いますので、「個人登録画面」（図-1）を例として『テスト条件一覧』を作成してみましょう。
（図-1）


 

テスト条件＝機能×観点

まずは、設計書から機能（何ができるか、どう振舞うか）を洗い出し、詳細化していきます。
個人登録画面の場合、「初期画面を表示する」「入力を受付けチェックする」「画面遷移する」の３つの主要な機能があります。そして、その機能は具体的に『どの項目』に作用するのか（画面、帳票、ファイル、DBなど）、どういう見方をするのか（観点）を対応付けます。それらをテスト区分～区分3に割りつけていきます。区分はもっと細かくしてもよいでしょう。結果の例を図-2に示しますので参考にしてください。

さらに、それぞれの機能に対して「何を確認するのか」を当てはめ、確認項目欄に記入していきます。要件レベルの概念的な表現でかまいません。例えば「～～の妥当性」「～～の整合性」といった具合です。

この辺が第一関門となるわけで、「どうやればうまくいきますか？」「やり方の決まりはあるのですか？」と質問を受けることがよくあるのですが、正直なところ正解はありません。まさにケースバイケースです。機能をどう捉え観点をどう組み合わせるか、にかかってくると思います。
一度で完成させようとせず、何度か違った角度（切り口）から考えてみることをお勧めします。
（図-2）

パターン分けが必要か考える

テスト区分～区分3まで細分化した要素について、確認項目欄の内容を確認するうえで条件やデータのバリエーションによる処理の分岐（結果の違い）があるかどうかによって、パターン分けをする（デシジョンテーブルを作る）かそうでないかを決めます。

例えば、画面遷移で[戻る]ボタンを押下した時の期待される動作は「メニューに戻ること」と一意に決まりますので、パターン分けの必要はありません。それに対して、生年月日の項目チェックは日付妥当性と一口に言っても「カレンダー的な正しさ」「未来日付・過去日付」「他の日付との前後関係」といったいろいろなパターンがあります。そのような場合はデシジョンテーブルを作って条件を整理しないと、抜け漏れが出てしまいます。

デシジョンテーブルの作り方及びパターン番号、パターン説明の書き方は第４回の記事で説明します。

次回（第３回）は期待値の書き方と、ありがちな失敗例をご紹介します。ご期待ください。
なお、検証サービスに対するお問い合わせは＜お問い合わせフォーム＞までお願いいたします。
ご愛読、ありがとうございました。

この連載のバックナンバー
(第１回)テスト設計の手順とセオリー
(第２回)テスト条件一覧（機能と観点の掛け算）
(第３回)テスト条件一覧（確認項目と期待値）
(第４回)デシジョンテーブル（曖昧さ排除テク）
(第５回)デシジョンテーブル（条件網羅テク）
(第６回)結合テストをどう考えるか
(最終回)結合テストの勘所