その『回帰テスト』、適切ですか？｜遊んだ分だけエンジニア

最初にお断りしておきます。

9割愚痴です。

はじめに

少し前にも投稿しましたが、現在Javaの案件に参画しています。

とある製品の開発現場なのですが、新しい潮流もありつつやはり既存がモノを言う世界です。

もうちょっと脱線しますが、『回帰テスト』とは別名『リグレッションテスト』とも呼ばれ、既にテストを行ったシステム（あるいは機能）を再度テストすることです。

現場ベースでお話しすると、既に稼働しているシステムに対して修正を加えた際にリリースを行う前にちゃんと修正が適用され、変更箇所以外は修正前と同様に動くことを確認する必要があります。

この時に行われるのが『回帰テスト』です。

初版リリース前に実施したテストに加えて、変更箇所に関しては変更内容に則ったテストケースを作成してテストを行います。

それでは本題に参りましょう。

今回私が直面したのはリリース前の単体テスト完了後の仕様変更でした。

内容としてはSQLのデータ抽出条件を2項目削除するというもの。

その2項目はSQL以外の箇所（要はプログラム）では扱われていない項目だったのですが、『回帰テスト』の項目は修正した箇所も含めて単体試験全量。

正直「マジか」と思いました。（私だけ…？）

プログラムで触っていない項目であれば、データの抽出さえ確認すればいい話ではないでしょうか。

いちおう私も大人の端くれですのでグッとこらえましたが、もし仮に反論していたらどうなっていたでしょうか。

きっと返ってくる答えは「それがルールだから」なのでしょう。

『いい大人』なら黙ってルールに従うのが良いと判断するところですが、腹の虫がおさまらないのでここで発散しておきます。

ルールに従うことが悪いとは言いません。円滑に事を進めるうえでは重要です。

しかし世の中をITでより良くしていこうとするエンジニアとして生きていて、いつまでもルールに縛られるのはいかがなものでしょう。

自分の身の回りをはじめ、システム開発の現場をより良くしようとも思わない人に世の中をより良くなんてできるのでしょうか。

仮に今回の私のケースで変更箇所のみテストしていたらどれだけの手間が削減されたでしょうか。

テストケースの修正はしょうがないとしても、既にクリアしたテストを再度通すのは単なるロスでしかありません。

このロスタイムを次のタスクに回せたら。塵も積もれば山となるとはよく言ったものです。

書いてたら少し落ち着いてきました。

究極的には何が言いたいかというと、システム開発の現場こそもっと臨機応変になった方が良いのではないでしょうか。

「これを書くのが習慣」「これまでこうやってきた」よく聞く言葉です。

でもそれって単に考えることを放棄しているだけでは？

「なぜこんなやり方をしているのか」という問いに対して、まともに回答できるエンジニアはどれだけいるのでしょう。

「どうしたらもっと良くなるのか」を考えているエンジニアはどれだけいるのでしょうか。

自分が先頭に立つときはもっとクリエイティブに進めていきたいと感じさせられた出来事でした。

以上です。