機能バグは、ソフトウェアの機能に関するバグです。例えば、ボタンをクリックしてもフォームが送信されない、検索がユーザーの入力に反応しない、アプリがクラッシュするといったものです。操作を行った際に、Webサイトやアプリが期待どおりに動作しない場合、それは機能バグである可能性があります。私たちはお客様の製品に関する情報が限られており、その実装についても把握していないため、確認した動作が意図された仕様なのか、それとも実際のバグなのかを判断することは容易ではありません。経験に基づいて推測を行い、さまざまなシナリオで製品の動作を検証することで、その判断材料を得ることができます。

機能バグの重大度を評価する際には、いくつかの要素を考慮する必要があります。具体的には、問題が機能に与える影響、問題の影響範囲、回避策があるかどうか、または業務を継続できないレベルの問題かどうか、売上に大きな損失をもたらす可能性があるか、さらに同じ重大度の他のバグと比較して適切かどうかです。

機能への影響に注目することが、最も分かりやすい評価方法です。その機能が利用できないことがどれほど重大かを考えてください。補助的な機能が利用できなくても、通常はユーザーが目的を達成することを妨げません。一方で、主要な機能が利用できない場合は目的を達成できなくなる可能性があります。その機能が製品全体の中でどれほど重要かを考えてください。

機能上の問題によって、どれだけ多くのユーザー、商品、または項目が影響を受けるかも、問題の影響範囲を判断する重要な要素です。例えば、Webショップの商品詳細ページにある「Add to Cart」ボタンが、すべての商品で反応しないのか、それとも特定の商品だけで反応しないのかを確認してください。また、影響を受けるのが一部のユーザーだけなのか、それともすべてのユーザーなのかも考慮してください。

別の経路や方法で目的を達成できるか、それともその機能がまったく利用できないままかも考慮してください。バグを簡単かつ直感的に回避できる場合、その回避方法（ワークアラウンド）によって目的を達成できます。ワークアラウンドがあるバグは、同等の問題であってもワークアラウンドがないバグより低い重大度になります。一方、主要な機能が利用できず、ワークアラウンドも存在しない場合は、業務を継続できないレベルの問題（ショーストッパー）となります。

売上損失の可能性を見積もることは補足的な評価方法です。実際には、ユーザーがそのバグにどのように反応するかは推測するしかない場合が多いためです。それでも、想定される売上損失の大きさは考慮してください。例えば、商品の価格差が数セントなのか、数百ドルなのかでは、影響は大きく異なります。

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

重大度があらかじめ決められているケースの一覧があります。その一覧に含まれるケースには、上記の評価基準は適用されません。

この一覧は随時更新されるため、定期的に確認してください。

エッジケースのバグは、通常とは異なる方法で機能を使用した場合に発生するバグです。一般的なデータや通常のユーザー操作では、その機能は正常に動作します。以下はその例です。

それぞれのケースは個別に評価されます。お客様にとって重要と判断されたエッジケースのバグは、Lowのバグとして転送されます。一方、ほとんどのエッジケースのバグに該当する重要ではないケースは却下されます。

通常ではない操作や特殊な条件によって強制的に発生させたバグは、一般的に対象外です。そのようなバグは、お客様にとって重要ではないためです。通常ではない操作や特殊な条件の例は次のとおりです。