language-agnostic - バグに優先順位を付けるには？

Question

私の現在の会社では、テストチームと開発チームの間で、バグの深刻度について明確な理解が得られていません。深刻度を下げたり上げたりする議論があります。私たちは今のところ、規則を定める文書を認識していません. テスターはバグを提起し、直感に基づいて優先順位を割り当てます。開発者は、負荷またはその他の要因に基づいて変更を要求します。

バグの重大度/優先度はどのように分類されますか? 顧客のニーズ、タイムラインなどに基づいて、ソフトウェアの欠陥の優先順位を決定する方法を示す基準はありますか?

score 11 · Accepted Answer

重大度や影響度とは意図的に関係のない優先度レベルを使用し、スケジュール内のバグの概念上の位置付けのみを記述します。このフィールドは、どのバグに取り組むかを決定するため、交渉の対象になります。
具体的で検証可能な定義を故意に持ち、交渉の余地がなく、スケジュールや優先度とは関係のない重大度レベルを使用します。私はDebian BTS で使用されている重大度の定義を正常に使用しており、一般的なプログラミングプロジェクトに適用できるように一般化されています。

そうすれば、重大度は、優先順位の表明とは関係なく、検証可能な事実の問題になります。優先度は、重大度フィールドの事実情報に影響を与えることなく、ネゴシエーションなどによって自由に調整できます。

「重大度」と「優先度」の両方を 1 つの分野に混同しようとすると、魂を消耗させる議論と無駄な時間につながります。バグ報告者は、バグがどの程度「悪い」かを判断するための確固たる事実のガイドを必要とし、これは独立した関係者によって容易に合意される必要があります。一方、優先順位は、交渉やゲームのスケジューリングの正しいターゲットです。

score 8 · Accepted Answer

私は緊急制御センターシステムに取り組んでいるので、この一連のバグレベルは少しですが...極端です：

誰かが死ぬ
DR呼び出しを必要とするシステム障害全体
エンジニアの対応が必要なサーバー障害
通話の継続性の喪失を伴う障害
データの損失を伴う障害
誤ったデータが記録されました
アプリケーションの障害-回復不能
アプリケーション障害-回復不能ですが、自動的に再起動されます
要件仕様を満たしていない、回避策なし
要件仕様を満たしていませんが、回避策があります
化粧品-レイアウトなど
実際には機能リクエスト

それは私の頭から離れています。あなたが不思議に思っているのであれば、それは最も極端なものから最も少ないものまでです:-)

score 4 · Accepted Answer

以前使っていたもの。欠陥の評価を優先度と重大度に分けます。

重大度(欠陥の提出時に提出者が設定)

最高 (5): データ損失、ハードウェア損傷の可能性、またはセキュリティ関連の障害
高 (4): 合理的な回避策なしで機能が失われる
中 (3): 合理的な回避策による機能の喪失
低 (2): 機能または機能セットの部分的な損失 (機能は依然として設計要件を満たしています)
最低 (1): 表面的なエラー

優先度（不具合評価時に開発、管理、QAにより調整）

最高 (5): システムは、この欠陥により実質的に使用できません。
高 (4): 欠陥は、このシステムを販売および維持する会社の能力に深刻な影響を与えます。
中 (3): この欠陥がシステムにある場合、会社はいくらかの損失を被りますが、スケジュールを守ることの方が重要かもしれません。リリース後に修正。
低 (2): リリースを遅らせませんが、後でこの問題を修正します。
最低 (1): 時間とリソースが許す限り修正します。

両方の番号を合わせてリスク優先番号 (RPN) を作成します。重大度に優先度を掛けるだけです。結果が高いほどリスクが高くなります。25 は、究極の欠陥爆弾を定義します。1 は、アイドル時間中、または誰かが退屈していて何かをする必要がある場合に実行できます。

第 1 の目標: あらゆる種類の評価が最高または高の欠陥は、リリース前に修正する必要があります。2 番目の目標: 製品をリリースする前に、RPN > 8 の欠陥を修正する必要があります。

これはもちろん少し人工的ですが、すべての関係者 (サポート、QA/テスト、エンジニアリング、および製品マネージャー) に、反対側の意見を吹き飛ばすことなく優先順位を設定するためのツールを提供するのに役立ちます。

score 3 · Accepted Answer

バグ追跡システムを fogbugz に置き換え、重大度フィールドを完全に取り除きます。

優先度と重大度を参照してください

score 2 · Accepted Answer

「そこに行った」。

私はさまざまなプロジェクトでこの議論を何度も繰り返してきました。優先度と重大度を組み合わせようとしましたが、私が学んだ教訓は、重大度と優先度を組み合わせないことです。

たくさんのブレインストーミングやミーティングがあり、「これはそれです」という言葉で終わりました。複数のガイドライン-ドキュメントが作成され、さまざまな「当事者」間で広まりましたが、しばらくすると、最終的には機能しないことがわかりました。「当事者」が異なれば、バグについての考え方も異なります。ヘルプデスクは、開発チームや営業担当者とは別の優先順位を理解しています。

重大度と優先度の両方があると、次の理由ですぐに非常に混乱します。

数字（1から5の間）を使用する場合、各数字が何を意味するのかわかりません
問題の優先度が可能な限り高く、重大度が可能な限り低い場合はどうなりますか？これが発生すると確信しています。
誰かが重大度を下げる場合、優先度も下げる必要がありますか？

「では、どうすればいいですか？」：

問題の「レベル」には1種類のインジケーターのみを使用してください。どのように呼んでもかまいません。
重要性を明確に示すために数字（例：1〜5、ただし必要に応じて多かれ少なかれ）を使用しますが、それが何を意味するのかを明確にするためにキーワードと組み合わせます（例：「持っているといい」、「ストッパーを表示」）。一部の人にとってはprio1が最も重要であり、他の人にとっては5が意味します->したがって、数字が何を意味するかを示すキーワードが必要です。
「通常の問題」と「赤いアラート」を区別します。私たちの場合、「レッドアラート」はすぐに解決され、すぐに本番環境に移行する必要があります。通常の問題は、通常のdevelopment-test-deployment-flowに従います。優先度/重大度/ただし、どのように呼び出すか-通常の問題に対してのみ設定する必要があり、「赤いアラート」では無視されます。*>実際には、「レッドアラート」は

「通常の問題」：サポートチームが重大なバグを発見し、「レッドアラート」を作成しました。しかし、調査の結果、データがアプリケーション経由ではなく直接データベースに挿入されたため、データベース内で「破損」していることがわかりました。*
フローをカスタマイズできる優れたツールを選択してください。しかし、ほとんどのツールはそうします。

score 1 · Accepted Answer

テスターは何が壊れているかを教えてくれます
開発者は、修正にどれだけの作業が必要かを見積もります
ビジネスの価値、つまり優先順位を決定するのは顧客です。

score 1 · Accepted Answer

標準については、ソフトウェア異常の分類に関する IEEE ガイドですが、これがどの程度広く採用されているかはわかりません。IEEE 1044.1-1995

score 1 · Accepted Answer

1 つのオプションは、製品所有者にバグの優先順位を決定させることです。バグがどの程度「悪い」かについてはある程度の一般的な直感がありますが、優先順位を設定するのは製品の所有者の責任である可能性があります (つまり、バグ A はバグ B の前に修正する必要があるなど...)。

製品所有者に提供できるより多くの情報 (明確かつ簡潔) は、その個人がそれらの決定を下すのに役立ちます (つまり、バグを経験したユーザーの数、バグの結果として利用できない機能など)。

score 1 · Accepted Answer

今すべきこと
出荷前に行う必要があります
軽度の煩わしさ (ユーザーが機能を実行するのを妨げない)
エッジケース/リモート/モルドールのテスターシナリオ

まあ、私はそれを作り上げました...バグを分類するという私のポイントは、毎週1時間以上の長い儀式であってはなりません..
私見、フローチャートに優先順位を付けるのは時間の無駄です。Cat#1 と #2 のバグを修正します - バグが表面化したらすぐに修正します。バグに圧倒されていることに気付いた場合は、速度を落として熟考してください。スケジュールで許可されていない場合、または優先度の高いアイテムがオーバーライドされている場合は、Cat#3 と Cat#4 を延期します。
重要なことは、この重大性と期待される品質について、全員が共通の理解を持っていることです。X の神聖な標準への準拠によって、顧客が望んでいるもの、つまり動作するソフトウェアの提供を遅らせてはなりません。

score 1 · Accepted Answer

個人的には、重大度と優先度の 2 段階のモデルを好みます。私は単一レベルの議論を知っていますが、私が働いた場所では一般的に、2 レベルのヒエラルキーがうまく機能するのを見てきました。

重大度は、サポートチームによって設定されます (クライアントからの入力に基づく)。優先度はクライアントによって設定されます (サポートチームからの入力によります)。

重大度については、次を使用します。

1 - ブロッカー/ショーの停止
2 - 主要な機能が利用できない (または事実上利用できない)、実用的な回避策がない
3 - 主要な機能が利用できない (または ...)、可能な回避策がある
4 - マイナーな機能が利用できない (または事実上利用できない)、作業がない可能な程度
5 - マイナーな機能が利用できない (または ...)、可能な回避策
6 - 表面的またはその他の些細な回避策

次に、優先順位として、高、中、低を使用しますが、3 ～ 5 レベルのいずれでも機能します (それよりもはるかに上です)。

私は通常、最初に優先順位で注文し、次にその中で重大度で注文します。これについて重要なことは、クライアントが最も重要な発言権を持っているということです。ロゴがレポートに印刷される方法が最優先事項であると彼らが言う場合、それは見られるものですが、ログインを妨げている他のクライアントの優先度が高い後に見られます.

一般的に言えば、優先度の高い問題や重大度 1 から 4 の中優先度の問題をリリースすることはありません。明らかに、理想的な世界ではすべてを修正することになりますが、その選択肢があるほど幸運なことはありませんでした。

score 0 · Accepted Answer

機能とバグの両方に次のカテゴリを使用します。

ショーストッパー、プログラム (または主要な機能) が動作しません
持っている必要があります。顧客のかなりの部分がこれに悩まされます。
一部の顧客は気にするでしょう
あると便利です。数人のお客様がこれを希望しています

通常は 1、2、3 を修正する予定ですが、3 は時間の制約から次のリリースに延期されることがよくあります。

score 0 · Accepted Answer

お客様の 1 人と同じ問題がありました。最後に、特定の重大度に一致するバグの種類を説明するドキュメントを一緒に設定しました。このドキュメントをガイドラインとして使用する時折の議論は別として、うまくいくようです。

ただし、テストチームと開発チームは、重大なバグとそうでないものについて非常に異なる意見を持っている可能性があることに注意してください。テスターの観点からは、開発者が誰も気付かないだろうと言っている場合、小さなレイアウトのバグが優先度が高くなる可能性があります。

私たちのドキュメントでは、これらのバグが「ブランドに損害を与える」場合、優先度を高くすることができます。つまり、レイアウトのバグがロゴまたは製品の 1 つにある場合、それは深刻です - ページ上の 2 ピクセルずれている単なる段落である場合そうではありません。

score 0 · Accepted Answer

プロジェクトの要件を設定して、バグによって妨げられた要件の優先度に基づいて修正の優先度を決定できるようにします。

score 0 · Accepted Answer

これは非常にシンプルに保つ必要があるというFogBugzの人々に同意します：http://fogbugz.stackexchange.com/questions/352/priority-vs-severity

覚えやすいこのスキームを作成しました。

pS: 秒の問題です。たとえば、サーバーが燃えています
pM: 分が重要です。たとえば、何かが壊れています
pH: 時間が重要です。つまり、これが完了するまで寝ないでください。
pd: 日の問題、つまり通常の優先度
pw: 週単位、つまり優先度が低い
pm: 数か月が重要です。つまり、急ぐ必要はありません。
py: 年は重要です。つまり、多分/いつか、つまり、ウィッシュリストです。

これは、Debian のスキームとほぼ同じです: http://www.debian.org/Bugs/Developer#severities

優先度と重大度を 1 つのフィールドにまとめて、値を設定しやすいので気に入っています。

PS: 「分単位」と「時間単位」の間で「pMH」のような中間の緊急度を選択することもできます。または、「pHd」は「時間の問題」と「日の問題」の中間にあります。大まかに言うと、「文字通り徹夜するのではなく、完了するまで他の作業を行わないでください」.

language-agnostic - バグに優先順位を付けるには？

15 に答える 15

Related

Reference