おの＠Wisdomです。
> ひがです。
>
> > 自社内開発＆クライアントがエンドユーザーのプロジェクトであれば
> > ドキュメント無しで大丈夫なのですが、下請け仕事だったりすると納
> > 品物に「単体テスト仕様書」が入ってくると思います。
> > まさか「単体テスト仕様はソースを見て下されば分かります」と言う
> > わけにも行きませんし・・・。
> >
> 単体テスト仕様書は、納品しない予定です。
> 機能テスト仕様書と結果があれば十分ではないでしょうか。
個人的には同意します。
逆に、なぜ単体テスト仕様書のようなものが要求されるかを考えると、
・社内規定でそうなってる
・なんとなく安心
・製造会社がちゃんとテストしてるか信用できない
・メンテナンスのため、クリアしているテスト項目を知りたい
のようになると思います。
問題は3番目で、納品後に機能追加などでその部品に変更があったと
します。その時には製造した会社の人たちはいません。変更の影響
によるテスト項目の追加や変更をするわけですが、既にどのような
テスト項目があるのかを知りたいわけです。この項目を確認するコ
ストを下げるために単体テスト仕様書を使う、と・・・。
つまり、納品後の変更のための保険という感じですね（その割には
保険料が高すぎる気がしますが）。
> > また、単体テスト項目の妥当性はどのように判断しますか？
> > 文書化されていないと「単体テスト仕様書レビュー」を行うのも困難
> > なように思います。
> >
> すべてをレビューするのは無理なので、
> サンプリングして、単体テストケースのソースコードレビューを
> 行う予定です。
このソースコードによるテスト項目レビューの方法は、私も使わせて
もらおうと思います。
*--------------------------*
株式会社 Wisdom
小野 博嗣
mail : ono@....jp
*--------------------------*