テスト仕様書の書き方～テストケース作成のポイント～

「テスト仕様書」は、ソフトウェアテストをどのように実施するのかを記したドキュメントのことです。JSTQB(Japan Software Testing Qualifications Board)の用語集では「テストアイテムに対するテスト設計、テストケース、テスト手順をすべてドキュメントにしたもの」と定義されています。
プロジェクトによっては、テスト方法やテスト内容などを記したドキュメントを「テスト設計書」と呼び、JSTQBにおける「テスト仕様書」と同じドキュメントを意味することがあります。

株式会社SHIFTでは、ソフトウェアテストに関して豊富な実績とテストナレッジを保有しており、あらゆるお客様のニーズを満たしたテスト・品質保証を上流～下流（テスト計画・テスト設計・テスト実行・テスト品質管理）まで一気通貫でご依頼いただけます。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

テストを実施するためには、具体的な確認内容や期待値などをまとめた「テストケース」が必要になります。今回は、「テスト仕様書」の一部であり、確実なテストを実施するために重要な役割を担う「テストケース」の書き方について解説します。
テストケース以外にテスト仕様書に記す内容である「テスト設計」、「テスト手順」については、以下をご参照ください。

・「テスト設計」コラムのテスト設計方針
テストケースを作成する前に、どのようなテストケースを、どのように作成すべきかを検討します。

・「テスト手順」コラムのテスト実装
作成した複数のテストケースをどのように実施していくかを検討します。

テスト計画、テスト設計の方針通りにテストが実施できるようにするために、テストケースに記載する項目は「テスト対象」「テスト観点(確認内容)」「テスト条件」「テスト手順」「期待値」の5つです。これらを明確に記載することで、確認すべき項目の抜け漏れを防ぐことが可能です。テストケースのフォーマット(表1)は現場やプロジェクトによって異なりますが、テストケースに記載すべき5つの要素(表2)は、どのような現場やプロジェクトにおいても、テストを実施する時に必ず考慮すべき事項になります。SHIFTでは、この5つの要素をテストケースに記載することを基本としています。

また、テストを実施した結果を記載する「実行日」、「実行者」、「実行結果」の列は、表1の例では、1列ですが、ダブルチェックや再確認など2回以上テストを実施する場合は、1回目、2回目と実行回数ごとに列をわけていきます。

表2：テストケースに記載すべき5つの要素

テストケースは、どのようなテストを実施するかを明確にするために作成します。テストケースには、テスト実行者、ほかのテスト設計者、レビュアー、開発者といった読み手がいます。どの読み手にも、テスト内容が理解できるように記述しておかなければ、テストケースとして意味のないものになってしまいます。

以下に、テストケースを作成するための3つのポイントを解説します。

テストケースに具体的な値のみを記載し、何を確認したいかが記載されていないことがあります。例えば、表3のようにテスト条件として「購入する商品A」とだけ記載されているような場合です。このような場合、何を確認するために商品Aを選択しているのかが、読み手に伝わりにくいです。期待値を確認することにより、何を確認するテストかを推測できることもありますが、読み手に確実に伝えるためには、テスト観点・確認内容に、そのテストで何を確認したいのかを記載するようにします。

　テスト観点・確認内容は、一読してそのテストケースの目的・意図が把握できるようにします。例えば、テスト観点には「端数処理」、確認内容は「1円未満の端数の金額が切り捨てられることを確認する」というように記載します。このようにすると、テスト実行者に確認したい内容が伝わりやすいだけでなく、テストケースをレビューする時にも有効です。テスト対象とテスト観点・確認内容を見ることで大まかなテスト内容が把握できるようにしておくと、レビューがスムーズに進むようになります。

テストケースの期待値(どのような結果になっていれば合格か、期待される結果)に「処理が正しいこと」や「正しく動作すること」などと書かれていることがあります。しかし、「処理が正しいこと」「正しく動作すること」とはどういうことなのでしょうか。

処理の仕様によっては、データが登録されることが正しい場合もありますし、データが登録されないことが正しい場合もあります。このような曖昧な表現では、テストケースの作成者と読み手で解釈が異なってしまうことが起こり得ます。もし、テスト実行者がテストを実施する際に誤った解釈をしてしまったら、テスト結果NGとして報告されるべきケースが結果OK(問題なし)として報告され、不具合を見逃してしまう原因となります。

そのため、期待値には「データベースの●●●項目にXXXXXXのデータが登録されること」といった形で、項目名やデータの内容を具体的に書くようにします。

システム仕様書に「特別会員のユーザーは、特別会員限定画面にアクセスできる」という記載があった場合、どのようなテストケースが必要でしょうか。

「特別会員でログインし、特別会員限定画面が閲覧できることを確認する」といった内容のテストケースをつくるでしょう。しかし、これだけでは不十分です。何故ならば、上記のテストケースでは「特別会員が特別会員限定画面にアクセスできること」は確認できますが、「特別会員以外が特別会員限定画面にアクセスできないこと」は確認できないからです。

つまり、このテストケース単体では、「特別会員以外が特別会員限定画面にアクセスできる」という不具合を見逃してしまうことになります。

これを防ぐため、「Aの場合●●できること」を確認するケースをつくったら、「Aではない場合●●できないこと」を確認するケースを作成する必要がないか必ず考えてみる必要があります。

今回の例で言えば、最初につくった「特別会員でログインし、特別会員限定画面が閲覧できることを確認する」というケースに加えて、「特別会員以外(一般会員)で特別会員限定画面にアクセスできないこと」といったケースが必要となります。

熟練したテスト設計者は、特別会員限定画面の仕様には明記されていない場合でも、会員種別(特別会員、一般会員、ゲスト会員)、会員の状態(入会中、休会、退会)などといった会員に関する情報からテスト結果に影響を及ぼしそうな要素を読み取り、組み合わせを考えていきます。表5のように、パターン表にして表現するとわかりやすいです。そして、テストケース作成時に出た仕様の不明点については開発者にヒアリングしながら、仕様への考慮漏れや仕様書への記載不足などを指摘し、品質向上に貢献します。

今回紹介した3つのポイントを意識することにより、読み手が理解しやすいテストケースをつくることができ、テストケースの抜け漏れ、テスト実行者の認識誤りといった不具合を見逃す原因を回避しやすくなります。テストケースのフォーマットは現場によって異なるかと思いますが、これらの考え方はどの現場でも共通して使えるものですので、ぜひご活用ください。

今回は、「テスト仕様書」の一部であるテストケースの書き方、ポイントについて解説をしました。テストケースは確実なテストを実施するために非常に重要なもので、テストケースの書き方がテストの精度に大きな影響を与えます。3つのポイントはどの現場でも共通する考え方ですので、これらを意識しながらテストケースを書いてみてください。

SHIFTでは、開発の上流工程からテストまでの一気通貫でのシステム開発を請け負っています。多数の導入実績を誇っており、あらゆる分野の開発に携わってきました。

また、一部分だけのご依頼も可能です。本記事で紹介したソフトウェアテストだけの実施でもご相談ください。特にソフトウェアテストは弊社が力を入れてお客様のサポートをさせていただいている分野です。安心・安全にソフトウェアを使うためにも、ソフトウェアテストでお困りであればぜひSHIFTまでお問い合わせください。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ