テストフェーズになると、テスト仕様書が欲しくなります。
でも、報告書として提出する必要が無い場合、わざわざ作るのってつらいですよね。
そのためかどうか知りませんが、テスト仕様書を作成せずに漠然とテストしているところを見かけます。

でも、このテストのやり方はまずいと思います。
テストを上手にできる人かそうでない人かで成果が大きく変わってきます。
要するに、属人的です。完全人依存になります。
とはいうものの、提出する必要もなければ、テスト仕様書をざわざわ作成するのもしんどいと思います。

テスト仕様書を作成するだけの時間もコストも無い。
そういう時は、仕様書を最大限に活用します。
多分、皆さんもテスト時に使われれているんじゃないかと思います。

特に有効と感じるのは、開発を担当していなかった人が、外部仕様書や画面仕様書でテストすることです。
画面仕様なんかはわかりやすいと思います。
画面仕様書をテスト仕様書として活用するには、
・操作に対し、どのようになるのが正解なのか？
・操作に対し、内部のふるまいが明確に記述されているか？
・バリデーションが明確か？
など、仕様書の内容もしっかりしたものになり一石二鳥です。

仕様書を活用することで、機能確認に漏れもなくなります。
あらためて、仕様漏れが無いかもチェックできます。
メンバーには、いつもこのやり方を推奨しています。

話は変わりますが、
先日、ある会社様経由で、テストフェーズのプロジェクトへの応援要請の連絡がありました。
そこにメンバーをアサインしてその案件を対応してもらいました。
かなりたくさんのテスト仕様書が準備された、緻密に運営している開発プロジェクトだったのですが…

ある日、メンバーに状況を報告してもらいました。
テスト仕様が難しく、あまり円滑に進んでおらず、かなり苦戦しているとの報告でした。

『やっぱり、あれだけドキュメントがたくさん準備されていて、難易度が高いのかな・・・？』
と想像していたのですが…
で、ある日のこと、
テスト仕様書を拝見したところ、
『うーむ…これはメンバーが苦戦するわ』
と驚愕です。

テスト仕様書の文書が日本語（文法が無茶苦茶というか(^_^;)）になってないのです。
そこに書かれていたのは暗号文書のようなレベル、まともな日本語ではなかったのです。
さらに、明確にどのような結果になるべきという記載も無い。
エスパーでないとわかならいテスト仕様書でした。

そこの開発現場にどっぷりの人だと、これでもわかるのかも知れません。
でも、これではテスト仕様書として全く意味をなしません。
このようなテスト仕様書に時間を割くぐらいなら、テストを意識した仕様書作の方がよっぽど効果的です。

あたりまえのことですが…
読み手を意識したドキュメントの重要性を改めて感じました。