わんくま同盟勉強会のネタにならないかと、昔のデータが残っていないか、漁ってみた。あった、あった。1996 年ぐらいのデータが。それ（テスト仕様書）を眺めながら思ったこと。
「これ、何をテストしているんだっけ？」
ウォーターフォール型で工程を進めているので、要望をまとめて、大まかな仕様を作って、細かい仕様を詰めて、プログラム作って、プログラムを作った人がテスト仕様をまとめて。そしてできあがるのは、「プログラムの正当性を確認するテスト項目」だったりする。
でも、本当にテストしなきゃいけないのは、「仕様通りに作られていることを確認する項目」ではないでしょうか。
それが「良」となることで、仕様のどこが確認できたのかわからない項目。それが「良」となることで、顧客のどの要望が実装されているのかわからない項目。
こう考えると、プログラムより先にテスト項目を作っておくというのも、納得できないでしょうか。
以前のプロジェクトで、プログラミングを行いながら、設計者がテスト項目を作り込んでいくというように運用したことがあります。
仕様書には、「こういう入力を行う」ということが定義されていることは、普通にあります。しかし、その入力に違反した場合、どの様な動作を行うかを厳格に定義していることは、少ないのではないでしょうか。これは、エラーメッセージが、どこに、どんな言葉で表示され、そのあとに入力状態がどうなるのか、ということです。これ、作る人によってバラバラになっていませんか？
テスト項目を作るとき、ここをあわせることを目標にしました。先にエラー動作が定義されているので、設計者があとから「これ、わかりにくくない？」と指摘することを予防できました。結果、テスト項目を作るのを平行で行ったこともあり、短い期間で仕上げることが出来ました。
平行なので、先にプログラムが出来ていることもありました。この部分は「手戻り」となってしまいます。
では、先にテスト項目が出来てしまっていたら？
仕様には、「ユーザの、こういうアクションに対して、こう答える」ということが定義されていると思います。よくよく考えると、「こう答える」と定義したことが出来ているか確認すること。それがテストではないでしょうか。つまり、仕様を決めたときにテストも決まっているのではないでしょうか。
こうして、プログラムからではなく、仕様からテストを作れば、「なにを確認するのかわからないテスト」は、なくなると思いませんか？
また、出荷が目前に迫ってくると、テストをする人を応援で呼ぶことがあると思います。この人たちが、操作に対して疑問を持たずにテストをすることが出来ていますか？
または、「こんなエラー、どうやって出すんだよ？」と思うことはありませんか？
これらも、仕様とテスト項目が結びついていれば、「ユーザの、こういうアクション」、どうやって出すかが明確になっているのではないでしょうか。
仕様と同時にテスト項目を作る。テスト項目の完成を、仕様工程の終わりとする。
面倒なようで、実はすてきな結果が待っているのかもしれません。
とはいえ、現実問題として、「１キロ ステップにつき、テスト項目が何件以上」とか、「１キロ ステップにつき、発見バグ数が何件以上」とか、定義している会社が多いんですけどね。でも、IDE が進化して、自動生成コードが多くなると、「ステップ数」って、何を根拠に求めるんでしょう？
投稿日時 : 2006年9月4日 22:24