みなさん、こんにちは。

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

テスト条件=機能×観点

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

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

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

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

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

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

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

次回(第3回)は期待値の書き方と、ありがちな失敗例をご紹介します。ご期待ください。

ご愛読、ありがとうございました。