受入テスト

XP

基本的には顧客が主体となる受入チームのタスク。
最近、受入テストが一番の肝だと思うようになってきた。

JavaのWebアプリ作成プロジェクトにおいて、受入テストをちゃんと実施するための作戦を考え中。WebStoryUnitというものが便利そうなので使ってみようと思う。

1.ストーリーのシナリオから、以下のものを作成
　前提条件　　→テストデータ
　内容・結果　→HTML(モック)
　Ex.ストーリー概要が
　　「顧客番号入力して、表示ボタンを押すと顧客情報画面が表示される。」
　　といったような場合、
　　テストデータは
　　　顧客、ユーザー(ログイン用)、必要であれば各種マスタ、トランザクション
　　HTMLは
　　　顧客番号入力画面のHTML
　　　顧客情報表示画面のHTMLの2つ
　　を用意する。
　　※モックHTMLは仕様確認にもなる。
　
2.WebStoryUnitを使用して、受入テストコードを作成
　2-1.シナリオに従ったHTTPリクエストを受けて、モックHTMLをレスポンスとして
　　　返すようなモックアプリケーションの仕掛けを作成。
　　　そのアプリケーションで、WebStoryUnitを使ってテストコードを生成する。
　　
　2-2.ブラウザから、モックアプリケーションに対してシナリオに従い操作を行う。
　　　→テストコードが生成される。
　
　2-3.生成したテストコードに以下を補完(拡張？仕掛けを考える)
　　　・テストデータ挿入ロジック
　　　・生成できないテストロジック

3.テスト実施
　3-1.モックアプリケーションに対して、テスト実施。
　　　(データの挿入は行わなくていい？？？)
　　　All Greenになることを確認。
　
　3-2.本番アプリに対して、テスト実施。
　　　(モックアプリケーション用のURLを本番用にうまく変換する仕掛けが必要？)
　　　正しく実装されているところは、Green。


とはいえ疑問：
　シナリオの前提のテストデータに対する記述が難しい。
　└あいまいな日本語から、テストデータまで持っていくところにギャップがでそう？
　　テストデータの妥当性は？
　
　シナリオのの前提からデータ作成するところは顧客では無理。
　└システム屋側でやるにしても結構大変？
　　仕様変更などでDBの変更は結構あると思うし。
　　受入チーム、開発チーム両方に精通している人間がやらないと回らない。
　　あとは、DB変更に伴って、既存テストデータをさくっとまとめて変更する仕掛けが必要
　
　シナリオをきっちり網羅することができるのか？
　└でもやらないと。
　
　自動テストができないところに対して
　└たぶん出てくる。
　　うまく管理していかないと。
　
　モックHTMLを全画面作ることができるのか？
　└でも、システムテスト仕様をつくってレビューして、イテレーション毎に実施
　　するのとどっちがどのくらい大変なのか。
　　これもやらなければ。
　　ほかにうまい方法があるだろうか。

まだまだ試行錯誤しよっと。