無料のバグ レポート テンプレートとフォーム

最先端のアプリケーションの開発に次いで、ソフトウェア会社にとって、現在のバージョンの欠陥を修正するよりも重要なものはありません。これらのバグを追跡しなければ、アプリケーションは設計どおりに機能せず、顧客は満足せず、収益が失われます。

しかし、これらの欠陥をどのように追跡しますか? 開発者が修正できるように、組織はバグを正しく追跡し、包括的に文書化し、適切な個人に割り当てる必要があります。だからこそ、質の高い製品を期限内に納品し、エンド ユーザーを満足させるためには、適切なバグ追跡テンプレートを選択する必要があります。

カスタマー サービスの担当者、QA のメンバー、開発者、さらにはクライアントによってバグが見つかった場合でも、十分な詳細を提供して、キューに入れてバグを修正できる簡単な方法が必要です。

以下のいずれかの形式で無料のテンプレートを選択して、見つけたバグの提出をすぐに開始できます。

• Microsoft Excel (英語)

• Microsoft Word

バグ追跡テンプレートを希望の形式でダウンロードしたら、次のフィールドに入力します。

• 欠陥 ID: バグを参照できるように、一意の ID を入力します。

• 著者: 誰がバグ レポートを書いたかを指定します。

• リリース ビルド番号: バグが検出されたリリース ビルド (またはソフトウェアのバージョン) を入力します。

• 日付: バグが見つかった/提出された日付を入力します。  

• クローズ日: バグが修正された日付を入力します。

• タイトル: バグを説明する明確で簡潔なタイトルを入力します。

• 説明: バグの詳細な説明を入力します。

• 環境: バグが発見された環境を指定します。

• 誰が検出したか: 誰が最初にバグに遭遇したかを入力します。

• 検出方法: バグが最初に検出された方法を説明します。

• 担当者: バグを確実に修正するために誰が割り当てられたかを入力します。

• 優先度: バグを修正する優先度 (高、中、低など) を選択します。

• 深刻度: バグの深刻度を選択します。どれくらい深刻ですか (ブロッカー、クリティカル、メジャー、マイナー、些細な、強化など)。

• ステータス:バグのステータス (新規、オープン、解決済み、承認済み、進行中、検証、完了など) を選択します。

• ステータスの説明: バグのステータスを説明します (「バグは QA テストの準備が整っています」など)。

• 修正者: バグを修正した人を指定します。計画された修正ビルド番号: バグ修正の対象となるソフトウェア ビルドを指定します。