作成後、誰も見なくなった廃墟みたいなテスト計画書ワースト3

qiita.com

テスト計画について何人かが書かれていたので、私はテスト計画の負の側面を書いていこうと思います。

テスト計画書をなぜ書くのか

なぜテスト計画は必要なのでしょうか？
やらなくて済むならそれに越したことはないのではないでしょうか？
計画なんてどうせ立てっぱなしで、あとから見返すことなんてないのではないでしょうか？

私は小学生の頃に夏休みの宿題の計画を立てましたが、僕がズルズルと先延ばしにするせいで結局29日から31日までに40ページずつ進めるとかいうカスみたいな計画に変更されてしまいました。 これは極端な例ですが、仕事でもこういうスケジューリングってよくありますよね？「リスケお願いします」「リスケで」「リスケ」「リスｋ」…

破綻することが前提になっているような計画をわざわざその都度更新していくのは、更新コストに対して得られるものが少なすぎますよね？ 更新する手間ばかりかかってメリットがないような計画書であれば、書かない方が合理的なのではないでしょうか？

どんなテスト計画書なら必要とされるのか

どうしたら必要とされるのか？というと、答えはシンプルです。
必要な情報が書いてあったらみんな読むんです。

例えば。
いつやるの？もだし、誰がやるの？もだし。
テストの手順書はどこにあるの？もだし。

要するに僕はテスト計画書のことをポータルサイト的なものだととらえていて、
むしろそういう使われ方をされないのであればただの自己満足であって書く理由って別にないんだよなと思っています。

書くのが目的じゃないんですよ。誰かに言われたから書くとか、そういうのマジでよくないと思います。

テスト計画に意味があるのではない、テスト計画をもとに議論が生まれることに意味がある

僕はメンバーにテスト計画書を読んでもらうこと、読んで考えてもらうこと、読んで議論されることにこそ意味があると思っています。
（参考：なんかデカめのソフトウェアテストの本）

繰り返しになりますが、ドキュメントそのものに意味があるわけではないです。ドキュメントはドキュメントでしかない。
だから、それを使って何をするのか？ということだと思っています。

偉そうに言いやがって

じゃあそんなあなたは何を計画書に書いているんですか？と聞かれると思いますので
こないだ私がテスト計画書を作った時に書いたことをここに紹介します。

• 要件と背景
• テストの目的
• テスト対象
• 具体的なテストの内容
• テストの完了基準
• テストケースの置き場所
• テスト実行の準備に関する情報
• テストの工数見積り
• 具体的なスケジュール
• その他確認事項

なんとなくわかるかもしれませんが、これらはどれも「誰かが書いてほしいと言っていたこと」「私がどこかに書いてあったら助かるもの」「書き残しておくと誰かが見れて便利なこと」です。
繰り返しになりますが、自己満足で書くのはやめましょう。
明確な需要のあるドキュメントにするのが、テスト計画書作成のポイントです。

作成後、誰も見なくなった廃墟みたいなテスト計画書ワースト3

それでは本題の、作ったはいいものの誰も見なくなった廃墟みたいなテスト計画書のワースト3を発表していこうと思います。

第3位　作成者のメモになっていて解読不能

例えばこういうものですね。

v4.0

DBのテストする

期間短め

不足したテストないか見直す

このレベルだともはや文章として成り立っておらず、他の人はおろか書いた本人でさえも「このメモは何…？」となるのが必至です。
せめて何のことを指しているのかくらいは分かる文章にしましょう。

第2位　ISO29119などに完全準拠していて超長い

ISO_IEC_IEEE_29119に準拠するなら、例えば以下のような項目を書いていくことになります。

• リスク分析
• テストアプローチ
• テストレベル
• テストタイプ
• テスト設計技法
• テスト時のプラクティス
• 静的テスト
  ...

いや、まあ確かにこれらは重要です。
しかし、必ずこれらがフルで必要になるでしょうか？そうとも限らないと思います。
案件、プロダクト、プロジェクトの状況に応じて、読み替えたり飛ばしたり、ポイントを絞ったりしないと散漫でとても長い文書になり、とてもじゃないですがみんなで読もうとかいう感じにならないです。

第1位　間違った情報が載っている

これは最悪です。テスト計画書を読んで仕事をしようとしたら「ああ、それに書いてるの古いから間違ってるよ」と言われ。ええ？と思い、もう二度とその文書を開くことはないでしょう。

書いてあることが正しいというのは読まれるうえでの最低条件です。それなのになぜ世の中には間違った情報が載っているテスト計画書が存在するのでしょうか？
仮説としてあるのは「更新コストが高すぎる」ということでしょう。たとえばスケジュールなんてものはすぐに変わります。なので、Jiraで管理しているならそこにリンクさせておけばいいです（とりあえず文書はリンクさせておくと何かと便利）

ソフトウェア開発にも近いですが、頻繁に変わるものは更新の対象から外れるようにして、ある程度決まったことが計画書に書かれるよううまく構成を分離できると、この辺りの更新コストを減らすことができます。

ただ、逆もよく聞きますよね。そう、「テスト計画書は更新前提で書こう！」というものです。これと矛盾しているように聞こえるかもしれません。
でも矛盾しないんです。先に述べたようなことはそもそも計画書に「書いてはいけないもの」なのであって、それは分離しなければならない。

じゃあ何を書くかというと、私は「意思決定」を書くべきだと思っています。
私たちは、一体何のために、何のテストを、どうやって実施するつもりなのか。
これこそがテスト計画書に書いてあるべきことであり、これが変わったら必ず皆で議論をする必要がある。

だからテスト計画書を書くのです。そして、みんなでこれをみて議論するのです。

おわりに

いかがだったでしょうか。
テスト計画は大切なテストプロセスのひとつですが、なるべく効果的な形で実施できるといいと思います。
何かの参考になりましたら幸いです。