リリース直後のテストの目的と背景

そもそも、テスト環境でテストしたのに、なぜリリース後の本番テストが必要なのでしょうか。
必要だとしたら、必要なテストとは何なのか、具体的に何をすればいいのか。
といった個人的な疑問があり、ここにまとめてみました。
また、必要に応じて情報を追加していきたいと思います。

# 目的まとめ

| 懸念                                                    | 背景/例                                                                                                                                                                                                          | 軽減策                                                                                              | リリース後のテスト概要                                                                                                                             |
| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 本番のみに存在するエッジデータによる不具合未検出 | 本番環境とテスト環境では、データの数や性質が異なる場合がある。例) 加筆中..                                                                                                                                                 | 1.テスト環境での適切なデータ作成<br>2.コンバージョンデータのモニタリング<br>3.露出を絞ったA/Bテスト(1%->5%->10%など)<br>3.**リリース後のテスト**                                               | そもそも想定外なので事前に検討はつかない                                                                                                                                     |
   | デプロイメントの失敗                                         |  例:ミドルウェア設定ミス、<br>DB更新ミス、デプロイの順序が守られていない、ライブラリなどの依存関係が正しくない、古いバージョンのソースコードをデプロイすることによるデグレードなど。                              | 1.デプロイの自動化<br>2.デプロイ手順のレビュー<br>3.デプロイのリハーサル<br>4.ペアデプロイメント<br>5.**リリース後のテスト** | 1.新機能<br>2.主な既存機能（高利用率のもの）<br>3.主な既存機能（高ビジネスインパクトのあるもの）<br>4.テスト環境で発見されたクリティカルバグを検出するテスト。 |
| 内部影響範囲調査の失敗                           | 影響を受けるソースコードが適切に特定されなかった場合<br>例：変更したソースコードを使っている未テストな機能あった、リリース前のデータ移行が必要を見落とした、など）                                |1.正しい影響範囲調査<br>2.テスト環境の回帰テスト<br>3.**リリース後のテスト**                                                                       | 1.主な既存機能（高利用率のもの）<br>2.主な既存機能（高ビジネスインパクトのあるもの）                                                                                                                                     |
| **外部影響範囲調査の失敗**                              | 例: データやアーキテクチャを共有するクライアントサービス/サブシステムがあったのを見落としたなど | 1.他のサービスやシステムとの適切なテスト<br>2.**リリース後のテスト**                                             | 1.クライアント/サービスの自システム主要関連機能  |
| **テスト環境でテスト不可能な領域の不具合未検出**                             | 例: 本番環境しか用意されていないAPIの関連機能、テスト環境で未実装の機能 | 1.適切なテスト環境の整備<br>2.**リリース後のテスト**                                             | 1.その領域のみに絞った**リリース後のテスト**  |

# リスクまとめ

| 懸念                    | 具体例                   | 軽減策                      |
| --------------------- | --------------------- | ------------------------ |
| 意図しないコンバージョン(購入、予約など) | 本番稼働しているお店の商品を購入してしまう | 1.本番テスト店舗を作る<br>  2.データのクリーンアップ       |
| 意図しない副作用(閲覧履歴が残るなど) | テストアカウントで足跡を残してしまう(例: LinkedInなどの足跡機能があるSNSの場合) | 1.特殊なテストアカウントを作り、このアカウントでは副作用が発生しないようにする<br>  2.万が一残ってしまった場合データのクリーンアップ方法の確立       |
| KPIのノイズ               | テストにより売上増に見えてしまう      | 1.本番テスト店舗を作る<br> 2.データのクリーンアップ        |
| ログのノイズ                | ユーザのアクションログにノイズが入る    | 1.リリース後のテストでログを吐かないようにする |
| テストデータの本番露出によるユーザ体験の低下               |テストデータが本番データに混ざり込む    | 1.テストデータが検索等通常動作でユーザの目に触れないようにする<br>2.検索エンジンのクロールを避ける |

# 参考文献
- https://www.softwaretestinghelp.com/post-release-testing/
- https://www.testim.io/blog/testing-in-production-modern-qa-strategy/