まず UI と業務ロジックをきちんと分離していない事が、そもそも回帰テスト(UI テスト)を人力で行わなければならない元凶です。
UI と業務ロジックを分離して、UI は操作コマンドを作るだけにするのです。
UI → コマンド → 業務ロジック解析エンジン → 業務ロジック
業務ロジック側にコマンドを解析するエンジンを組み込み、業務ロジックはコマンドによって実行されるようにします。このようにすれば、UI で作られたコマンドは xml や json ファイルに保存しておくようにすれば、UI をいちいち人間で操作する必要は無くなり、何度も同じテストがバッチ処理で出来るようになるはずです。
バッチでテストが出来るようになれば、夜間に Jenkins でテストを実施することも出来るようになります。つまり人手で毎回UIを使ってテストする必要はありません。テストの自動化の仕組みが出来てはじめてその先にアジャイル開発などがあるわけです。
そういうテスティングフレームワークを作れば良いと思うのです。無ければ作れば良いのです。良い物が出来たなら、いろいろなプロジェクトで使うことが出来るでしょう。UIの共通部品化なども出来るかも知れません。さらに素晴らしいものだとすれば、そのテスティングフレームワークを外販も出来る事でしょう。そうすればお金を生み出せます。テスティングフレームワーク記述言語とか作れば良いのです。ISO とかで標準化すべきです。
回帰テストを人手でやりテストに１人月もかかっている状況で、どうしてアジャイル開発が出来ると言うのでしょうか。「アジャイル開発」という言葉ばかりが先行している気がしますが、テスト自動化のその先に「アジャイル開発」がある事を認識すべきではないでしょうか。テストなんて金にならないと言う人が多いと思いますが、「テスティングフレームワーク」も真剣に作ればお金になりますよ？きっと。そういうフレームワークの開発は真剣に取り組む価値があると思いますけどね。未だにそういうプロジェクトはお目にかかった事がない。いつまでも回帰テストを人力なんかでやってるから「IT土方」とか揶揄されてしまうのですよ。残業時間が減らないのですよ！面倒くさい事は全部機械にやらせるべき。エンジニアに必須の最重要な資質は「建設的面倒くさがり*1」です。
回帰テストがあまりにもだるいので、仕事せずにこんなもん書いてしまったｗ
だっるいけど回帰テストの続きやるか・・・
*1:はぁー作業めんどくせー。そうだプログラム書こう！
