【詳細設計書】参照すべきドキュメントが多すぎる問題

今のプロジェクトでテスト仕様書を作成し続けてしばらく経つ。
基本的に、テスト仕様書は詳細設計書に書かれている仕様をベースに作成しているので、
そこに記述がないものについては、「そういう仕様ではない」ということでテスト仕様書には記述しない。

たとえば各項目の活性非活性に関して、

Aというチェックボックスにチェックが入っている状態だと、Bというボタンは押せない
Cというラジオボタンにチェックが入っている状態だと、Dというテキストボックスは入力不可

などという部分は設計書に記載があればテスト仕様書に挙げられるが、なければ当然スルーされる。で、実際にテスト消化の際に、
「ここにチェックが入ってると、このボタンが押せません」とか
「ここのラジオボタンにチェックを入れていると、このテキストボックスには入力できません」とか上がってくる。

実際のアプリの挙動と仕様書を見比べて、アプリ側の挙動を「正」とするかどうかは微妙なので
一応確認するのだが、大体仕様書に記述が足りていないことが原因で、結局テスト仕様書を修正することになる。
(というか、制御に関する網羅的な表もなくて作ってる側は混乱せんのか）

これくらいならアプリと仕様書を見比べるだけで済むのでそこまで苦労はないのだけど、
実際は仕様変更という名のもとに、仕様書とは別のファイルが存在し、そちらも確認しなければいけないので手間が倍になっている。

今年春の段階で凍結した仕様書と
設計バグ等が見つかったことにより、ページ単位で修正の入ったドキュメント

これらが別々のSubversionに置いてある。
現状のアプリは「春までに凍結された仕様書通りに作られている部分」と
「修正の入ったドキュメントで作り直された部分」が存在していて
テストを実施した際にテスト仕様書の期待値（確認項目）と差異が出ているのはどちらのドキュメントに対応しているのか探さなくていけない。

この、修正の入ったドキュメントというのも、「5/10時点」で見つかったバグ対応の修正と「6/15時点」で見つかったバグ対応の修正では
ドキュメントが別なので、それぞれ見比べなくてはいけない。

・・・なぜ仕様書にそのまま修正を反映してくれないのだろうか...

実装する人からすれば、修正箇所のみをピックアップしたようなドキュメントなので
どこをどう修正するかわかりやすい、ということなのかもしれないが...

しばらくテスト仕様書の準備作業は続くし、今後はテスト結果のチェックも必要になってくるわけだけど
バグ修正も延々続いていて、そのたびに仕様変更ということでドキュメントが増えていくのだろう。
頭痛い。

見るべきドキュメントはなるべく少なくすべきなんじゃなかろうか
おそらくリリース後にドキュメントの整理というタイミングで今あるバラバラのドキュメントと仕様書を統合していくのだろうけど。
（本来は統合したいのだけど、修正が多すぎて中途半端な状態で設計書として統合出来ないんじゃないかと思う）

工数、という部分を重視しすぎておかしなことになっている気がする。
優先すべき作業を置いておいて、とりあえず当初のスケジュールを尊守すると言う形になっているように見える。

実際、テストの工数ってプロジェクトにおいてもわりと割かれているはずなんだけど
こういう無駄な作業のおかげで手間ばかりかかっている。そりゃ、スケジュール通りに進まんわ。