読者です 読者をやめる 読者になる 読者になる

mokky14's IT diary

IT関係の仕事メモ、勉強会の感想など書いてます。

ソフトウェアテスト勉強会~テスタビリティの高い仕様書を書こう!~に行って来ました

テスト 勉強会

今回の勉強会は、「テスタビリティの高い機能設計書」についての勉強会。

勉強会の内容は以下ブログで。
http://ameblo.jp/sendai-test/entry-11552931068.html

機能設計書作るときは「実装出来るか?」という目では見てるけど、「テスト出来るか?」という目ではあまり見てなかったので、今回のテーマにはすごく興味があった。
ただ、今回はちょっと消化不良かも知れない。

設計書から曖昧な記述をなくすとかは当然としても、設計書にどこまで書くかは、線引きがすごく難しいところだと思ってる。
内容が曖昧すぎて、テスト以前に実装出来ないんですが? というドキュメントも見たことあるけど、逆に、ソースレベルの細かいところまで詳細に書いてたり、異常パターンまで全て網羅するように書いた結果、何が正常処理なのか分かりません! という状態になったドキュメントも見たことある。
そういう設計書だと、テストはし易いのかもしれないけど、実装はし辛いし、ドメインもぼやけてしまうので、設計書として良いものだとは思わない。
なので、設計書としては、曖昧なところはなくしつつも、書き過ぎてないことも必要だと思ってる。
どこまで書くかも個人の感覚に拠るところが大きいので、統一した基準を決めるのも難しいし、ドキュメント見る人によってもレベルを変える必要あるしで、そのバランスはいつも悩む所。

簡単に答えが見つかるようなものでもないので、とりあえず、次に設計書書くときに「テスト出来るか?」という目で見てみて、また考えてみよう。


他に勉強会の内容で気になったところは、仕様書を「能動態で書く」こと。これは完全同意。
感覚的に、受動態で書かれてる仕様書って、言われたように作りましたって感じで、自分の頭でモノ考えないで書いてるなーと思うことが多い気がする。
個人的感覚として、能動態で書くようにすると、書く内容に対する意識が変わるので、自分はかなり意識して能動態を使うようにしてる。

あと、デシジョンテーブルは今まで設計書で使ったことなかったけど、使えそうなので覚えておこう。


次回はC言語読む勉強会だそうなので、C言語メインで開発してる身としてはぜひ参加しなくては。