メニュー

QAテスターがリリースおよび展開管理プロセスについて知っておくべきこと

what qa tester should know about release

問題を排除するために楽器を試してください

html面接の質問と回答pdf

今日の私たちのチームミーティングでは、マネージャーが全員に確認しました テスト実行の準備 。彼は「コードは明日の朝までにQAの準備ができている」と述べました。彼が「コードの準備ができている」と言ったとき、彼はどういう意味でしたか？それは開発者が今夜QA環境でコードを書くつもりであることを意味しますか？

彼は実際には、展開は夜間に行われる予定であり、新しいコードはテストのためにQA環境に展開されることを意味していました。

あなたの多くは今、展開とは何か、そして彼らは実際にその中で何をしているのかと尋ねるかもしれません。

qaのリリースおよび展開管理プロセス

学習内容：

QAチームの全体的なリリースおよび展開管理プロセスと重要性

  • なぜ私たちは本当に異なる環境を維持しているのですか？
  • コードはどのようにしてある環境から別の環境に移行されますか？

この記事では、次のトピックについて説明します。

  1. テスターがリリースと展開のプロセスを認識することが重要なのはなぜですか？
  2. さまざまな環境
  3. ビルドとデプロイとはどういう意味ですか？
  4. 計画的展開と緊急展開
  5. QAチェックリスト–展開の前後

＃1。テスターが展開プロセスを認識することが重要なのはなぜですか？

テスト実行の主な仕事は、展開がどれだけ成功したかによって異なります。展開チームが課題に直面し、いくつかの問題に遭遇し、コードを適切に展開できなかった場合、QAチームが環境または展開プロセスに関連する可能性のある多くのバグを特定しようとしていることを確実に示します。

  • テスターが展開プロセスを認識している場合、計画された時間枠内にタスクを完了することの重要性を理解します。
  • テスターは、問題が実際に機能のバグであるか、展開中に発生した何かであるかを判断します。たとえば、テスターはレポート機能をテストするように割り当てられていますが、Webサイトにログインしようとすると、環境がダウンしていることを意味するエラーが表示されます。 、そのような問題は機能的な問題としてではなく、環境的な問題と見なすことができます。テスターがデプロイメントを認識している場合、その問題をデプロイメントの問題に関連付けることができます。
  • テスターが展開されたリストを実際に認識していれば、多くの非問題を回避できます。展開されたことのない領域の問題をテストして報告することがあります。

＃2。さまざまな環境

さまざまな環境

上記の分類では、ほとんどの組織が従う4つの最も重要な環境について説明しましたが、多くのクライアントは、ステージング、プレステージングなど、より多くの環境を維持しています。また、命名規則が異なる場合があります。

  • DEV – 開発環境は、コードを作成するために開発チームによって作成および保守される環境です。この環境へのアクセスは、開発チームにのみ与えられます。通常、QAチームはこの環境にアクセスできません。この環境は、主に開発チームが単体テストに使用します。
  • QA- QA環境は、テストが実際に行われる環境です。この環境はQAチームが所有しています。 DEVチームはこの環境にアクセスできません。設計とコーディングの完了後、コードはQA環境に移動され、QAチームがテストを実行できるようになります。
  • UAT- ユーザー受け入れテスト は、ビジネスユーザーがテストを実施する環境です。これは、システムテストが完了した後に行われます。主な目的は、ビジネスの観点からシステムをテストすることです。この環境へのアクセスは、ビジネスユーザーにのみ許可されます。ただし、QAの支援を求める場合もあります。そのような状況では、QAチームは環境への一時的なアクセスを許可されます。
  • PROD- PROD環境は、実際のユーザーに公開される実際のライブ環境であり、DEVチームとQAチームのいずれもこの環境への読み取り/書き込みアクセス権を持っていません。製品サポートチームは、本番環境に関連する問題を解決するために維持されます。

また読む=> 「テストベッド」を効果的に準備し、テスト環境の欠陥を最小限に抑える方法

＃3。ビルドとデプロイとはどういう意味ですか

ビルドには主に、実行可能bat、exe、dll、libなどのライブラリ、zipファイルなどのアーカイブを含むコンパイル済みパッケージが含まれています。開発チームはビルドを作成し、インストールのために展開チームに提供します。

ソースコードのコンパイルは主に開発チームによって処理され、ビルドを生成した後、別の環境にデプロイするためにデプロイメントチームがアクセスできる特定の場所にソースコードを配置します。

ビルドがデプロイされると、QAチームは ビルド検証テスト （BVT）成功した​​場合、チームは残りの 機能テスト 。

個別の展開チームを維持していない一部の組織では、開発チームがQAにビルドを提供し、QAチーム自体が展開を完了します。大きなリスクが伴います。そのような場合、QAリソースは、ビルド展開プロセス全体を理解するために技術的に健全であり、問​​題が発生した場合の修正方法も知っている必要があります。

ビルドは、1.0.01または1.0.03などの数値を使用して維持されます。したがって、ビルド1.0.01がDLL v0.2を実行し、ビルド1.0.03がDLLv0.5を実行している可能性があります。 QAチームにとって、テストを開始する前に、正しいビルドが環境にデプロイされていることを確認することが重要になります。各ビルドの一部として提供された変更を追跡することは常に良い考えです。

ある環境から別の環境へのコードのスムーズな移動に役立つため、個別のデプロイメントチームを維持することは常に良い習慣です。

デプロイメントは、コード/ビルドをある環境から別の環境に移動するプロセスです。最近の組織のほとんどは、展開のための適切なチャネルに従い、これらすべてを処理する別のチームを維持しています。

ビルドとデプロイ

間のc ++乱数

展開日の前に、開発者、開発マネージャー、展開エンジニア、テストリード、およびその他のビジネス関係者で構成されるチームが集まります。会議では、開発者は通常、自分の変更について説明するように求められます。通常、変更とロールバック計画の詳細を特定のフォームに記入する必要があります。

一部の詳細が欠落している場合、変更は展開が承認されません。次に、チームは、変更を翌日の展開の一部にすることができるかどうかを決定します。 QAテストリードは、変更が既存のテストに影響を与えないことを確認するための承認を求められます。会議では、最終的な展開項目が計画されます。

承認済みリストは、展開日に展開チームによって処理されます。チームは、各変更フォーム（開発者によって提供される）で定義されている一連のプログラムを実行し、展開が完了すると通信を送信します。

Deployment Completeメッセージは、変更/新しいコードをテストする準備ができていることをQAチームに示します。

変更をDEVからQAに移行するのは、展開チームの責任です。 QAテストが完了すると、コードはUATに移動されます。 PRODデータの移動は最も重要な部分であり、展開中に環境を停止する必要があり、ビジネスに深刻な影響を与える可能性があるため、細心の注意を払って実行する必要があるため、営業時間外に実行する必要があります。

Prodの展開のほとんどは、エンドユーザーが環境に影響を与える可能性が少ない深夜に行われます。

＃4。計画的展開と緊急展開

すべての組織は展開カレンダーを維持しています。多くのお客様は週に1回の展開に従い、多くのお客様は隔週で展開を行っています。計画された展開は火曜日にのみ行うか、火曜日と金曜日に行う可能性があると述べています。展開予定日が休日の場合、展開日が変わる場合があります。

上記のセクションでは、どのような場合にも実行されるプロセスについて説明しました。 計画された展開 。

計画された展開には、独自の課題があります。新しいコードがQA環境にデプロイされ、健全性テスト中にチームがブロッカーの欠陥を特定し、テストを停止する必要がある場合を考えてみてください。テストチームは次の展開まで1週間待ちますか？

このような状況に対処するために、緊急の修正と展開が行われ、展開チームは計画された展開日まで待つ必要がありません。緊急展開の場合でも、フォローして承認を求める必要がありますが、これらの承認は通常迅速に行われ、新しい変更は同じ日に、またはできるだけ早くQA環境に展開できます。

＃5。 QAチェックリスト–展開の前後

展開前–

全体 テスト設計フェーズ コードが実際に環境に移動される前に行われます。展開チームがQAにコードを展開する作業を行っている間、QA環境でのコードの可用性に依存するのはテストの実行です。QAチームは、以下のアクティビティを完了していることを確認する必要があります–

  • テストケースがレビューされ、承認されていることを確認します
  • テストチームが利用可能であり、リソース計画が完了していることを確認します
  • 確保 テストデータのニーズが特定されます

展開後–

展開後、QAチームとして最初に行うことは、健全性テストを開始することです。ただし、健全性テストを開始する前に、以下の点に注意する必要があります–

  • QAチームは、展開が成功し、QAの準備ができているという通知を展開チームから受け取っているはずです。
  • QAチームは、展開されたビルドを追跡する必要があります。
  • QAチームに、正常に展開された変更のリストと、計画されていても展開されなかったアイテムのリストがあることを確認してください。詳細が不足しているなどの理由で、展開チームが展開できなかった可能性があります。

結論

上記の記事で、ソフトウェア開発サイクル全体の一部として実行されるリリースおよび展開管理プロセス全体についてのアイデアが得られたことを願っています。これはほとんどの組織で行われている一般的な手順にすぎませんでしたが、多くのお客様は異なるプロトコルを使用しています。

著者 ：この素晴らしい記事は、STHチームメンバーのPriyaRによって書かれました。

このプロセスは役に立ちましたか？組織で従う展開プロセスについてお知らせください。

推奨読書

^