はじめに
どうも、雑に扱われた検証環境（修正の確認やテストを行う環境）の怨みです。
検証環境をキレイに使う意識が皆さんの中で育ってくれると嬉しいです。
目次
- 「キレイに使う」とはどういうことか
- 「キレイに使う」と何故品質が向上するのか
- 「キレイな検証環境」を維持する方法
「キレイに使う」とはどういうことか
hogehogeしますよね？
- 修正途中のコードを環境に入れた
- エラーが起きるように設定した
- 既存のデータを変更した
- 新規に設定を追加した
- DBを直接いじった
おそらく日常茶飯事にしていると思います。
これらは各種検証の必須操作でしょう。
こういった操作無しに開発はできません。
hogehogeした後……
- 完成したらそれに上書きするから
- あとでまた検証するから
- 誰も使ってなさそうだし
- 他に影響ないでしょ
- 関連データは範囲外だからいじってない
わかります、非常によくわかります。
「キレイに使う」と何故品質が向上するのか
端的に言えば、技術的負債と似たようなものです。
つまるところ「キレイに使わないと品質が低下」します。
以下、例を挙げていきます。
もちろんこれらの例以外にも品質低下の要因はあります。
エラーを誤検出して調査に時間が使われる
本来であれば処理Xを実行するとX´,Y´,Z´のデータが作成されるが、
自分の検証ではZ´のデータが必要だから、これだけ作って検証しよう
ということで実施してそのまま放置していたら、
他人の検証がエラーとなるケースです。
エラーで引っかかった人は、エラーを回避するための調査や、
回避のために追加でデータを作成するなど、検証に余計なコストがかかります。
また、
「本来Z´のデータのみが作成されることがないから処理Xの不具合ではないか」
と調査をする人が出てくるでしょう。
そしてご存じの通り徒労に終わります。
結果として、検証コストや不要な調査コストが増加します。
本来検出できたエラーを検出できない
このアカウントはずっと昔からデータA,B,Cが紐づいていて、
実行すると処理A´,B´,C´が実行されるから、B´の動作検証に使おう
と思って実行したら、誰かがデータBの紐づけを消していた、という場合があります。
「エラーが出てないので問題ない」と思っていたら実は検証できておらず、
本当はB´の処理でエラーになるケースを見逃します。
結果として、本来検出できた不具合をリリースしてしまいます。
リリースまで行かなくとも、もっと後続のテストで引っかかり、
修正コストが増大することもあります。
リグレッションテストが息絶える
検証でちょっと画面変えた。
既存データちょっと変更した。
ちょっとだけ ちょっと ちょっと
同環境でリグレッションテストを実施している場合、エラーになります。
手動ならまだしも、それが自動テストだったり、
E2Eならばさらにダメージはエグイことになります。
ECサイトなど、厳密な金額計算が行われる場合、
商品データの値段や消費税率、送料設定、ユーザー設定など、
どこかをちょっとでも変更するだけで最終結果が狂います。
セレニウムなどを利用したE2E自動テストでは、
要素の指定方法にもよりますが、
ボタン1つ移動しただけで動かなくなります。
その「ちょっと」を無限に探して行かねばなりません。
それも、毎回違うところが異なっています。
自動テストの実行時間より、動くようにする時間の方がかかってる。
ということもあり得ます。というかありました。
だからこそこの記事をしたためています。
キレイな検証環境を維持する方法
方法や運用での制御は不向き
- 勝手に変更するな
- 変更したら必ず元に戻せ
は現実的でありません。
人は忘れる生き物ですし、楽できるなら楽したいのがエンジニアの性です。
また、新たに人が入ってくることもありますが、
再教育し続けても必ずどこかで変更が発生します。
クラウド環境を検証環境として利用するべし
この一択に収束します。
EC2やOCIなどサービスはいろいろありますが、
以下の通り、キレイな検証環境を恒常的に利用できます。
- 複製が容易
- 個人ごとに環境が利用できるので、他の人の影響を受けません
- 元に戻す必要がない
- そもそも戻さなくてよくなれば、戻し忘れることはありません
- 必ずキレイな初期状態からスタートできる
- 初期状態をリグレッションテストの開始状態と一致させておけば、外部要因による偽陽性を排除できます
追加コストは発生し辛くなり、
それどころか「元に戻すコスト」が不要になります。
そうすると「もしミスってぶっ壊しても安心！」なので、
恐々検証することもなくなります。
さいごに
みなさんが検証環境をキレイに利用することで、
怨みの私が成仏できることを祈っています。