ソフトウェアの品質を上げるためにはテスト仕様書の品質が大事です。糞みたいなテスト仕様書だと、多くの不具合を見逃してユーザーに供給されてしまうことになります。どんな天才プログラマーを集めても、テストが糞だと完成品も糞になってしまいます。というわけで、今回は職場で遭遇した悲しいテスト仕様書たちを集めてみました。多くの人が触ったことがあるであろうWindowsのペイントソフトのテスト仕様書を作る場合で考えてみます。
悲しくて残念なテストたち
人によってテスト結果が変わってしまう
基本中の基本です。上図のテスト仕様書はNo.2がダメですね。この仕様書だと人によって結果が変わってしまいます。鉛筆で1本の線を描くだけの人もいれば、たくさん線を書いて塗りつぶす人もいます。また、色を変えて赤で描く人もいれば、太い線を選択して線を描く人もいます。もし、黄色を選択したときに問題が発生する場合、上図のテストではOKになる人とNGになる人がいます。テスターが黄色で線を描くかどうかで品質の評価が変わってしまうのです。テスト仕様書は誰がテストを実施しても同じ結果になることはとても大事です。
結果が正しいかどうかしばらく分からない
ストレスです。No.2もNo.3もNo.4を実施しないと評価できません。これはNo.2とNo.3の結果の欄の記入が間違っています。その手順を実施した場合の結果を書かなければいけません。強いて言えば、ここに書いてある結果はNo.4に書くべきでしょう。しかもこれ、よく見るとNo.2で背景を青にして、その上に青で円を描いています。つまり、保存された画像は真っ青で円なんて見えません。これはテスト設計を明らかにミスしていますね。
何が正常なのかが分からない
テスト仕様書は、そのソフトウェアのことを何も知らない人でもテストができるように書かなければいけません。上図のテスト結果は意外とありがちかもしれませんが、これではペイントソフトを知らない人はテストできません。何が正しい動作なのか分からないからです。正常に円が描かれるといっても、何がどうなれば正常なのでしょうか？ペイントソフトならドラッグアンドドロップで円を描ければOKです。しかし、別の画像作成ソフトならどうでしょうか？スタンプのようにワンクリックで円が描かれるべきかもしれませんし、ドラッグアンドロップで真円（楕円じゃないもの）だけ描かれるべきなのかもしれません。このため、結果の欄には具体的に何がどうなれば良いのかを明記しないといけないのです。
そもそも結果が有り得ないことになっている
No.3でNo.2の結果をリセットしているのに、No.5の確認ではNo.2の結果が残っていることになっています。単純なミスなんですが、他人にテストしてもらうので大変失礼です。テストを書きっぱなしで全く検証してないんだなと思われてしまいます。テスターの人は、「俺はソフトウェアをテストしているのであって、お前のテスト仕様書をテストしているわけじゃないんだよ」と思うでしょう。テストを書く人とテストをやる人は違う人が良いとは言いますが、書く人は書きっぱなしにならないように気を付けないといけないですね。
…とまあ、今日も仕事での愚痴を書いてしまいました。とにかくテスト仕様書の品質も大事なんですよ！
