バグもソフトウェアもありません。すべての人には邪悪な側面があり、すべての開発者はプロジェクトで間違いを犯し、最も慎重に作成されたプログラムでさえ崩壊する可能性があります。
ソフトウェアによって生成されたエラー メッセージをログに記録して処理することは、一見すると簡単な作業です。ただし、バージョンがリリースされるたびに、既知のバグの数が増減する可能性があります。
「古い間違いは去り、新しい間違いがやってくる」 – これは開発者に関する古いジョークです。エラーを制御するために、人々はそれを欠陥追跡システムと呼ぶ素晴らしい製品が誕生しました。
欠陥追跡システムとは何ですか?またその原理は何ですか?
欠陥追跡システムは、プログラマー、テスター、プロジェクト マネージャーがソフトウェア内で見つかったエラー (欠陥) を収集および制御し、これらのエラーを除去するプロセスを監視するのに役立つ一連のソフトウェアです。言い換えれば、欠陥追跡システムは欠陥を追跡し、整理するのに役立ちます。
以下に、最も人気のある 4 つの欠陥追跡システムとその機能を示します。
バグを追跡するための 6 つの簡単なヒント
1 リリースは迅速かつ頻繁です
覚えておくべきことの 1 つは、長期間にわたって持続するバグが最も迷惑であるということです。迅速かつ頻繁なリリースに重点を置くことで、開発者とテスターの間に緊密なフィードバック関係を確立でき、未処理のバグ レポートがバグ キューに大量に残ることを回避できます。
2 コミュニケーションブリッジを構築する
欠陥についてレポートを作成するときは、欠陥レポートに完全な情報を含める必要があります。誤解が生じたり、重要な情報が欠落したりする状況に遭遇することがあります。
このような場合、開発者とテスター間のコミュニケーションが必要になります。これを避けるためには、チームメンバー全員が団結し、フィードバック重視の文化で働く必要があります。
3 プロジェクト会議で欠陥について話し合うのは避ける
欠陥について話し合って次の段階に進めるのは長いプロセスです。一つずつ治療したほうがいいですよ。それぞれの欠陥は、問題発見者 (テスター) と問題解決者 (開発者) と呼ばれる 2 人の専門家に関連付けられています。
プロジェクトに何人の開発者とテスターが取り組んでいるとしても、必要なのは、異なる役割と役割を持ち、既存の問題を解決する責任を負う 2 人の専門家だけです。
4 効果的な解決策に焦点を当てます
バグレポート内の既存の欠陥については、個人的な意見を表明するコメントは避けてください。代わりに、電子メールまたはグラフ作成ツールを使用してください。欠陥レポートには、欠陥の監視と修正に関連するコンテンツのみを含める必要があります。
5 クローズされたバグについて
クローズされたバグが何を意味するかについて、チームの他のメンバーと同じ認識を保ってください。
バグのステータスについて話し合う必要がある状況に遭遇した場合、次の質問は正しい決定を下すのに役立ちます: 誰が指示を出す (またはバグを報告する) 責任を負うべきか、誰が指示を受け取る責任を負うべきか結論(現時点での問題の解決策)は何ですか?
「クローズされたバグ」とは、問題を解決した開発者によってクローズされたバグを常に意味します。バグをクローズできるのはその人だけであるため、バグをクローズする責任者と報告者が同じ人であることを確認してください。バグを修正する ソリューションが問題を解決するのに十分であるかどうかに責任を負います。
6 バグの特定には 2 つの状態のみを使用します
バグの特定には、未解決のバグとクローズされたバグの 2 つの状態のみを使用するようにしてください。バグのさまざまな状態に時間を無駄にすることは避け、代わりに問題の考えられる解決策に集中してください。