「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の１４日目です。
[blogcard url=”http://qiita.com/advent-calendar/2015/mmtest”]
今回の記事は，Chapter6「テスト設計 ～テスト設計をしよう～」です。いつものように読む上で注目して欲しいポイントと補足をします。
※ご注意：本Advent Calendar はあくまで池田の個人企画です。
■いきなりテストケースはＮＧ
テストのプロセスが十分に普及していない現場ではテスト設計を実施せずにいきなりテストケースを作成する光景をよく見かけます。テストケースが記述された文書からもそう見てとれる事も多いです。
文中，先輩は新人に向けてこう言っています。
「いきなりテストケースを書き始めるのではなく，ちゃんとテスト設計からやらないとダメだよ。いきあたりばったりでテストケースを書いてしまうと，漏れや抜けがが多くなってしまうんだ。テストでも，ちゃんと設計を意識すること。このテスト設計の作業品質でテストケースの品質も決まってくるから，よく考えて取り組むことが重要だよ。」
（引用：マインドマップから始めるソフトウェアテスト p.111）
この先輩の言葉がChpater6でもっとも大切な部分かもしれません。さらに整理してみます。
- テストケースは行き当たりばったりで作ってはいけない
- テストでも“設計”を意識すること
- テスト設計の作業品質でテストケースの品質も決まってくる
文字面，そりゃ当たり前でしょと思う方がほとんどですが，設計しているというのならば設計書のような物がアウトプットとして存在するはずです。ですがそのようなものがないのがほとんどなのではないでしょうか。もしくはテスト設計書といいつつも中身はテストケースだったり，単なる方針指示書だったりするかもしれません。以前にも少しだけ言及しましたが，テストケースを仕様書から直接作成するという行為は，いきなりプログラミングと同じような行為です。よほどのエキスパートでなければ作業品質もアウトプット品質も良くならないでしょう。
テスト設計とはテストケースを書く前にテストの観点や方針や意図といったようなものの全体像を作るという行為であるわけでとても重要なことなのです。
■本書におけるテスト設計
本書Chapter6で解説しているテスト設計の内容と手順は，現在多少の異なりが生じてきてしまっていますので，特に注意深く読み進めていただきたいと思います。
Chapter6で紹介している手順は以下のような物です。
「テストの目的を確認する」
↓
「テスト対象の仕様を確認する」
↓
「テスト項目の候補を挙げる」
↓
「テスト項目の値を検討する」
↓
「テスト項目の組み合わせを検討する」
ここで，テスト分析設計技法をいくつか勉強している方であれば「あれ？仕様を確認するのはテスト分析では？」と思う方もいるでしょう。筆者が本書を書いた後に作ったテスト分析設計手法TAMEでも仕様を確認するのは仕様分析（テスト分析）に置いています。なので，混乱を招きそうですね。
ここで言うところのテスト対象の仕様を確認するというのは，Chapter4での仕様の確認よりも，より詳細なレベルでの確認ということになります。Chapter4は要件定義書や社内で規定されているテストカテゴリを参考にして「大枠としてどういったテストをやるか」といったところを検討しています。これは計画の初版を作る上でも必要な作業です。
Chapter6の確認は今後テストケースに落とすための，テスト設計（テストモデル／テストアーキテクチャ）を詳細に決めるための確認ということになります。ですので同じような言葉ではありますが，目的ややるべきことが違うという事に注意して下さい。脚注にもあるとおり，三色ボールペンを使うなど，作業としての内容も異なります。
現在において様々なテスト分析設計手法を知っていると，このChapterがある意味読みにくいと感じると思いますが，前述を意識して読み進めていただくと良いと思います。
■おわりに
発行されて8年も経つと，技術の進化により当日の記述と違和感が生じる部分が出てきます。そこに注意を払いつつも，一方当時との差について検討してみると，それはそれで様々な発見があると思います。単に古い記述と切り捨てるのはもったいない部分もありますし，基礎は変わらない訳ですから改めての温故知新ということでも読み直していただくと良いと思います。
