how perform post release testing effectively
QAとしてキャリアをスタートしたとき、私はSaaSとして製品を提供している会社で働いていました。プロダクションリリースは重要であり、ライブクライアントの機能に影響を与える可能性がありました。
クライアントベースが拡大するにつれて、リスクを管理し、ライブクライアントへのリリースの影響を最小限に抑えるために、QAチームは採用しました リリース後のテストの実践。
これは私にとってまったく新しいことであり、私は私の心の中に非常に多くの質問と疑問を持っていました：
- リリース後のテストとは何ですか？
- すべてを適切にテストしましたが、リリース後のテストを行う必要があるのはなぜですか？
- すべてをもう一度テストしますか？リリース後の検証では正確に何をしますか？
- 問題を見つけたらどうなりますか？等。
最初の数回のプロダクションリリースですべての答えが見つかったことを認めてうれしく思います。
ここで私はその知識を皆さんと共有しています。答えを見つけた方法を示すために、質問と回答の形式で記事を書くことにしました。
学習内容：
- ポストプロダクションリリース検証とは何ですか？
- リリース後の検証フェーズにはどのようなタスクとアクティビティが含まれていますか？
- すべてをもう一度テストする必要がありますか？
- ポストプロダクションリリースの検証戦略を策定するにはどうすればよいですか？
- ポストプロダクションリリーステスト計画を作成するのは誰ですか？
- ポストプロダクションリリーステスト計画を承認するのは誰ですか？
- ポストプロダクションリリースの検証計画はいつ作成しますか？
- ポストプロダクションリリースの検証を完了しました。次は何ですか？
- 問題を見つけたらどうなりますか？
- ポストプロダクションリリースの検証プロセスについて他に何を知る必要がありますか？
- 結論：
- 推奨読書
ポストプロダクションリリース検証とは何ですか？
定義により、 役職 手段 後 、 プロダクションリリース 展開を指します ライブ/本番環境へ そして 検証 含む リリースされた機能が要件を満たしていることを確認する 。
おすすめの読み物=> テストを開始する前に「テスト環境」を効果的に準備する方法
目的は、本番環境/ライブ環境でのリリースを確認することです。
Eclipseで新しいプロジェクトを開始する方法
しかし、その後、疑問が生じます。
- QA環境ですべてをテストしたのに、なぜポストプロダクションリリーステストを行う必要があるのですか？
- テスト環境でリリースを徹底的にテストしたにもかかわらず、本番環境で問題が発生すると予想されるのはなぜですか？
完全にフォローしたとしても、本番環境で問題が発生する理由はたくさんあります。 品質保証プロセス （つまり テスト計画 、テスト計画のレビュー、テストサイクル、 回帰テスト 等。）
本番環境で問題が発生する理由：
1）データの問題 –実稼働環境とテスト環境で利用可能なデータは異なる場合があります。これにより、テスト環境でいくつかのコーナーケースの問題を見逃す可能性があります。
2）展開の問題 –会社に手動のビルド展開プロセスがある場合、リリースは展開の問題を起こしやすい可能性があります。一般的なシナリオには、構成またはサイト設定の欠落、DBスクリプトの欠落、展開の順序に従わない（コードを最初に、次にDBなど）、依存関係が正しくインストールされていないなどがあります。
また読む=> QAテスターが展開プロセスについて知っておくべきこと
3）影響領域が特定されていない –影響を受ける領域がチームによって正しく完全に特定されていない可能性があるシナリオがいくつかある可能性があります。
例えば、検討してください SaaS 環境。
チームが、古いテーブルスキーマを使用して、リファクタリングされたDBテーブルがクライアントに与える影響を特定しなかった場合（データの損失、 データ移行 リリース前など）など）。この問題は、正確な要件を持つ十分に計画されたプロジェクトでは発生する可能性が低くなります。しかし、その可能性はまだ存在します。
4）不明な影響領域 –これは、リリースの範囲と影響を受ける領域が不明な場合に発生する可能性があります。たとえば、共通のDBとアーキテクチャを共有する複数のソフトウェア製品を使用している企業では、わずかな変更でも多くの製品の機能が損なわれる可能性があります。
リリース後の検証フェーズにはどのようなタスクとアクティビティが含まれていますか？
ポストプロダクションリリースのタスクとアクティビティには、通常、次のものが含まれます。
- ポストプロダクションリリースの検証
- 検証結果を報告する
- 本番環境で見つかった問題の報告
- リリース後の検証データのクリーンアップ
- リリース後の監視（該当する場合）
すべてをもう一度テストする必要がありますか？
必ずしも。これは、リリースされるビルドと影響分析によって異なります。
詳細なテストは、通常のQAサイクル中に実行する必要があります。リリース後の検証は、そのリリースの完全なテスト計画の派生物である必要があるポストプロダクションリリースの検証テスト計画に従って行う必要があります。
ポストプロダクションリリースの検証戦略を策定するにはどうすればよいですか？
ポストプロダクションリリースの検証計画は、通常のテスト計画と同様の方法で行う必要があります。
戦略 QAサイクル中に実行されるテストフローと同じ行にある必要があります。最大の機能範囲を可能にする最も重要で重要なステップを含めることが重要です。
さまざまなブラウザで私のウェブサイトをテストする
優れたポストプロダクションリリース戦略は次のとおりです。
- 新しい機能と主要な既存の機能をテストする手順を含める
- 主要な影響領域を確認する
- 最大の機能カバレッジを許可する
- オプション：テスト環境で見つかった重大なバグをすべて含めます
- オプション：テストケースの優先度を含める
ポストプロダクションリリーステスト計画を作成するのは誰ですか？
これは企業によって異なり、組織構造によって異なります。
次のQAチーム組織の例を見てみましょう。
このシナリオでは、特定のプロジェクトに取り組んでいるQAが、最初のポストプロダクションリリーステスト計画を策定します。
ポストプロダクションリリーステスト計画を承認するのは誰ですか？
これは企業によって異なり、組織構造によって異なります。
前の質問に示したのと同じ組織構造を再度検討する場合、ポストプロダクションリリースのテスト計画は、 テストリードまたはQAマネージャー 。
ポストプロダクションリリースの検証計画はいつ作成しますか？
ポストプロダクションリリースのテスト計画は、要件、開発範囲、および影響領域が特定されてロックされた後、ソフトウェア開発サイクル中いつでも作成できます。通常、QAは、スプリントの途中でポストプロダクションリリーステスト計画を作成する方が簡単です。これにより、レビューと承認のための十分な時間が確保されます。
このテスト計画を他のテスト計画と一緒に含めることをお勧めします 正式なQA承認文書 プロジェクトが展開およびリリースフェーズに入る前。
ポストプロダクションリリースの検証を完了しました。次は何ですか？
リリース後の検証が完了したら、次のステップは次のようになります。
1）検証結果の伝達 –検証結果は、本番環境で見つかった可能性のある問題を含め、利害関係者に伝達する必要があります。
2）欠陥管理ツールで本番環境で見つかった問題を報告する –へ 根本原因分析を容易にする そして トレーサビリティ 。
3）リリース後の検証データのクリーンアップ –検証が完了した後、データのクリーンアップを実行する必要があります。
例えば、検討してください eコマースアプリケーションのリリース 生産時にテストオーダーを作成したとします。このテスト注文は、検証が完了した後でキャンセルする必要があります。
4）ポストプロダクションリリースの監視（該当する場合） –一部のリリースでは、本番環境での監視が必要です。
例えば、チームがアプリケーションのページ読み込み時間を改善するために改善を行った場合、リリース後に改善が実際に見られたことを確認するために、これを一定期間監視する必要があります。監視の責任者を明確に特定し、伝達する必要があります。
問題を見つけたらどうなりますか？
問題がある場合は、 欠陥管理ツール 利害関係者に伝えました。本番環境で重大な問題が見つかった場合は、問題をさらに調査するためにビルドをロールバックする必要があるかどうかを判断する必要があるため、結果の伝達をすぐに行う必要があります。
見つかったすべての問題を欠陥追跡ツールで報告することが重要です。通常のQAサイクルのバグとの分離を示すために、これらを個別の問題タイプ（ポストプロダクションバグなど）として提起することをお勧めします。これらの問題は、根本原因分析の目的で必要な場合、簡単に除外できます。
ポストプロダクションリリースの検証プロセスについて他に何を知る必要がありますか？
実際のポストプロダクションリリースの検証プロセス、計画、および戦略に加えて、以下にいくつかの指針を示します。
- リリース後の検証の範囲と目的に関して明確な期待を設定することが重要です。利害関係者（内部および外部）は、次のことに注意する必要があります
- チームは本番環境ですべてをテストすることはできません
- チームは、リリース後の検証のために取っておいた数時間に、数日分のテストを詰め込むことはできません。
したがって、本番環境でのテストは、基本的に、承認されたポストプロダクションリリーステスト計画に基づいています。
制限事項：
十分な注意が必要です ポストプロダクションリリーステストの範囲を決定しながら。実際に本番環境でテストできる内容と量には制限があります。実稼働環境にはライブクライアントデータがあり、非常に注意深く処理する必要があります。データの移行、更新、削除などを伴う変更については、追加の計画を立てる必要があります。
例1）： eSurvey企業の場合、テストに調査への回答と送信が含まれる場合、QAは、クライアントの調査収集データとその統計に影響を与えないように、検証後にテスト調査を削除するリクエストを送信する必要があります。
IS 例＃2）： eコマース企業の場合、価格更新SQLジョブが毎日深夜に実行され、最終的な価格がWebサイトにアップロードされると仮定します。このSQLをオンデマンドで、リリース後の検証のために複数回実行することはできません。これにより、未完成のデータが本番環境にプッシュされる可能性があります。
さらに、それはの可能性を高めることができます DBデッドロック クライアントアプリケーションのパフォーマンスに影響を与える可能性のあるピーク営業時間中のCPUおよびメモリリソースの大量消費。
- リリース後のテストおよび関連するすべてのアクティビティに必要な作業を組み込み、プロジェクト計画に含める必要があります。ビジネスルールとプロジェクトの詳細に応じて、これはプロジェクトのオーバーヘッドと見なされるか、QAサイクルに含まれるか、リリース管理計画の一部として含まれます。
- リリース後の検証中に報告された問題については、根本原因分析を実施して、問題が早期に発見されなかった理由と、問題に直面しないように次回より適切に行うことができる方法を見つける必要があります。根本原因分析は、チームがこれらの過去の問題から学び、実装のギャップを埋めるのに役立ちます。組織構造に基づいて、テストリードまたはQAマネージャーは、プロジェクトチームからの入力を使用して根本原因分析を完了することができます。一般的な根本原因には、コーディングの問題、要件の問題、設計の問題、データの問題、サードパーティの制限、テストシナリオの欠落などがあります。対応する修正措置と予防措置を作成して追跡できます。
- サーバーログ リリース後のビルドの監視にも使用できます。 サーバーログ お客様には見えないかもしれないが、バックエンドで問題を引き起こすイベントや問題が含まれている可能性があります。このモニタリングは、アクションアイテムとして開発リーダーとDevOpsチームに割り当てることができます。
例：
Javaサンプルプログラムのオブジェクトの配列
プロジェクトの概要：
以下の変更は、ソーシャルメディアアプリケーション、特にサインアッププロセスに加える必要があります
- 姓フィールドの検証を削除する必要があります。以前は「姓は4文字以上にする必要があります」として実装されていました（既存のフィールドの改善）
- メールアドレスの横にトグルボタンを実装して、ユーザーがプロフィールに表示するメールアドレスのプライバシー設定を設定できるようにします（新機能のリクエスト）
- ユーザーは自分のアバターを選択できる必要があります（新機能のリクエスト）
- サインアッププロセス中のAPI呼び出しを減らして、アプリケーションのパフォーマンスを向上させます（改善）
ポストプロダクションリリース検証計画：
| S.No. | 説明 | 期待される結果 | 状態 | コメント |
|---|---|---|---|---|
| 1 | Livesiteurlに移動します | ウェブサイトのホームページが正常に読み込まれるはずです | パス | |
| 二 | (新規ユーザーとしてサインアップ)をクリックします | ユーザーは登録/サインアップページにリダイレクトされる必要があります | パス | |
| 3 | 必須フィールドに入力し、(登録)ボタンをクリックします 注意： -「Lee」として姓を入力します -プライバシーボタンを(表示しない)に切り替えます -アバターのもの | -登録が成功すると、ユーザーはプロフィールページにリダイレクトされます。 -ユーザーの電話番号は表示されません -ユーザーが選択したアバターは表示されます | パーシャルパス | アバターが正しくレンダリングされておらず、壊れた画像として表示されています。 JIRAでBUG-1088として報告されました |
| 4 | 監視-このリリース後にアプリケーションのパフォーマンスが向上したかどうかを確認します | サインアッププロセス中のAPI呼び出しを減らすと、アプリケーションのパフォーマンスが向上します。 | 進行中 | アプリケーションを24時間監視するためのアクションは、DevLeadおよびDevOpsチームにあります |
| 5 | リリース後のクリーンアップ | 作成したテストアカウントを削除します | 完了 |
結論：
現在、ほとんどのソフトウェア会社で アジャイル手法の採用 、製品リリースの数が増加しました。
例えば、使用中 ウォーターフォールモデル 、チームは1.5か月ごとに製品リリースを行う場合がありますが、アジャイルプロセスでは、同じチームが2〜3週間ごとに製品リリースを行う場合があります。
すべての製品リリースで、ライブクライアントの機能に故意または無意識のうちに影響を与える可能性があります。リリース直後にポストプロダクションリリース検証を採用することで、リリースの信頼性を高めると同時に、ライブクライアントが問題に遭遇する前にリリースをロールバックするセーフティネットを提供できます。
影響が大きい/リスクの高いプロジェクトの場合 、ポストプロダクションリリースの検証計画は、テストシナリオの優先度に基づいて構成できます。重要な優先度テストを最初に実行し、結果や問題について関係者に連絡を送ることができます。重大な問題が見つからない場合は、ポストプロダクションリリースの検証を続行できます。それ以外の場合は、アプリケーションのダウンタイムとライブクライアントへの影響を最小限に抑えるために、ロールバックを決定する必要があります。
さらに、 ポストプロダクションリリーステストは自動化できます テストスクリプトは、リリースごとに回帰テストとしてオンデマンドで実行できます。繰り返しになりますが、本番環境で自動テストスクリプトを実行する際は、ライブクライアントのデータと機能に影響を与える可能性があるため、十分な注意が必要です。
ポストプロダクションリリースの検証は 最後の防衛線 すべてのソフトウェア会社のために。私たちが問題を見つけなければ、私たちの顧客はそうするでしょう、そしてこれはどんなソフトウェア会社の評判にも壊滅的な影響を与える可能性があります。
製品の信頼性を維持するためには、展開直後に本番環境に展開された変更を確認することが不可欠です。
著者について： この役立つ記事はNehaBによって書かれました。彼女は現在、品質保証マネージャーとして働いており、社内およびオフショアのQAチームの指導と管理を専門としています。
ポストプロダクションリリースのテスト戦略/ヒント/経験を読者と共有してください。