開発者はバグ追跡システムにバグを入力する必要がありますか？

開発中（機能またはバグ修正のいずれか）、私が作業しているものに直接関連しないバグを発見することがあります。その状況で私は何をすべきか。修正するだけですか？後で修正することを忘れないでください。どこかに書き留めますか？それともバグ追跡システムに入力しますか？

私は通常それをバグ追跡システムに入力し、プロセス自体を再生させます（つまり、トリアージング、割り当てなど）。しかし、他の開発者がバグを入力することはほとんどありません。（何故ですか？）

バグを発見した場合、それを修正するかどうかにかかわらず、バグ追跡システムに入力しない正当な理由は考えられません。結局のところ、これがバグ追跡システムの目的です。

場合によっては、システムを扱った経験のあるQA担当者に報告する方が適切かもしれませんが、いずれにしてもバグを追跡する必要があります。

開発者がバグを入力してはいけないという、何らかの理由があるかもしれません。考えられる理由の1つは、バグ追跡システムが部外者に見えており、報告されたバグが多すぎるように見えることです。これは非常に悪い理由であり、バグを追跡できる他の方法で対処する必要があります。上司に聞いてください。

（もちろん、まだ作業中のコードにバグがあり、リリースされたものに表示されない場合は、システムで追跡する必要はありませんが、ソースコードのTODOコメントは極端な場合、「この行の最後にセミコロンを入力していないため、このコードはコンパイルされません」は報告可能なバグではありません。）

他の開発者がバグを入力しない理由については、それらを尋ねる必要があります。彼らはおそらくそうすべきです。

どちらの場合も、バグ追跡システムにバグを入力する必要があります。

• バグが作業中のコードに直接関係する場合、

• バグが現在作業していないコードまたは別の開発者が作業している部分に関係している場合。

バグ追跡システムは...バグを追跡するために作られているため、これは不可欠です。すべてのバグ。何か間違ったことを発見したら、それを直さないでください。バグ追跡システムを通じて文書化します。後日、以前のバージョンのソフトウェアを実行している顧客が完全に重複するバグを報告する場合、それをレポートにリンクできます。リンクするものが何もない場合は、以前のリビジョンのバグを検索する時間（または同僚）を無駄にし、それを解決しようとして、最後にバグがすでに魔法のように解決されていることがわかります。

これは、フリーランサーがバージョン管理とバグ追跡システムの両方を使用する必要がある理由も説明しています。これらの2つのツールはチーム専用ではありません。

欠陥を欠陥追跡システムに入力しない正当な理由はありません。追跡せずに適用されたバグ修正を確認した唯一の場所は、プロセスが根本的に壊れていたためです。この場合、プロセスを修正します。

入らない理由は次のとおりです。

• このプロセスは、欠陥報告に基づいて測定および処罰します。報告しないで、処罰しないでください。この場合、組織を離れる
• このプロセスには負担がかかります。欠陥を入力し、それを修正するまでに多大な労力と時間がかかります。開発者がtriage / accept / fixedプロセスを通じて軽量なバグを迅速に追跡できるように、プロセスを変更する必要があります。
• 一部の開発者は怠け者/ずさんな/ハッカーであり、他の人に与えることの影響を気にかけません。プロの開発者を募集します。
• 私は一人のバンドです。2人のバンドの仕事に行くと…

バグをすぐに修正することは、おそらく悪い考えです。最初に、他の誰かが同じ修正に取り組んでいて、重複した作業が発生する可能性があります。また、フォローしている開発方法によっては、次の作業の優先順位付け（バグの修正または新機能の実装）管理決定、開発決定。

決定は明確ではなく、トレードオフを伴います。

（一部）長所

バグ追跡は、特に大規模なチームでのコミュニケーションに不可欠です。コードに複数の目を持つことの最大の利点の1つは、問題を早期に検出できることであり、開発中にバグが記録または追跡されない場合、その利点は失われます。

• 多くの場合、バグはすでにコードの一部にいる間に最も簡単に修正され、それを理解するように働きます。
• 小規模なチームであっても、バグをリストでき、バグを修正することで進歩することで、士気を高めることには多くのメリットがあります。
• 正確なバグ検出は、事後に非常に困難になる可能性があります。コード内のバグを見ることは、探偵をして、問題が最初に発生した場所を見つけようとして、後で多くの作業を節約できます。
• 開発者としてのあなたの一般的な開発にとって、バグを見たときに注意を払い、コードを改善/クリーンアップ/読み取りするという習慣を身に付けるのは良いことです。

バグを見つけたときにログに記録するのは、一般的に言えば、良い習慣です。

（一部）短​​所

バグ追跡システムにバグを入力するのは面倒で時間がかかり、開発作業に大きな混乱をもたらす可能性があります-大規模なチームで作業している場合はそうです。次のことが期待されます。

• 入力する前にエントリが重複していないかどうかを確認します（これは暗黙的である可能性もあります。バグをキューに入れてクローズすることはできません）
• レポートに繰り返し可能なテストケースを提供する
• バグの詳細についての質問で後の中断を受け入れ、書かれたときに修正を受け入れ/検証する
• どの製品が最も影響を受ける可能性が高いか、バグの優先順位など、バグ追跡システムで頻繁に収集される無関係な情報について考えます。

バグ追跡は、時間の最も効率的な使用ではない場合があります。

これらはバランスを取るのが難しい2つの一般的な原則です。優れた戦略を見つけることは少し芸術です。このような状況では、特定のプロジェクト、チーム、作業環境、および一般的なスキルに応じて微調整する柔軟なヒューリスティックを採用するのが最善だと思います。私の戦略は通常、次のようなパターンに従います。

• いつでもどこかであなたが見ているように問題を記録してください。粘着性があるかもしれませんが、ファイルを横に置いているかもしれません。ログに記録するのはファイル名と行番号だけかもしれません。問題があなたの現在の考え方を妨げすぎないようにしてください。

• 仕事の準備の一環として、新しい就業日ごとに時間を取り、粘着物に対処します。前日から検出された問題のリストを確認するのに10〜15分かかり、次のうち最も速い方法を実行します。

  • 問題を修正してコミットします（おそらく1つのライナーの修正またはタイプミスの場合）。バグレポートなしでコミットすることが許可されていない場合は、小規模なコミット用のサイドプロジェクトを作成します。サイドプロジェクトに十分な修正が蓄積されたら、それらを文書化してコミットするのに必要な数時間かかります。
  • バグ追跡システムに問題を記録します（修正に時間がかかるが、面倒なオーバーヘッドのない明らかな問題の場合）
  • 「ビジーでないときに調べる」ドキュメントに問題を記録します（通常、「// TODO-これは壊れているように見えるので、修正する」とコメントをソースに追加します）。定期的に1日に1回（1か月に1回）リストを確認し、必要に応じてログに記録します（機能要求、バグレポート、マネージャーとの話し合いなど）。

時間が経つにつれて、私はあらゆる種類の調整が有用であると気づきました。例えば：

• より厳格な環境では、バグ報告作業をテストチームに任せるだけです。テスターに​​時々1時間会ってもらい、問題のリストを渡してログを取ります。テストのロギングが大事な環境では、通常、テスターは生産性が無料で向上することを喜んでいます。
• 一部のチームは、背後に顧客のバグレポートがない修正を許可しません。私はプロジェクトを修正でいっぱいにしておき、関連する問題がクライアントから報告されたときに即座にコミットして、無料ブラウニーポイントを獲得します。
• 一部のチームは、コードのチャンクを「所有する」人が修正を実行する人であることを要求します。コードの「所有者」をテストリーダーのように扱い、非公式に会合して問題を時々引き渡します

一般に、このタイプの戦略に従うと、同僚や他の会社のメンバーの多くがあなたの仕事と品質へのコミットメントを尊重し始めます。十分な時間の後、あなたは自分の好みに合わせてプロセス全体を最適化するために必要な敬意と権限を得るでしょう。そのような機会に目を光らせ、必要に応じてそれらを取り上げてください。

私は、開発者は、彼らが働いていると、彼らは固定されないことをどのように関連していないバグに遭遇した場合、彼らは持っているシステムに入力しなければならないと信じているいくつかのそれの記録を。こうすることで、QAがテストを開始する（まだ修正されていない）ときに、このリストのバグを「既知の欠陥」として与えることができ、同じバグの報告を開始しません。

バグを見つけた他の開発者は、修正を計画している場合、自分でバグを追跡しますが、その場合、2人の開発者が同じバグを個別に見つけて修正するというリスクを負います。

バグが既に修正されている場合でも（問題トラッカーに記録する前に発生してはならないことです）、追跡することをお勧めします。

このように、問題が将来再び発生する場合（回帰が発生します！）、問題を「すでに対処済み」として認識し、最初に修正された方法を読むのは比較的簡単です。

何故ですか？ほとんどの開発者は、提起しなければならない問題と記述しなければならないコードを見て、気にしないほうが簡単だと考えているためです。

しかし、それが正しいことかどうかは、プロセスによって異なります。QAチームはありますか？追跡されないコードを変更するだけなら、彼らは気にすると思いますか？コードレビューはどうですか？その亀裂でスキップしますか？ビジネスはどうですか？彼らはあなたがバグを修正したことを知っている必要があるので、後で同じバグが発生しないようにしますか？

他の開発者はどうですか？同時に別の方法で修正した場合はどうなりますか？彼らが後で同様のバグを見つけて、あなたができるすべてが「ああ、いまいましい、私たちは前にこのようなものを持っていることを知っている-今は何だった？」

バグ追跡システムにバグを記録する理由は約100万あります。あなたがこれらの問題のどれにも当てはまらないことを確信しているなら、どうしても気にしないでください。しかし、ほとんどの人が知らない場合でも、まったくわからない場合は記録する必要があります。

プログラミングは基本的に複雑な作業です。バグは複雑です。そのため、以前は2つの要因でバグを評価していました。

1. そのような種類のバグは、今後どのくらいの頻度で再び発生する可能性がありますか？この推定が正確であるかどうかにかかわらず、推定を続けます。
2. そのような種類のバグが再び現れるとき、それは理解しやすいですか？これは、このバグを分析して修正するときに正確です。

バグを次のいずれかのタイプに分類します。

1. 将来再び登場する可能性が高く、わかりやすい
2. 今後再び登場する可能性が高いが、理解しにくい
3. 将来的にはまれにしか現れず、理解しやすい
4. まれに再び登場するが、理解しにくい

ケース1では、チームが将来そのようなバグを修正するためのクックブックまたはFAQが役立ちます。

ケース2では、別のプログラマーがこのようなバグに再び耐えるのは労力の無駄であるため、チームには精巧でわかりやすい記録が必要です。例：メモリリーク。

ケース3では、簡単なバグを修正するのに時間をかけすぎないため、記録するものが何もないことは大したことではないと思います。たとえば、HTMLの要素のidのタイプミス。

ケース4では、このようなバグがジレンマを生み出します。このようなバグを説明するために、精巧でわかりやすい記録を作成するには時間がかかります。ただし、このレコードは今後ほとんど使用されません。しかし、記録がなければ、そのようなバグの出現は再び苦労するでしょう。たとえば、そのようなバグは、誰かのコンピューターのコンピューターウイルスが原因で発生します。

もちろん入力する必要があります。または、それが通常のプロセスであれば、少なくともQA担当者に報告してください。

バグを自分で修正しただけでも、変更の記録が必要になるので、テストして修正が実際に機能し、リグレッションが発生していないことを確認できます。また、ユーザーがバグをある時点で報告する可能性があります。バグがシステム内にあり、修正済みとマークされている場合、サポート担当者は既にバグに対処していることを伝えることができます。

実際、それらをシステムに記録する必要があります。それが実践されていない場合は、開始することをお勧めします。

私は過去に製品チームの一員であり、新製品のベータリリースを行っていましたが、時々バグを発見し、その時点でメモして、モジュールを処理している各担当者にメールを送信していました（バグ追跡システムですが、そこにプッシュすることは考えていませんでした）。後にメールのアイテムが数日経つと、他の優先事項のために無視され始め、最終的には眠れない夜になります。

それから、いつか強打、ニルヴァーナ！バグのように見えて、バグではない可能性があるものを見つけたとしても、なぜバグトラッカーを使用しないのですか（プロセスについてのあなたの考えが間違っている/欠陥がある）。それは少なくともリストで構成され、テストされる可能性があり、最も重要である理由または最も重要な理由についてのフィードバックの中で最も重要であり、それが理由1 ... 2 ...のためにどのように機能するかです。

これでリストができました。アプリケーションの一部を誤解している人のために、彼らは自分の考えを明確にすることができるフィードバックを持っています。Win-Winの状況。

既にテスト済みの（特にリリースされている場合）コードを絶対的に想定します。

これにはいくつかの理由があります。

メモリ -システムがバグを忘れることはほとんどありません。

メトリックス -発見されたバグの数、クローズされた時間、および取得にかかった時間は、コードの品質がどのように進行しているかを把握するための優れた簡単なメトリックスです。

緊急性 -開発者にとって世界で最も重要なことのように思えるかもしれませんが、この問題の修正に費やす時間は、エンドユーザーが最初に望むものに費やす方がよい場合があります（メモリも参照）。

複製 -すでに発見されている可能性があり、他の誰かによって調査/修正されています。あるいは、緊急ルールのファウルに陥り、延期された可能性があります。もちろん、あなたが再びそれを見つけたという事実は、それがされるべきではないということを意味するだけでなく、それは修正することがより緊急であるということを意味するかもしれません。

根本原因分析 -修正が最も簡単なバグは、決して存在しなかったバグです。チームがこのバグを調べて、それがどのようになったかを調べる必要があるかもしれません。これは、責任のある人（決して役に立たない）を罰するのではなく、将来どのように状況を回避できるかを見つけるための決定的なことです。

より広い影響分析 -最も安いバグを見つけるには、あなたがそれを見つけた前に、あなたは知っていたものです。（特に根本原因分析を行った後）このバグを見ると、この問題がコードの他の場所に存在する可能性があることがすぐに明らかになります。その結果、チームは、より恥ずかしい瞬間にい頭を上げる前に、それを見つけることを選択できます。

これらに費やされる時間（ある場合）は、コードの成熟度と品質レベルに大きく依存します。根本原因分析は、デモンストレーションコードに取り組んでいる小さなチームにとってはやり過ぎになる可能性がありますが、ビジネスクリティカルな開発に関する大規模なチームは、おそらくレッスンを効果的かつ効率的に学習する必要があります。

経験から、開発者がツールの使用を避ける2つの大きな理由があります。

1. バグ処理ツールおよび/またはプロセスは、開発には重すぎると認識されています
2. 開発者は、バグを修正するという精神的な課題が、現在取り組んでいるものよりも興味深いと感じています。

項目1は、より優れた/よりシンプルなシステムが必要になる可能性があることを意味します。あるいは、既存のシステムのより説得力のある正当化が適切であるかもしれません。

項目2は、現在のタスクの割り当てに関する開発リーダーへの有用な警告サインである必要があります。

私はほぼFrustratedWithFormsDesignに同意しますが、問題全体が2つの領域に分けられるとさらに明確になると思います。

• バグ報告。
• バグ修正。

これらはしばしば同じものとして扱われ、それらを分離することはほぼ確実に大いに役立ちます。

これらは次の方法で処理できます。バグ報告：-皆が言うように、システムにそれを置きます。

バグ修正：-毎週1〜2回（開発スケジュールなどに合わせて）全員がプロジェクトに集まり、誰が何を修正するかを決定します。これは誰もが同じページにいて、終わり。アジャイル開発では、これはスプリントプランニング会議です。

人々が使いたい良いツールも大きな違いを生みます。私はPivotal Trackerが好きで、私が自分のプライベートプロジェクトでやりたいことや修正したいことを追跡するためだけにPivotal Trackerを使い始めたとき、それは私の「本当に便利なツール」テストに合格しました！

何か見たら、何か言ってください！

現在のタスクを中断したくないので、自分のモジュールに関するバグレポートも入力します。そして、再現するためのすべての手順が含まれていることを確認できます:-)

そして、あなたが何かを既知のバグとしてリストしたことを他の誰かが見ることができればさらに良いです。彼らは他の誰かがそれを見つけたことを知りたいです。

これは、ベストプラクティスに関する質問というよりも政治的な質問だと思います。

• バグ侵入のせいでソムボディはどうなるのでしょうか？
• 顧客がバグエントリを読み、追加のエラーがあることを確認できます。これはあなたの会社の評判の問題ですか？
• これは本当にあなたが知らないバグまたは機能ですか？
• 誰がバグ修正を支払うのですか？

私の意見では、トラッカーシステムに些細でないバグを追加することは良い習慣ですが、管理者はこれに対処する方法を決定する必要があります。

自明ではない場合は、他の人に相談せずに問題を解決しないでください。

• これは本当にバグであり、機能ではありません
• sombodyは、修正をテストし、修正によって新しいバグが導入されないことを示すことができますelse elsere（回帰）