バグ・トラッキングとは、ソフトウェアのテスト中にバグとエラーを記録し、監視するプロセスのことです。 障害トラッキングまたは問題トラッキングとも呼ばれます。 大規模なシステムでは、何百または何千もの障害が発生することがありますが、 障害それぞれに対して、評価、監視、デバッグ用の優先順位付けを行なう必要があります。 場合によっては、長期間にわたってバグをトラッキングすることも必要です。

「複雑で業務上重大なシステムには何百もの障害が生じるので、障害トラッキングがソフトウェア・エンジニアリングにおいて重要なプロセスになります。」とはTutorials Point社の見解です。 「このような障害の管理、評価、優先順位付けは困難な課題の1つです。 障害の数は時間の経過とともに非常に増えるため、それらを効果的に管理するために障害トラッキング・システムを使用することで、ジョブの簡素化を図ります。」  ¹

ソフトウェアのバグは、アプリケーションやプログラムがその設計通りに動作しない場合に発生します。 エラーの多くは、システム構築の担当者、設計者、開発者による失敗やミスです。 テスト・チームは、バグ・トラッキングを利用して、アプリケーションの開発やテストを行なう際に発生するエラーを監視し、報告します。

「バグ・トラッキング・システムの主な構成要素は、既知のバグに関するファクトを記録するデータベースです」とウィキペディアに掲載されています。 「ファクトには、バグが報告された時刻、その重大度、誤ったプログラム動作、バグを再現する方法の詳細、バグの報告者や修正担当プログラマーのIDなどが含まれます。」 ²

単一の障害が、そのライフタイムで複数の段階や状態を経ることがあります。 段階には以下のようなものがあります：

• アクティブ：調査が進行中
• テスト：修正され、テストの準備完了
• 検証済み：品質保証（QA）によって再テストと検証が完了
• クローズ済み：QAによる再テスト後、または障害と見なされない場合はクローズ可能
• 再オープン：修正されておらず、再度アクティブ化 ³

バグは優先順位と重大度に基づいて管理されます。 重大度レベルは、製品リリースに対する問題の相対的な影響を識別するのに役立ちます。 重大度レベルの区分数は異なりますが、一般的には以下のような形式があります：

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

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

ソフトウェア開発者は、コード1,000行ごとにおおよそ100から150のエラーを出すと言われています。⁴ Consortium for IT Software Quality（CISQ）のレポートには「これらのエラーのうち深刻なものはごく一部（約10%）であったとしても、20,000行のコードから成る比較的小さなアプリケーションでは約200の深刻なコーディング・エラーが発生することになります」と記載されています。 ⁵

エラーの切り分けと軽減にはソフトウェア・テストが不可欠です。 優れたQAプロセスでは何百、何千もの障害が見つかることがありますが、テスト・チームはそのすべてを管理しなければなりません。 その際にバグ・トラッキングをテストのワークフロー内に組み込むと、テスターが各エラーの状況に優先順位を付け、監視、報告を行なえるため、効率が向上します。

「障害トラッキングは、実際にシステムで発見されたバグを確実に修正するために役立ちます」こう語るのはアジャイル・コンサルタントのYvette Francino氏です。 「トラッキング・ツールを使用すると、バグ・トラッキングを最後まで確実な方法で遂行できるだけでなく、価値ある指標も提示されます。 使用ツールに応じて、チームが障害を変更されたコードやテストなどのデータと関連付けることで、障害の傾向に基づいて追跡可能性を確保し、分析することができます。 特定モジュールに障害が多いときには、そのモジュールをレビューして書き直すことが必要な場合があります。」 ⁶

テストはできるだけ早期に、つまりバグを簡単に修正できる上、コストも大幅に抑えられるタイミングで行うのが理想的です。 IBMによる以前の研究によると、実働後やリリース後に見つかった障害は、開発の初期段階で障害を解決した場合に比べて修正のコストが15倍になる可能性があります。

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

ますます複雑になるアプリケーションを、障害とコストを削減しながら、より素早く市場に投入する方法をご覧ください。

堅牢なアプリケーションを開発する上で品質管理は欠かせません。 チームは、ソフトウェア・テスト、変更管理、バグ・トラッキングの各ツールを利用することで障害を発見し、その範囲と影響を判断して解決することができます。

「ハーバード・ビジネス・レビュー」でNicholas Bowen氏が障害管理プロセスの概要を説明しています。 最初のステップは分類と優先順位付けです。「通常チームでは、2種類のバグ（システムのクラッシュを引き起こすバグと、それほど深刻ではないものの広範囲に影響が及ぶ可能性のあるバグ）を優先させます....次に、重大度のレベルごとに目標対応時間を決めます。 品質管理システムが新しい場合、最初に取り組むのは、数時間または数日以内に行う最も重大なバグの修正です。 システムを使用する際に、2つの重要な指標となる「バグ受信率」と「バグ修正担当者の生産性」に関するデータを収集し、必要に応じて目標を調整できます。」 また、彼は「組織内で障害の場所とその解決に要した時間を、CEOを始めとするすべてのレベルでレビューできるシステムの構築も必要である」と述べています。⁷

優れたバグ・トラッキング・システムでは、障害の監視、報告を行ない、ライフサイクルの追跡可能性を確保する単一のワークフローを提供することで、このプロセスを支援できます。 そのシステムがさらに他の管理システムとリンクすることで、ソフトウェア開発と大規模な組織の両方で可視性とフィードバックを共有できるようになります。 例えば、IBM Rational ClearQuestはエラー・トラッキングとレポートを一元管理されたプラットフォームで提供します。 これはIBMの他の開発システムや変更管理システムと統合され、開発者、運用、広範なチーム間のコミュニケーションやコラボレーションの向上を図ることができます。

また、AIを利用して開発プロセスの初期段階でエラーを検出するテストとトラッキングのシステムもあります。 この製品では、チームが実行するテストの数と種類を最適化し、テスト・プロセスを自動化し、AIを利用して過去の障害を分析することで将来の障害を防ぐことができます。