欠陥が製造上の欠陥であるかどうかを確認する
QA担当者として、私は常に、欠陥を再現できるように修正するために必要なすべての手順が欠陥にあるべきだと常に信じています。
しかし、QAが開いたすべての欠陥がすでに本番環境に存在している場合、それをチェックする必要があると考えるのはおかしいですか？理由、私が尋ねる理由は、この問題が本番環境に存在するかどうかにかかわらず、QAがこの調査を行っていれば、開発者の時間を節約できるかどうかについて、絶えずいじくる開発マネージャーがいるからです。私はそれを理解していますが、QAがテストサイクルで見つけたすべてのバグが本番環境にも存在するかどうかを確認することは、少しナンセンスだとまだ思います。
開発マネージャーの観点から見ると、バグの処理方法に直接かつ直接的な影響があるため、欠陥が新しいものか既存の欠陥かが重要です。開発マネージャーの観点から、最も重要な質問は、現在のリリースサイクルで新しいバグを解決する必要があるか、それとも待機して、後のサイクルで優先順位を付けることができるかどうかです。これは、多くの場合、バグが新しいかどうかによって異なります。
新しいバグを見つけた場合、それは現在のリリースサイクルでの新機能/バグ修正の1つが問題を引き起こしたことを意味します。その場合、誰かが現在のリリースの一部として問題を修正する必要があります（バグの原因となった変更を元に戻すか、バグ自体を修正する）、またはビジネスで新機能Xの追加が導入に値するかどうかを判断する必要があります新しいバグYが導入された場合。ほとんどの場合、バグは現在のビルドサイクルで解決する必要があります。解決しない場合は、問題のある変更をロールバックする必要があります。一方、現在の変更ラウンドの前に存在していた古いバグを見つけた場合、現在のビルドサイクルは通常続行でき、新しいバグは将来のリリースで優先される可能性があります。もちろん、バグがそれほど重大であるため、現在のリリースサイクルで新たに特定されたバグを処理する必要がある場合がありますが、そのようなケースはまれである傾向があります。
バグが現在のリリースに影響するかどうかを確認するのはQAの責任であるのか、それともバグに優先順位を付ける人（優先順位付けがすぐに行われると想定している）が行うのかは未解決の問題です。私のバイアスは、彼らが既にバグを書いているので、QAにそれをするように依頼することです。 QA担当者はすでにバグの再現方法を知っているので、本番環境に存在するかどうかを確認するのに最適な位置にいます。また、QA部門では、作業が多くのアナリストに分散される可能性があるため、優先順位付けを行う人よりもこの種の調査に利用できる時間が多くなる傾向があります。
ここで2つの別々の質問です。生産的なシステムをチェックする必要がありますか、誰がそれを行うべきですか？同じ会社の2つの別々の部門について話しているとしましょう...
- それを行う時間があるのはどの部門ですか？ウォーターフォールであれスクラムであれ、私が経験したほとんどのプロジェクトでは、リリースが近づくにつれてテストがボトルネックになります。その理由だけで、開発環境のスタッフに開発環境のチェックを渡すことは理にかなっています。
- 一方、多くのテスターは開発者よりも収益が少ないため、十分な数のテスターがいる場合は、それらにレッグワークを任せることは経済的に理にかなっています。
- 誰が生産的環境に必要なアクセス権を持っていますか？私が働いている場合、開発にはそれがないことがよくあります。オペレーション（もちろん）とQA（2次レベルのサポートを兼ねているため）だけです。
プロジェクトの予算とスケジュールがこの責任を反映している限り、段階的、生産的、またはその他のシステムでチェックを実行できることを開発マネージャーに伝えます。
欠陥が見つかったら、最も重要なことは、重要な情報（タイトルまたは要約、欠陥または問題の詳細、実際に何が発生し、何が発生するはずであるか）を記録することです。それを再現する必要があり、それが見つかった環境（OS、Webブラウザー、テスト中のソフトウェアバージョンなど）。プロセスによっては、欠陥レポートを提出する人が優先度や重大度を割り当てる場合もあります。
QAの観点からは、通常、まだ開発中のソフトウェア、またはせいぜいリリース候補のソフトウェアに注目しています。開発チームは、ユニット、統合、およびいくつかのシステムテストを実行する前に実行する必要がありますが、テストは完全ではなく、開発チームがリリースする前に確認する必要がある問題を見つけることになります。最終的には、特定された問題に優先順位を付け、このリリースサイクルで修正されるか、それ以降のリリースサイクルで修正されるかを決定するのは、組織の担当者次第です。
開発サイクル全体を通して、開発チームとQAチームの両方がテストを変更する必要があります。常に実行される regression test スイートがあるかもしれませんが、テストはより徹底的で、変更されたソフトウェアの機能または部分に焦点を当てていると思います。欠陥は、さまざまな理由で露呈する可能性があります。変更により欠陥が生じた可能性があります。変更により、欠陥がより明確になり、トリガーしやすくなり、より一般的になった可能性があります。新しいテストケースでは、長期間にわたってソフトウェアに潜んでいた欠陥が発見された可能性があります。テストで欠陥が検出された理由に関係なく、現時点ではそれほど重要ではありません-最優先事項は欠陥を修正することです。
お客様のセルフホストソフトウェアなどの一部の環境や、複数のバージョンをサポートまたは維持する義務がある場合は、ソフトウェアの複数のバージョンをテストして、お客様に通知できるように欠陥が最初にいつ導入されたかを判断する必要がある場合があります。特に重大な欠陥である場合。このような環境では、現在サポートされているバージョンから影響を受けるバージョンを特定し、問題が複数のレベルとラウンドのテストから逃れた理由に対処するために、QAチームに多くの負担がかかると予想します。
ただし、ソフトウェアの1つのバージョンのみがサポートされている環境では、欠陥がどのバージョンで始まったかが本当に重要であるかどうかはわかりません。欠陥がユーザーに影響を与えていて、ユーザーが問題を報告するメカニズムを持っている場合、彼らはそれを報告します問題として。ただし、品質の観点からは、ソフトウェアの既知の問題を理解することが重要です。プロジェクト管理の観点から、未解決の問題の量を使用して、ソフトウェアをリリースする準備ができているかどうかを判断したり、将来の開発サイクルの作業を計画したりできます。現在の開発サイクルが終了する前に修正される予定がない場合でも、修正されるまで、回避策とともにユーザー向けのドキュメントに反映される可能性があります。
最後に、欠陥が修正された後、何らかの 根本原因分析 を実行して、欠陥がいつ（現在の開発サイクルで）いつ挿入されたか、なぜ欠陥が挿入されなかったかを判断できます。以前の開発とQAサイクル（最近導入されていない場合）で発見され、この欠陥が再発しないように作成、実行、管理する必要があるテストの種類。
余談ですが、ソフトウェアQA組織が責任を負うべきことについては、いくつかのアイデアがあることに注意したいと思います。一部の組織では、ソフトウェアQAは本質的にテストチームであり、ソフトウェアリリースが要件を満たし、重大な問題がないことを確認するための最後の防御ラインです。他の組織では、ソフトウェアQAは製品の品質だけでなくプロセスの品質にも責任があり、開発プロセスのすべてのステップに関与して、（要件から配布メディアまでの）すべての作業製品が標準に従って完全で正しいことを確認します。他にも期待があります。この回答は、製品の品質を担当するソフトウェアQAに重点を置いています。
開発者として、私はこの問題をたくさん受けます。
いくつかの新機能がテストに送られ、「間違っているように見えますが」ライブ環境に存在する動作を説明するバグが報告されます。
新しい機能を開発する時間が割り当てられているため、これは問題です。ランダムな「バグ」を修正しない
多くの場合、その振る舞いがバグであるかどうか、修正の優先度をどのように取るべきかなどについて、長い議論が必要です。
問題は、追加のテストケースを作成し、それらをテストスイートに追加する前にライブに対して実行しないことから生じます。
スクラムや他のaglieプロセスを使用する開発者は、通常、時間を厳しく管理しています。
テスターが特定の要件に反するのではなくアドホックにバグを提起すると、開発者も作業し、遅延とフラストレーションを引き起こします。