関係のなくなったバグを閉じる方法

21

現在、中規模のWeb開発者チームに所属しています。バグ追跡にjiraを使用しています。

私たちは頻繁にレイアウトを変更する製品に取り組んでいます。多くの場合、一部のブラウザのレイアウトのバグについてバグが報告されます。時々、優先度の低いバグに対処する頃には、レイアウトはすでに変更されており、関連性がなくなっています。

何を閉じますか？
私が言いたいのは、これらの問題をどう扱うべきかということです。Jiraは私たちが使用するバグ追跡ソフトウェアですが、私はこれらの種類の問題全般をどのように処理するかにもっと興味があります。
それも重要ですか？（後でレイアウトに戻る可能性がありますが、ほとんどありません）

issue-tracking jira

— ベンジャミン・グリュンバウム
ソース

8

ローカライズが多すぎる;）

— ヤンニス

4

これがローカライズされすぎていることに同意しない場合、ツール固有の可能性があるとしても、SOに適している可能性があります

— jk。

6

@jk。へー、私は質問に対する提案/回答として「ローカライズされすぎた」ことを意味しました。質問自体が「ローカライズされすぎている」ということではありません。後者を考えた場合、私はそれを閉じたでしょう。

— ヤニス

2

@YannisRizos doh！たぶんそれは答えだったはずです;）

— jk。

6

@jk。2番目の質問はもっと面白いと思います（それでも問題ですか？）が、私は今それに答える時間がありません（そして私の頭に形成されている答えが良いものであるかどうかは本当にわかりません）。最初の質問に関しては、このスレッドが「単語/フレーズの提案」スレッドになると、「建設的でない」として閉じられる可能性があります。したがって、回答者は、2番目の質問を無視しないでください。これは話題の興味深い質問です。

— ヤニス

26

プロジェクトで報告された問題の状態を伝える手段として課題追跡を検討する場合、そのようなニュアンスは重要です。そのためには、バグレポートを読みやすく理解しやすいものにするためにある程度の努力を注ぐのが理にかなっています。

この状況は、テスターの観点から見れば、それほど混乱しません。あなたのチームはテスターを持っていない場合は、（より良いまだまたは1つ雇うものを想像して^1、2、3）。

わかりましたので、その後はずっと持っているバグがワンス・アポン・ア・タイム、テスターは、古いリリースのコピーを保持していないとは考えにくい場合は、アプリケーション（サイドノートの古いリリースを使用してそれを再現することができなかったくらいで困難な問題をあなたの時代遅れのバグよりもチーム）。テスターはそれを見ることができ、何が間違っているのか、何がバグなのかを知ることができます。

ここで、「レイアウトはすでに変更されており、関連性がなくなっています」と言います。高額な関連性がなくなったため、テスターの心はより単純なステートメントに変わりました。問題はなくなりました。

ここで、プロのテスターは、システムをブラックボックスとして快適に考える必要があることに注意することが重要です。その観点から、問題がどの程度正確に発生したかはそれほど重要ではありません。レイアウトの変更、黒魔術、全面的な再設計、具体的なコードの変更などです。

ブラックボックスの観点から見ると、状況は非常に単純です。問題がありましたが、古いリリースでも再現可能ですが、新しいリリースではそのような問題はもうないと主張しています。テスターにとって、これはバグが修正されたという主張と、それぞれ主張が真実かどうかを検証する必要性に要約されます。

プロのテスターが古いリリースを取得し、そこに問題がどのように存在するかを確認し、新しいリリースを取得して、それが存在するかどうかを確認します。

上記から、あなたが説明したようなバグを処理する最も正確な方法は、解決済み、修正済みとしてこれらを閉じることです。もちろん、修正がレイアウト変更の意図しない副作用として発生したことをコメントで明確にしても問題はありません。

過去のプロジェクトで私が使っていたカスタマイズされたJIRAの1つは、「Fixed By Design」という解決策を持っていました。あなたが説明するような場合、それは単なる「固定」の代わりに考えることもできます。意図的にコードを変更するのではなく、むしろ副作用であることをチケットリーダーに示唆するからです。

— ぶよ
ソース

2

設計によって修正されたということは、私にはそれの完全な反対を意味します。私の考えでは、設計とは「意図的」を意味します（「誤って」の反対です）。

— TRiG

「修正済み」で十分であることに同意します。それが意図的なものであるか、他の変更の副作用であるかはまったく関係ありません。ただし、「Fixed by Design」がわかりにくい@TRiGにも同意します。

1

@TRiGであるため、コメントで正確な詳細を説明する方が良いと指摘しました。Fixed By Designは少し広いです。私が見たプロジェクトでは、かなり重大な変化を伝えるために使用されました。多くの結果があり、意図的なものもそうでないものもあります。また、質問テキストも私の回答も「間違って修正する」（どのような間違いですか）を意味するものではありません-ここでは、「意図しない」の方がはるかに適しています

— -gnat

1

すべての答えは良いですが、これはそれを釘付けにするようです。みんな、ありがとう。

— ベンジャミングリュンバウム

6

「Fixed by Redesign」はどうですか？

— ペングア

47

「廃止」などの問題を解決します。これはJIRAのデフォルトの解像度オプションではありませんが、追加するのは簡単です。

— クリス
ソース

少なくともそれをバグではないとして選択し、理由をコメントできない場合は、+ 1

— tgkprog

9

JIRA（および他のバグトラッカー）では、カスタム解像度を指定できるため、「Overtaken By Events」または「Irrelavant」などの解像度を設定できるようになります。

それは重要ですか？私たちにとっては、トラッカーの未解決の問題の数について顧客が過度に懸念しているので、私たちは「はい」と言うでしょう。したがって、問題を完全に削除することなく関連性がなくなったため、これらはクローズされていると言うことができると便利です。

顧客が問題番号に懸念を抱いていない場合でも、関連性がなくなった古い未解決の問題を整理することは、ブラウザの混乱を減らすためだけに役立ちます。

— jk。
ソース

1

「イベントのオーバーテイク」が長すぎる（私見）ので、検索が簡単でスペースが少ない（レポートなどで）という理由だけで、1つの単語（無関係/古い）を使用します。廃止されたバグの量が有用であることを知っていたのは、それらが大量に入ってきたときであり、それは通信の問題を示していました。私たちのテスターは、開発者が取り組んでいるものに追いついていませんでした、彼らは物事が1週間かそこらのために不安定になるというメモを逃し、（無駄な）音を立てていました。だから、私たちの目を振り返ってください。バグは、コミュニケーションプロセスの穴を見つけて修正するのに役立ちました。

— ヤンニス

3

私たちは実際に頭字語OBEを使用していますが、実際に使用されている単語はここで最も興味深いポイントではないと思います。ポイントはあなたのために働くものを選ぶことです

— jk

3

@YannisRizos：バグを使用してメタバグを修正。なんてかっこいい！

— ヨルグWミットタグ

@YannisRizosの検索は、とにかく（JIRAで）ドロップダウンから有効な解像度が選択されるため、それほど大きな問題ではありません

— jk。

2

@ヤニス。私はそれについて眠りを失います：追い越されることは一言でなければなりません。

— TRiG

5

私たちはFogBugzを使用しますが、ここでは同じ（または類似した）が当てはまると確信しています。

「解決済み（修正済み）」を使用し、「Fixed by case 12345」のように解決策を編集します。

FogBugzは「case \ d +」と一致し、Relation Casesの下で2つをリンクしますが、Jiraがそれを行わない場合は、リンクを追加するだけで簡単です。

それはので、これは、「あまりにもローカライズされた」バリアントよりIMO優れていた、それが固定されたため、その機能は、単に削除されていなかった、実際のバグ、そしてちょうど「廃止」よりも良いです。

— イズカタ
ソース

3

落ち着いてもう一度確認することで修正されました<-実話。

— ヤニス

1

Jiraではこのアプローチも可能です。解決コメントに問題番号を記載するだけで、Jiraはそれをハイパーリンクに変えます。

— マルジャンヴェネマ