前々回、前回の記事に続いて、2011年にSQiPのサイトで連載してた記事の第三話の再掲です。

テスト設計とは何か？については何度か書いたことがあり、例えば2004年のITmediaの連載や、2005年の日経ソフトウェアの連載、2009年のWACATE マガジンVol8（の中の「ゆもつよのこちらテスティング事業部」という連載）では、以下の３つのお題に対して解を出すことがテスト設計だ！なんて話してました。
・ より網羅性の高いテストを行う
・ 少ない数のテストケースでテストを行う
・ テストでより多くの不具合を見つける

けど、これらの３つはテストの目的設定やスコープ設定で微妙にステークホルダー間で話が噛み合わなくなることがコンサルしているクライアント先でもよく起きて、お題よりも具体的な観点を述べた方がわかりやすいかもってなり、結果的にこの連載のような話をするように変わってたんじゃないかなって、振り返ると思いました。テストプレスVol10（2010年）頃からこのnoteの方式で説明しています。

まぁ、みんな古い話にはなりますが、このレベルの抽象度の話はいつまでたっても変わらない話になるので、今の若い人が読んでも価値あるかと思います。

----------------------------

1. はじめに

ソフトウェアテストはここ10年の間に多くの専門書籍が出版され、Web媒体やシンポジウムなどでも多くの情報が入手できるようになりました。筆者は、ソフトウェアテストのコンサルティングという仕事を通じて、記事を書いたり講演をしたりすることがあるのですが、いろいろな方とお話をする機会を得るたびに、ソフトウェアテストに関して似たような質問を受ける事が多くあります。それらの質問は、書籍などに書いてある専門的な質問と言うより、もっと原点に戻るような質問であることが多くあります。

今コラムではそのような「ソフトウェアテストにまつわるよくある疑問」とそれに対する私の回答を四回に分けて紹介していきたいと思います。第三回は「テスト設計をするとはどういうことか？」と言う質問です。

2. テスト設計をするとはどういうことか？

 質問を受ける状況
この質問は、実は「テストに設計が必要なのですか？」と聞かれることのほうが多くあります。テストの現場に携わっていない方からこのような質問を受けることが比較的多いと思います。筆者は15年以上ソフトウェアテストの仕事ばかりをしてきたため、テスト設計をすることが当然になってしまっていて、最初にこのような質問を受けた時にわかりやすく答えられなくて困りました。

 テストを設計することとは？
「ソフトウェアテストにまつわるよくある疑問」のコラムの初回にて、テスト目的とテスト対象を決めたら十分かどうかが測れるようになる、というお話をさせていただきました。
ただ、実際に、テスト目的とテスト対象を決めたらテストケースが書けるでしょうか？テスト対象について書かれている仕様書には、テスト目的を満たすためのテストケースを書くための情報が全て書かれていますか？
また、仕様書に書かれている事を全てテストする時間はあるでしょうか？

テストを設計することとは、テスト対象について書かれている仕様書や設計書から、テストケースをテスト目的に沿って抽出することです。抽出するためには、単純に右から左に流すのではなく様々な工夫が必要であり、それこそがテストにも設計が必要な理由となります。以下にいくつかテスト設計しているテストケースとテスト設計していないテストケースの違いを列挙したいと思います。

 テストで確認すべきポイント
設計されていないテストケースは、気になったところや仕様書に記載があるところをとりあえず片っ端から選択するか、その場で気になったところを選択して書いています。設計したテストケースは、テストで確認すべきポイントを絞るために、機能を整理して機能毎に観点を明らかにする手法を活用し、テスト目的に沿ったテストケースを選択しています。

 テストすべき優先順位
設計していないテストケースは、とりあえず着手できるところからテストするように書いています。設計したテストケースは、品質リスクや作業の効率性を考慮してテストケースを書いています。テストケース毎に何を確認したいのか、例えばロジックが正しく実装されているのか、もしくは想定外の挙動をしないか、といった観点が明確です。

 サンプリング方法
設計していないテストケースは、場当たり的か、もしくは非論理的にサンプリングしてテストケースを書いています。設計したテストケースは、同値分割を行い代表値をサンプリングしたり、境界値を分析したり、組合せを行う場合もデシジョンテーブルや状態遷移、ペアワイズといったモデルを作って網羅的になるようサンプリングしてテストケースを書いています。

注釈：（ISO/IEC/IEEE29119というテストの標準ではサンプリングするもののことP-V〔パラメーターとバリュー〕と呼びます。）

 テスト設計技法を適用するまでの道のりも重要

テスト設計のことを、テスト設計技法と呼ばれる技術を適用することだと思っている方も多くいます。それはある意味正解ではあるのですが、全てのテストケースがテスト設計技法を適用しないと書けないわけではありません。例えば画面に表示された文言を確認するためのテストは、技法を知らないでもテストケースが書けます。
テスト設計技法は、極論すると、テスト対象を技法が適用できるよう小さい単位に分解し、その「部分」をモデル化して、そのモデルを網羅するようにテストケースを書くことです。教科書に出てくるテスト技法の演習では予め「部分」が提示された状態で、利用する技法も提示されて、といったお膳立てがあったうえでテストケースを導いているので、誰でもできるようになっていきます。しかし、現実にテストをするソフトウェア（もしくはその仕様）はいきなり技法が適用できる「部分」としては提示されません。テストケースを書くためには、技法が適用できるサイズまでソフトウェアを分解しなければなりません。つまり、目的を具体化した観点でテスト対象を絞り、技法を選択する行為が必要であり、それこそがテスト設計として最も頭を使う創造的な作業となります。

この「道のり」が、例えばテスト設計の前にテスト分析があるって話やテストアーキテクチャ設計の話であったり、HYAST法やVSTeP、ゆもつよメソッドといった手法の提唱であったりします。（ただし、手法が扱っている範囲などが微妙に異なるので単純に同じように扱うのは注意が必要です。）つまり、テスト設計といっても、ちゃんとやろうとすると、いくつかのフェーズに分けることが必要になるわけです。

3. 最後に

今回の質問の回答は、「テストを設計するとは、的を射たテストケースを抽出するために工夫をすること」となります。
的を外すとそのテストは無意味なものになってしまいますし、的を外さないようにひたすらたくさんテストケースを書いて、実行していたら、何年たってもテストが終わらなくなります。ただ、このように創造的で奥が深いところがテストの面白いところでもあると思います。