やぼったい開発 > コラム > ウォータフォールモデルではテストファーストは当たり前?

コラム

ウォータフォールモデルではテストファーストは当たり前?


エクストリーム・プログラミング (XP) で テストファーストが特徴になっていますが、ウォータフォールモデルも当たり前のように、コードの前にテストを書く事が可能です。



なぜかを説明する前に、ウォータフォールモデルをおさらいすると

上記の図のように、基本設計書を保証するテスト仕様書、機能設計を保証するテスト仕様書があり、詳細設計、プログラム設計を保証する単体試験とそれぞれの段階があります。

プログラムのコーディングはCD工程で行います。

つまり作業時期としてBDの後に、いつITの試験書を作成しても何ら問題ないわけです(下の表)。同様にUTをCDの前に作成することに何ら問題ありません。@

時間
BD FD DD/PD CD
IT FT UT

※1 「BDが終わればFD,ITの作業が開始できる」という意味

もうひとつテストファーストに対立する意見として、「DDに対してUTを行わずに、ソースに対してUTは行わければならない」と主張する人もいるかと思いますが、CD工程では設計をしません。

DD/PDで行います。CDに対しての保証は誤記や漏れ対応になるので、レビューやコンパイラなどでカバーします。

DD/PDレベルの設計に対して、UTで保証します(DD/PD工程がなく、CD工程で設計しても、その設計部分までUTでカバーするところは同じ)。

つまり、CDの設計部分に対するUTは、すでにCD工程の前に可能なのです。A

つまり以上のように、UT試験書を CDの前に作成しても問題ありませんし、UTの前にCDが必要となるわけでもありません(実際テストファーストを主張している人は、そこのところがわかっていると思います)。


つまり、コーディングの前にUT試験仕様書を作成することに対して、ウォータフォールモデルでは制約もありませんので、ウォータフォールモデルにおいて、そのテストファーストという開発手法が不可能と言うことにもなりません。


とりたててテストファーストがウォータフォールモデルではできなかった事ではないんです。



補足

その他、コードに対して直接試験仕様書を書く弊害として、ソース上に不足している処理を見つけられないためテストケースの漏れ発生してしまう問題があります。それが、粒度的に機能試験(FT)でみつかりずらい物である場合、その後の試験でも見つからず最悪リリースしてしまう可能性があります(※2)。


CDに対して(粒度の小さいDD/PDレベルの問題点)は、やはりUTで見つける必要があり、そのためには、UT試験仕様書はソースのみにフォーカスを当てるだけでなく、設計部分にもフォーカスを当て、処理的に網羅された試験書を作る必要があるわけです。


CDからUTを作ること自体は本質が理解されていれば問題ないですが、DD/PD工程がない時、新規メンバーにCD工程の意図をくんだUT試験項目書を作成させることは負担が大きいです。



※2 機能的にテストされないということは、機能的に影響ないこともあり得るので、なかなか表面化しづらい面もある。



類似コンテンツ

ウォータフォールモデルではテストファーストは当たり前?

なぜ自動化するのか?単体テスト自動化のメリットとデメリット

JUnitの役割はどこまで? 試験工程内で 単体テストのできることとできないこと

早わかり Junit 30分講座

単体試験と機能試験の違い


<< やぼったい開発 へ戻る。



http://www2.ocn.ne.jp/~cheerful/develop/
since (05/03/2006)
http://www2.ocn.ne.jp/~cheerful/develop/