テスト戦略を仕様書レビューに活かす
2ヶ月も前になるが、テスト業界の著名人である電通大の西先生の講義および演習を受講した。
演習は架空の製品の仕様書に対してテスト戦略を立ててみようというもの。
テスト戦略というと難しそうだが簡単に言ってしまえば、テストカテゴリとして大項目、中項目ぐらいまで考えてみようということ。
まず、個人で考えてみた後、グループ（7名ぐらい）で各自の考えを持ち寄りまとめてみた。
その結果、
- 自分だけでは思いもつかなかった項目があがった。
- 仕様もれが見つかった。
で、その後の西先生の話では
「テスト戦略を立てることが実は有効な仕様書レビューになる。」
とのこと。
これは目からウロコだった。
しかし、実際に演習やってみて上記の結果が出たのだから納得せざるをえない。
今まで仕様書レビューというと一応、識者が参加して、一応、「もれがないか？」なんてふうにやっていたが、「本当にこれで大丈夫？」という思いがあった。
しかし、レビュー＝テスト戦略を立てるとすることで、
- その結果がシステムテストのベースになる。
- とかく行間が多いといわれる要求仕様書の行間がうまる。
- 結果を設計フェーズのインプット材料として使える。
といったメリットが生まれる。
また、複数人でやるのもポイント。
7人は多すぎるが3人ぐらいで1時間ぐらいやれば、かなりの項目があがるし、1人だけではあがらないような項目もあがる。
テスト戦略を立てるという考え方は設計以降にも有効だろう。
基本設計の場合は機能／結合テストを検討すればいいし、詳細設計の場合は単体テストとなる。
ようするに、要求分析をスタートとして、
となるわけだが5-6番目はTDDといえる。
しかし、1-2,3-4番目もTDD的な流れとなる。
DSLがもっと発展してくれば、1-2,3-4番目もまさにTDDの感覚で作業できるのではないだろうか。
例えば、DSLでシステムテストを記述し、それをパスするための基本設計をやはりDSLで記述する。
で、システムテストがパスすることを確認する。
そうなれば、いわゆる上流フェーズできっちり品質を確保することができ、下流フェーズで頑張って辻褄あわせなんて悲惨なことがおきなくなる。
この時に重要となるのがテスト戦略（テスト分析、設計）スキルとなるのではないだろうか。
だって、テストケースが次フェーズのインプットになるわけだから。
現在のTDDだってテストケースがプアだったらうまくいかないし。
