ソフトウェアのバグは、アプリケーションまたはプログラムが本来意図される状態で機能しない場合に発生します。 ほとんどのエラーは、システム・アーキテクト、設計者、または開発者による人為的ミスまたは障害です。 テスト・チームは、バグ追跡システムを使用して、アプリケーションの開発とテスト中に発生するエラーを監視し、報告します。

「バグ追跡システムの主要なコンポーネントには、既知のバグに関する事実を記録するデータベースがある」とウィキペディアには記載されています。 「ここでいう事実には、バグが報告された時間、その重大度、プログラムの誤った動作、およびバグを再現する方法の詳細が含まれる場合があります。また、それを報告した人の身元と、それを修正している可能性のあるプログラマーの身元も記載されるかもしれません」。²

そのライフタイムで、1つの障害が複数の段階または状態を経る可能性があります。例えば次のような段階を経ます。

• アクティブ：調査が進行中です
• テスト：修正済みで、テストを待っている状態です
• 検証済み：品質保証（QA）チームにより再テストを受け、検証済みです
• クローズ済み：QAチームによる再テスト後、または障害とみなされない場合はクローズ可能です
• 再オープン：修正されずに再び障害となった場合にこの状態になります³

バグは、優先度と重大度に基づいて管理されます。 重大度レベルは、製品リリースに対する問題の相対的な影響を特定するのに役立ちます。 これらの分類の数はさまざまですが、通常は次のような形式があります。

• 壊滅的：ソフトウェアの完全な障害、または回復不能なデータ損失を引き起こします。 これには回避策がなく、製品をリリースできません。
• 機能障害： 回避策が存在する可能性がありますが、不十分です。 ソフトウェアをリリースできません。
• 重大ではないシステムの障害：かなり満足のいく回避策が存在します。 バグが文書化されていれば、製品をリリースできる可能性があります。
• 軽微：回避策があるか、問題を無視できます。 製品のリリースには影響しません。

通常、状態と重大度レベルはバグ追跡データベースで監視されます。 優れた追跡プラットフォームは、より大規模なソフトウェア開発および管理システムと連携している：エラーの状態や全体的な生産およびタイムラインへの潜在的な影響をより適切に評価できます。

ソフトウェア開発者は、1000行のコードごとに100〜150のエラーを犯すと推定されています。⁴ IT業界団体であるConsortium for IT Software Quality（CISQ）のレポートによると、「深刻なエラーがこれらのエラーのごく一部（例えば10％）であったとしても、20,000行のコードで構成される比較的小さなアプリケーションでは、約200の重大なコーディング・エラーがあるということになります」。⁵

ソフトウェア・テストは、エラーを特定して軽減するために欠かせんません。 優れたQAプロセスでは、数百、数千もの障害が発見される可能性があり、テスト・チームはそれらすべてを管理する必要があります。 バグ追跡をテストのワークフローに組み込むことで、テストの実施者が各エラーのステータスを優先順位付け、監視、報告できるようになり、効率が向上します。

「障害追跡は、システム内で見つかったバグが実際に修正されがことを確認するのに役立ちます」とAgile社のコンサルタント、Yvette Francino氏は言います。 「追跡ツールは、フォロー・スルーを確実にする方法を提供するだけでなく、貴重な指標も提供します。 使用するツールに応じて、チームは変更されたコード、テスト、またはその他のデータに障害を関連付けることができるため、障害傾向の追跡可能性や分析が可能になります。 特定のモジュールに障害があまりにもたくさんある場合は、そのモジュールを見直して書き直す時期が来ている可能性があります」。⁶

理想的には、テストはできるだけ早く、バグの修正が容易でコストもはるかに低いときに行う必要があります。 IBMが前に実施した調査では、製造後またはリリース後に障害が見つかった場合は、開発初期に見つけて解決した場合と比較して修正に15倍のコストがかかる可能性があることが判明しています。

現在、多くのチームが継続的テストと呼ばれる手法を採用しています。この場合、品質テストとフィードバックは、設計、コーディング、展開に至る開発のすべての段階で実施されます。 人工知能（AI）などの最新テクノロジーも、ライフサイクルの早い段階でバグを検出して分析することで、テスト・プロセスを支援できます。

品質管理は、堅牢なアプリケーション開発に不可欠です。 ソフトウェア・テストの変更管理とバグ追跡ツールにより、チームは障害を発見し、その範囲と影響を判断して解決することができます。

米国の経営学術誌「Harvard Business Review」誌では、Nicholas Bowen氏が障害管理プロセスに関する概要を説明しています。最初のステップは、分類と優先順位付けです。「一般的に、チームは2種類のバグを優先します。1つは、システムをクラッシュさせるようなバグと、もう1つは深刻度こそ低いものの、蔓延する可能性のあるバグです。品質管理システムが新しいものである場合、最初の焦点は数時間から数日以内に最も深刻なバグを修正することです。システムを使いながら、2つの重要な指標、バグの発生率とバグ修正者の生産性に関するデータを収集し、必要に応じて目標を調整します」。 また、組織は、障害とその解決に要する時間を、CEO以下、あらゆるレベルで見直すためのシステムを構築する必要があると述べています。⁷

優れたバグ追跡システムは、障害の監視、報告、ライフサイクルにわたるトレーサビリティーを単一のワークフローで提供することで、このプロセスを支援できます。 さらに、他の管理システムと連携して、ソフトウェア開発チームと組織内の利害関係者間で可視性とフィードバックを共有する必要があります。 例えば、IBM® Rational ClearQuest は、エラーの追跡と報告のための一元化されたプラットフォームを提供しています。 他のIBM開発システムおよび変更管理システムと統合され、開発者、運用チーム、より広範なチーム間のコミュニケーションとコラボレーションの改善に役立ちます。

また、開発プロセスの早い段階でエラーを検知するため、AIを使用するテストおよび追跡システムを探してください。 チームが実行するテストの数と種類を最適化し、テスト・プロセスを自動化し、AIを使用して過去の不具合を分析することで、将来の不具合を防止することができます。