「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の１５日目です。
[blogcard url=”http://qiita.com/advent-calendar/2015/mmtest”]
今回の記事は，Chapter７「テスト実装 ～テストケースを作成をしよう～」です。いつものように読む上で注目して欲しいポイントと補足をします。
※ご注意：本Advent Calendar はあくまで池田の個人企画です。
■テスト項目とテストケースは別として説明
よくテスト項目をテストケースの意味で使っている場面に出くわすことがありますが，本書ではテスト項目とテストケースは別のものとしています。ざっくりと説明すると，テスト項目はどういった事に着目しているのかを表し，テストケースは具体的な手順等を含むものです。テスト項目はテスト観点として表現されることもありますし，テストカテゴリやテストタイプとして表現されることもあります。ISTQB的に言うと，ここでのテスト項目はハイレベルテストケースということもできるでしょうか。テスト項目やテストケースという言葉の意味は今でこそISTQB用語集を参照すれば良いと思いますが，執筆当時はJSTQBの試験も始まって居らず日本語訳された用語集もありませんでした。ですので，本書では書かれているように整理をしています。読まれる場合にはそのあたりの事情を意識しながら読むとわかりやすくなるでしょう。
また，テストケースとテスト手順，テストシナリオについても解説されていますが，同様のことが言えますのでご注意下さい。
■テストケースはテスト設計から機械的には導けない
テスト設計結果からテストケースは簡単に作れると思われがちですが，実際の所はそうでないことを本章では示しています。抽象度が高いテスト設計から，手順レベルでの記述になるほどの具体的なテストケースを作り出す場合，テスト設計では生み出せなかった“具体的な”情報が追加で必要になることがあります。直接的には本文には書かれていませんが，テスト設計結果とテストケースをつなぐための情報を集めるというプロセスが必要です。ここで必要な情報は何かということを考えるためにマインドマップは効果を発揮します。
■テストケースのテンプレートそのものを設計する
案外見落としがちなのが，テストケースの構造や表現方法そのものも設計する必要があるということです。テストケースを作成する際にテスト技法を使用する場合がありますが，技法による出力は多様であるため，組織などで決められているテンプレートでの表現が難しいことがあります。
例えば状態遷移テストの出力は表かグラフ（図）のほうが直感的です。よく，日本語表記ベースのリスト型のテンプレートを標準としている場合がありますが，先ほどの表やグラフで表現された物を変換する必要が生じます。それはひょっとすると無駄な作業かもしれません。また，変換時にテストケースに欠陥を埋め込んでしまう可能性があります。
テスト実行を担当する担当者のレベルによって記述の詳細度のレベルが変わることもあるでしょう。新人や業界未経験の人が担当するのであれば，手順レベルまで懇切丁寧に書く必要があるでしょうし，ある程度のベテランであれば多少のことは省いてもいいかもしれません。
また，文中では解説していませんが，テストケースの構造を決めた後にはその記述ルールを決めておく必要があります。プログラムにコーディングルールがあるようにテストケースもルールを決めておかないと，テストケースの作成者で記述内容にばらつきが生じ，可読性を損ないます。多くの場合，テストケースは日本語で記述されますが日本語自体は曖昧性を多く含む言語なので，特に注意する必要があります。細かいところでは，段落の分け方や使う表現（受け身を禁止，とか）なんていうのもあります。また，当然ながら用語集なども参照する必要があります。
■テストケースを導くためにテスト技法を活用する
敢えて本書には書かなかったのですが，テスト設計およびテスト実装では「テスト技法」を利用するとよいでしょう。ただしテスト設計をせずにテスト技法を使おうとすると使いどころがわからなかったり，あまり効果を生み出さない使い方になってしまうことに注意して下さい。
■おわりに
テスト実装は「テストケースリストに列挙していくだけ」と思われがちな作業ですが，それほど単純なものではありません。必要な作業を認識し，ひとつひとつ順を追って作ることが大切です。この機会に改めてテストケースの作成という作業を振り返ってみてはいかがでしょうか。
