平鍋です．
On Mon, 28 May 2001 08:55:56 +0900,
"Tuyoshi Ushio" <t-ushio@....com> said:
> ■総合テストに関して
> ウォータフォール型で実践するときの総合テスト
> の話になり、他のメンバーから、以下の質問が
> でて、
> Q１．各ストーリ毎の機能テストはわかったが、
> 各ストーリを複数動かさないと発生しない
> ロックなどの問題の発見はどうするのか？
> Q２．従来の総合テストのような実データの入った
> テストはどうするのか？
難しいですね．平鍋ならこんな風に答えて見ます．
A1. 機能テスト(受け入れテスト)は顧客が定義します．顧客は自分
が欲しいと思ったものが手に入るはずだ，という仮定をしないもの
です．つまり，欲しいと思ったら，それを保証できるテストを用意
します．XPでは，仕様は，「ストーリーカード」と「受け入れテス
ト」の2つで定義されます．よって，顧客が複数のテストを組み合
わせたテストが必要だと考えれば，そのテストを受け入れテストと
して定義します．
まあ，上は建前で，実際そのようなテストの必要性は開発側が気付
く場合が多いようです．また，顧客がテストを定義する，とはいっ
ても，日本での実践の場合はやはり開発側がリードしないと難しい
ケースも多いでしょう．
基本的に，顧客と開発はチームなのですから，誰かがそれが欲しい
と気付いたら，それはミーティングに持ち出さねばならず，そして
全員で解決を考えて行くのが実際的な気がします．
> A2．XPのイテレーションの終わりには物件をリリースする
> が、それは本番リリースである。
> ＃つまり、本番データがある状態と思われる。
は私の考えと同じです．「本番」という 5m のバーを一気に越える
のでなく，1m, 2m, 3m と越えて行きます．しかも，越えるのが開
発側だけでなく顧客からも見えることが必要です．これは1つの
「期待管理手法」と言えます．
> と答えたのですが、PJがスタートした当初から本番データ
> が開発環境に入っていることは今まで殆ど無かったですし、
> 実際に本番データをすべて想定する機能テストを書かないと
> いけないのかな？とふと疑問に思いました。
リリースの計画を顧客と共に立て，各リリースでは，顧客に「ビジ
ネス価値」を提供するようにします．少しでも使ってもらえる部分
はないか，と考えます．
以上