「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の８日目です。
[blogcard url=”http://qiita.com/advent-calendar/2015/mmtest”]
今回は過去（２００７年に）寄稿した記事を少し手直しして掲載したいと思います。（初出はgihyo.jp向けの記事となります）
※ご注意：本Advent Calendar はあくまで池田の個人企画です。
■ソフトウェアテストはクリエイティブな仕事（技術）である
以前の記事でCPM法について触れましたが，まだまだ多くの現場でテストケースを作る際，仕様書に書かれていることをExcelにシコシコと入力し，語尾や数字だけを変更するという単純作業で行っているところが多いようです。そういった作業では勿論作業漏れや思考漏れによってテストケースが抜けることが多くなります。皆さんも実感していることだと思います。
今回はこの狭い範囲でのお話を例に取りますが，このようなテスト作業にマインドマップを使うと，ちょっとイイんです。本記事では，この「ソフトウェアテストとマインドマップのちょっとイイ関係」について，簡単にご紹介してみようと思います。
■ソフトウェアテストはひたすら頭を使う
まず，よくある「テストは頭を使わず，誰にでもできる」は完全に誤解であり，テストは非常に頭を使うクリエイティブな技術であるということを主張して，話を先に進めていきます。
テストを実施する際の情報源となる開発成果物のひとつは，プロジェクトの各局面で作成されたドキュメントです。これらのドキュメント，たとえばシステム仕様書や基本仕様書は，複数人の開発者がよってたかって，頭を使うだけ使って，再三にわたるデザインレビューをくぐり抜けた末に，ようやくできあがります。まさに開発者の知恵のの結晶とも言えるでしょう。一方テストでは，そうした知恵の結晶たるドキュメントを対象に静的テストを行い，またテストケースを作る際のテストベース（テストにおける情報源）とするために深く理解しなければなりません。
テスト技術者が実施するレビューなどの静的テストでは，ドキュメントに潜む仕様の抜けや間違いといった欠陥を見つけなければなりません。開発者が総力をあげて作成した物ですから，開発者以上によく考えないと欠陥を見つけ出すことは難しいでしょう。ただ単純にドキュメントの最初のページから読み進めながら欠陥を見つけ出していく方法では限界があります。
テストケースを作るためには，ドキュメントを基にソフトウェアのどこに欠陥が潜んでいそうなのか予想して（テスト設計を経ながら）テストケースに落とし込まなければなりません。これも開発者の知恵の結集たるドキュメントをよく考えないといけません。単純にドキュメントの文言をテストケーステンプレートに転記しているようでは，欠陥を発見できるいいテストケースにはなりません。
つまり，テストではある意味開発者以上に「よく考える」ということが大事なのですが，この「よく考える」というプロセスはマインドマップとちょっとイイ関係なのです。
■ソフトウェアテストとマインドマップのちょっとイイ関係
開発作業では，各局面でUMLやフローチャートを描いて意図や設計，構造といったものを煮詰めていきます。これらは言ってしまえばお絵かきですが，お絵かきを繰り返すことで，最終的に洗練された仕様なりプログラムができあがります。
ところが，テストについては本書執筆当時はあまりお絵かきはされてきませんでした。テストケースをExcel等のテンプレートに直接書いているのがほとんどです。しかしこれはUMLやフローチャートを書かずにいきなりプログラミングしてしまうようなものです。よほどスキルが高い人で無い限りできあがった代物の品質は想像できるのではないでしょうか。
マインドマップは，テストの作業におけるお絵かき，つまり一種のモデリング支援ツールとして機能します。これが，ちょっとイイ関係になる理由です。
■マインドマップによる効果
マインドマップをこの「よく考える」という部分に活用すると，どのような効果が得られるでしょう。3つほど挙げてみます。
- マインドマップの持つ一覧性により，関連関係がわかりやすくなる
この一覧性，言い換えればバードビューという特性は，テストにおいて実に大きな効果を与えます。テストは常に“網羅性”を考えながら行っていきます。カバレッジという言葉を聞いたことがあるでしょう。ドキュメントに関する網羅，コードに関する網羅，機能に対する網羅，要求に対する網羅，それぞれの組み合わせにおける網羅などなど挙げればたくさんあります。この網羅を考えるとき，マインドマップの一覧性が強力にサポートしてくれます。Excelシートに直接，という方法ではこうはいきません。 - マインドマップに描かれたキーワードから，新たな気付きを得ることができる
良いテストは，ある意味“どれだけバグの影に気がつくか”が勝負です。ドキュメントからいくつものキーワードをマインドマップに描いていると，ある時ふと「キーワード間の関係情報」に気がつくことができます。ドキュメントの最終頁に書かれていたことが，最初の方に影響を与えていたが気がつかなかったという経験があるでしょう。これを防ぐことができます。また「本来マインドマップに描かれるはずのキーワードがない」ということに気がつくこともあります。これが仕様の抜けであったりする場合が多いです。 - マインドマップを描いていると，自然に情報が整理されてる
マインドマップを描いていると，“本当に必要な情報”だけが描かれていくようになります。そして，その情報は自然と階層構造で描かれるなど，意識せずに整理が行われていきます。何回かマインドマップを整理していくことでテストすべき情報が階層化され，テストケースを検討する際にカテゴライズしやすくなります。また階層化されることで，テストケースの直交性の検討も行いやすくなります。
これら以外にも，描いたことを思い出しやすいとか，いろいろと効果を得ることができます。なにより，延々Excelシートとにらめっこしているより，絵を描くことで作業が楽しくなるという効果もあります。楽しくなってくると気分もノってくるので，テスト作業もサクサクと進めることができます。私自身，マインドマップでテストを考えていると，非常に楽しく，またのめり込むことができるので，結果としてテストケースの品質も上がっているように思います。
■おわりに
以上本当に簡単ですが，ソフトウェアテストとマインドマップのちょっとイイ関係について説明を行いました。テストにおける「よく考える」プロセスは非常に大変で疲れます。このようにマインドマップを活用することで作業の品質を向上し，また作業自体を楽しくすることも可能です。
