本番環境でのテスト

本番相当のステージング環境(またはプレ本番環境と呼ぶこともある)を作ってテストするのは、相応のコストがかかるわりに、結局検出できない問題も多く存在するので、本番環境でテストしちまえと言うアイデア。

フィーチャーフラグのようなContinuous Deployment用の仕組みと合わせて、ようやく費用対効果が見合うとされる (『Continuous Deployment』)。

本番環境でのテストのパターン

データの分離

注文など実際にトランザクションをしてしまうと、実ユーザのデータと混ざってしまうのでそれと区別する手段が必要になる。

本番テスト専用ユーザ

テスト専用ユーザを作っておき、そのユーザでのトランザクションは、バックエンドの処理で分岐してCommitではなくRollbackするようにする。

トランザクションデータの削除

あるキーワードを含んだデータを定期的に消す仕組みを作っておき、コミットされてしまったデータが後続の業務(発送など)に回らないようにする。

ログの削除

どの手段をとっても、テストした履歴がログに残ることまでは避けられないことが多い。効果測定などのノイズになるのが問題視される場合は、特定のユーザ、キーワードを含むデータを事前に削除するコマンドを作っておく。

エラーの再現

特定の顧客に成り変わる

ユーザIDや会社IDを自由に変更できる特殊なユーザを作り、問い合わせのあったユーザ、会社になり変わって、不具合を再現させ原因を探る。

※ 危険なのでやらない方が良い

特定のエラーを発生させるワード

異常系の検証のため、特定のクレジットカード番号などを入力すると、必ずオーソリ失敗するなどの仕掛けを作っておく。(実在しないカード番号は簡単に生成できるが、通常バリデーションでエラーになってしまうので、そこにも分岐が必要になる…)