そもそも、テスト環境でテストしたのに、なぜリリース後の本番テストが必要なのでしょうか。
必要だとしたら、必要なテストとは何なのか、具体的に何をすればいいのか。
といった個人的な疑問があり、ここにまとめてみました。
また、必要に応じて情報を追加していきたいと思います。
目的まとめ
| 懸念 | 背景/例 | 軽減策 | リリース後のテスト概要 |
|---|---|---|---|
| 本番のみに存在するエッジデータによる不具合未検出 | 本番環境とテスト環境では、データの数や性質が異なる場合がある。例) 加筆中.. | 1.テスト環境での適切なデータ作成 2.コンバージョンデータのモニタリング 3.露出を絞ったA/Bテスト(1%->5%->10%など) 3.リリース後のテスト |
そもそも想定外なので事前に検討はつかない |
| デプロイメントの失敗 | 例:ミドルウェア設定ミス、 DB更新ミス、デプロイの順序が守られていない、ライブラリなどの依存関係が正しくない、古いバージョンのソースコードをデプロイすることによるデグレードなど。 |
1.デプロイの自動化 2.デプロイ手順のレビュー 3.デプロイのリハーサル 4.ペアデプロイメント 5.リリース後のテスト |
1.新機能 2.主な既存機能（高利用率のもの） 3.主な既存機能（高ビジネスインパクトのあるもの） 4.テスト環境で発見されたクリティカルバグを検出するテスト。 |
| 内部影響範囲調査の失敗 | 影響を受けるソースコードが適切に特定されなかった場合 例：変更したソースコードを使っている未テストな機能あった、リリース前のデータ移行が必要を見落とした、など） |
1.正しい影響範囲調査 2.テスト環境の回帰テスト 3.リリース後のテスト |
1.主な既存機能（高利用率のもの） 2.主な既存機能（高ビジネスインパクトのあるもの） |
| 外部影響範囲調査の失敗 | 例: データやアーキテクチャを共有するクライアントサービス/サブシステムがあったのを見落としたなど | 1.他のサービスやシステムとの適切なテスト 2.リリース後のテスト |
1.クライアント/サービスの自システム主要関連機能 |
| テスト環境でテスト不可能な領域の不具合未検出 | 例: 本番環境しか用意されていないAPIの関連機能、テスト環境で未実装の機能 | 1.適切なテスト環境の整備 2.リリース後のテスト |
1.その領域のみに絞ったリリース後のテスト |
リスクまとめ
| 懸念 | 具体例 | 軽減策 |
|---|---|---|
| 意図しないコンバージョン(購入、予約など) | 本番稼働しているお店の商品を購入してしまう | 1.本番テスト店舗を作る 2.データのクリーンアップ |
| 意図しない副作用(閲覧履歴が残るなど) | テストアカウントで足跡を残してしまう(例: LinkedInなどの足跡機能があるSNSの場合) | 1.特殊なテストアカウントを作り、このアカウントでは副作用が発生しないようにする 2.万が一残ってしまった場合データのクリーンアップ方法の確立 |
| KPIのノイズ | テストにより売上増に見えてしまう | 1.本番テスト店舗を作る 2.データのクリーンアップ |
| ログのノイズ | ユーザのアクションログにノイズが入る | 1.リリース後のテストでログを吐かないようにする |
| テストデータの本番露出によるユーザ体験の低下 | テストデータが本番データに混ざり込む | 1.テストデータが検索等通常動作でユーザの目に触れないようにする 2.検索エンジンのクロールを避ける |