「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の１２日目です。
[blogcard url=”http://qiita.com/advent-calendar/2015/mmtest”]
今回の記事は，テスト計画についてです。
※ご注意：本Advent Calendar はあくまで池田の個人企画です。
■テストスケジュール＝テスト計画？
テスト計画立ててますか？と質問すると「何言ってるんですか，当たり前でしょう！」といって手渡されたのはどう見てもスケジュール表（ガントチャート）でしたことによく遭遇しましたし，現在もそういった現場が多いように感じています。
この章で伝えたいことはひと言です。
スケジュールはスケジュール，計画じゃないよ！
ということです。
■テスト計画とは？
Chapter５ではまさにこのような展開から新人君にテストにおける計画とはなんぞやということを解説しています。この計画はソフトウェアテストではIEEE829というデファクトのテンプレートが存在します。829でのテスト計画テンプレートを以下に示します。
①テスト計画識別番号
②はじめに（序文）
③テストアイテム
④テストすべき機能
⑤テストしない機能
⑥アプローチ
⑦合否判定基準
⑧テスト中止／視界基準
⑨テスト成果物
⑩テストのタスク
⑪環境要件
⑫責任範囲
⑬要員計画とトレーニング計画
⑭スケジュール
⑮リスクと対策
⑯承認
（引用：マインドマップから始めるソフトウェアテスト p.90～91）
どうでしょうか，スケジュールは計画の一項目として14番目に登場するに過ぎません。テストの作業は実行のみと言う現場に於いてはスケジュール＝計画という認識なりやすいですが，テストのリテラシが向上してくるとスケジュールだけの計画では対応が難しくなってきます。なぜならばテスト実行以外の範囲についても計画を立てる必要が出てくるからです。その際に様々な概念を盛り込んで計画を作る必要があり，その整理された一例が829でのテスト計画テンプレートと言うことになります。このChapterを読み進めるにあたっての一番のポイントはスケジュール以外もあって初めて計画であるということです。
■テストの計画は安定しない
さて，計画というと，最初にキッチリ細部まで検討し尽くしてからあとはそのとおりに実行していくものというイメージがあるでしょう。ただしテストに関してはそれがなかなかうまくいかないのです。その原因の1つは開発が進まないと検討できないことが多すぎるということです。例えば仕様書がないのに，テストすべき機能としない機能を検討することは難しいでしょう。ソフトウェアテストの（特にレベルテスト計画）については開発の状況を抑えつつ，同期しながら“育てていく”というつくりかたになります。このあたりは本文でも「ローリングウェーブの計画」を引き合いに出して解説していますので，読み飛ばさないようにしてください。
■マインドマップを書くことで気付きを得られる
本文中ではこの計画の検討をマインドマップを使って実施していますが，途中で気付きを得ていることに注意して下さい。あれ？と思ったときにどう対応すべきか，その一例を示していますので見落としが無いようにすると良いと思います。
■おわりに
今回はテスト計画を取り上げましたが，ひょっとすると「え！そんなことも計画に入れないと行けないの！？」と思った方もいらっしゃるでしょう。念のため，IEEE829のテンプレートは項目が多く重いので活用しようと思ったら河野区の取捨選択をしてもいいと思います。ただし，あまり落としすぎると結局スケジュールだけ計画になってしまうので良くないですね。テンプレートに書かれていることは普段頭の中で決めていることも多いでしょう。ですからそれを文書化するだけなので，実は新たに増える作業ではありません。文書にして他人に見えるようになるとレビューができ，合意もできます。また，自分自身忘れることもありませんね。こういった計画書が整備されていない現場では是非取り組んで欲しいと思います。
