機能バグは、ソフトウェアの機能に関連する問題です。たとえば、ボタンを押してもフォームが送信されない、検索がユーザーの入力に反応しない、アプリがクラッシュするなどです。操作を行った際にWebサイト／アプリが期待どおりに反応しない場合は、機能上の問題である可能性があります。お客様の製品についての情報が限られており、その実装について十分な知識がないため、観察された動作が意図されたものなのか、実際にバグなのかを判断することは困難です。経験に基づいて合理的に推測し、さまざまなシナリオをテストして製品の動作を分析することで、判断の助けになります。

機能バグの重大度レベルを判定する際には、複数の要因を考慮する必要があります。問題が機能に与える影響、問題の範囲、回避策が存在するか、またはショーストッパーであるか、潜在的かつ重大な売上損失が発生する可能性があるか、そして同じ重大度の他のバグと比較できるかどうかです。

分かりやすい方法として、バグが機能に与える影響を見ることができます。ある機能が利用できないことがどれほど重大なのかを考えてください。補助的な機能が壊れていても、主要な機能が壊れている場合とは異なり、ユーザーが目的を達成することを妨げるとは限りません。その機能が製品全体の中でどれほど重要なのかを考えてください。

機能上の問題によって何人のユーザー、何個の製品、または何件の項目が影響を受けるかは、問題の範囲を判断する重要な要素です。たとえば、Webショップの商品詳細ページすべてで「Add to Cart」ボタンが反応しないのでしょうか、それとも特定の1ページだけでしょうか。問題の影響を受けるのは少数のユーザーでしょうか、それとも全員でしょうか。

別の経路やオプションから目的を達成できるか、それともある機能が利用できないままなのかを考えてください。バグを直感的かつ簡単に回避する方法を見つけられる場合、このいわゆる回避策によって、引き続き目的を達成できます。回避策があるバグは、同等のバグで回避策がない場合よりも低い重大度になります。最後に、壊れた主要機能に回避策が存在しない場合、それはショーストッパーです。

潜在的な売上損失の見積もりは二次的な判断方法です。バグに対して人々がどのように反応するかは、多くの場合、推測することしかできないためです。それでも、潜在的な損失がどの程度になるかは考慮してください。商品の価格差が数セントなのか、数百ドルなのかでは大きな違いがあります。

また、同じチームリーダーがこのテストですでに承認したバグと自分のバグを比較することで、自分の重大度レベルが適切かどうかを確認することもできます。

重大度が固定されているケースの一覧があります。上記の判定方法は、その一覧に記載されているケースには適用されません。この一覧は時間の経過とともに更新されるため、定期的に確認してください。

エッジケースのバグは、機能が通常とは異なる方法で使用された場合に発生します。一般的なデータと通常のユーザー操作で使用する場合、機能自体は壊れていません。例：

各ケースは個別に評価する必要があります。お客様にとって関連性のあるエッジケースのバグは、低重大度のバグとして処理されます。ほとんどのエッジケースのバグに該当する関連性のないケースは却下されます。

通常とは異なる操作や特殊な条件によってバグを強制的に発生させることは、一般的に対象外です。このようなバグはお客様にとって関連性がないためです。通常とは異なる操作は、通常のユーザー行動を反映していません。通常とは異なる操作や特殊な条件の例：