技術とか戦略とか

証券レガシーシステムを8年いじってから転職した普通の文系SEによるブログ。技術のみではなく趣味の戦略考察についても。

テスト環境を使用する時の心構え

始めての現場でテスト環境に触れる時、テスト環境がどのような環境か良く分かっていないと知らず知らずの内にテスト環境を壊してしまいがちです。
このあたりのことは情報処理技術者試験の勉強をしても身に付かなかったりするので、あえて文章にしてみます。
 
【そもそもテスト環境とは】
その名の通りテストをするための環境のことです。
作ったプログラムをいきなり本番運用している環境に上げてしまうと、プログラムのバグでお客様に迷惑をかけてしまうので、事前にテスト環境でテストしてバグを発見・除去してから本番運用に乗せます。
なお、テスト環境の中には、バグの発見率を高めるために本番環境にできる限り構成を近づけた特別な環境が用意されることがあるのですが、そのような環境は「ステージング環境」と呼ばれることが多いです。
 
【テスト環境の一般的な構成】
テスト環境が一つしかないことはごく稀で、通常は複数のテスト環境が用意されています。
サーバやディレクトリ、ユーザ等を分けることで、複数のテスト環境を用意しています。
 
複数のテスト環境を用意する必要がある理由は、用途や案件ごとで別々の環境を用意しないと、自分のテストが他の人のテストに影響を与えてしまうからです。
用途で言うと、各々の開発者が思い思いにテストデータを投入してホワイトボックステストする環境、本番環境と同じデータを投入して業務面の確認を行う環境、日々バッチを回して運用面の確認を行う環境、といった形でテスト環境を分けます。
案件で言うと、リリース時期毎でテスト環境を分けることが多いです。例えば、5月時点の環境と6月時点の環境、といった具合です。
 
【開発者の心構え】
ここで開発者が心がけなければならないのは、誤ったテスト環境でテストしないようにすることです。
例えば、ホワイトボックステスト用のテストデータをバッチを回す用の環境に入れてしまったら、バッチが異常終了し騒ぎになってしまいます。
また、6月にリリースするべきプログラムを5月用の環境に入れてしまったら、5月時点の構成を再現できなくなってしまいます。
(5月リリースするプログラムに潜んでいたバグが6月リリースするプログラムの挙動で隠されてしまう、というようなことも起こり得ます)
 
誤ったテスト環境でテストしないためには、どのようにして環境が切り分けられているのかを知る必要がありますし、自分がどのテスト環境を使用するべきなのかを案件ごとに確認する必要があります。
環境の一覧表があったり使用するべき環境が仕様書等に書かれていたりすれば良いのですが、そのような文書が無いのであれば都度確認した方が無難です。