各システムを使用する理由と時期、およびバグ追跡アプリケーションと問題追跡アプリケーションを区別する機能の両方の説明を探しています。
18086 次
14 に答える
45
問題追跡システムは通常、顧客および顧客の問題とより統合されます。問題は、「これをインストールするのを手伝ってください」または「どうすればfubarをflimflamに入れることができますか」である可能性があります。「あなたのソフトウェアの評価キーが必要です」のようなものでさえあり得ます。
バグ追跡システムは、プログラムの間違ったものや欠けているものを追跡するのに役立ちます。
Webシステムを見ると、通常、顧客を支援するか、ソフトウェアの問題を追跡するかのどちらかで、焦点に大きな違いがあります。
于 2009-06-02T19:48:43.413 に答える
39
次の例から、違いがより明確になる可能性があります。
今日、5人の顧客に影響を与えたが、単一のソフトウェアの欠陥が原因である本番環境の問題が発生したとします。
問題追跡システムでは、5つのチケットを開き、各顧客が報告した内容、通知された内容、ソフトウェアパッチが適用された時期などの追跡を開始しました。このようなものは、顧客ごとに個別に追跡できます。
バグ追跡システムで、ソフトウェアの欠陥に対して1つのエントリを作成し、再現手順、コード変更などの追跡を開始しました。
お客様の問題は、お客様が満足するように修正された場合はいつでも解決できます。これには、ソフトウェアの修正が含まれる場合と含まれない場合があります。バグを修正して再テストすると、バグを閉じることができます。
外向きと内向きの2つのシステムで、それぞれ独自のライフサイクルを持つ2つの異なる種類のものを追跡します。
于 2009-06-02T20:10:39.127 に答える
11
Tracのようなバグ追跡システムは、プログラムに固有の問題ごとに1つのチケットを持つように設計されているため、プログラムを変更することでチケットを閉じます。
IssueTrackerProductのようなカスタマーサポートチケットシステムは、状況を経験している顧客ごとに1つのチケットを持つように設計されているため、その顧客の状況を把握することによって（おそらくプログラムを変更することによって）チケットを閉じます。
それぞれの例については、ウィキペディアの問題追跡システムの比較を参照してください。
于 2009-06-02T19:58:07.047 に答える
10
バグは問題のサブクラスです。すべてのバグは問題ですが、すべての問題がバグであるとは限りません。
通常、バグはコードベースの欠陥です。これは、不完全な/まだ実装されていない機能や、開発者が技術的負債の一部に対処するためにチケットを提出したり、UI に関する懸念のように特定するのが難しいものとは異なります。これらはすべて、意味的に言えば「問題」です。
一般的な問題は、他のカテゴリに該当しない場合でも、多くの場合、エンド ユーザーから報告された問題を表しています。ほとんどのシステムでは、この報告された問題は、それ自体がバグ レポートとして処理されます。これは間違いだと断言したい。
注意が必要なのは、複数の問題が他の問題に関連している場合があることです。同じバグ、複数のバグ、または実際には機能要求に関するものである可能性があります。つまり、課題間に多対多の関係が存在する可能性があります。
なぜ区別が重要なのですか？内部には自然なツリーがあります。1 つの問題を解決すると、他の何百万の問題も間接的に完了 (または完了に貢献) する可能性があります。また、問題の解決方法にも違いがあります。欠陥自体は、コードを変更して修正するか、無関係にすることで解決される場合があります。ユーザーからの苦情の場合は、回避策を送信することで解決できますが、元の欠陥が解決されたときにフォローアップする必要があります。
これらのニュアンスを便利な方法で表現して操作するのに適した機能は、実際にチケット追跡システムで探すべきものです.
ある時点で、あなたは実際の発券システムよりもプロセスや方法論について話しているので、物事の実際の名前は無関係になり始めるはずです。主流およびエンタープライズ指向のソリューションは、ITIL などの一般的なシステムで実行される傾向がありますが、チームの全員が顧客サービスのニーズをよく理解している場合は、その場しのぎのもので済ませることができます。個人的には、ウォーターフォール (ITIL) 対アジャイル (DevOps)の状況だと考えています。
于 2009-06-02T20:46:40.647 に答える
5
それは単なるセマンティクスです。バグは問題であり、問題はやるべきことです。それ以外はほとんど同じです。
于 2009-06-02T19:46:07.553 に答える
4
それはせいぜいあいまいな線です。問題追跡システムは、おそらく2つのうちのより一般的なものと見なされます。すべてのバグ追跡システムは問題追跡システムですが、必ずしもその逆ではありません。
私たちの友達ウィキペディアから
バグ追跡システムは、品質保証とプログラマーが作業中に報告されたソフトウェアバグを追跡するのに役立つように設計されたソフトウェアアプリケーションです。これは一種の問題追跡システムと見なすことができます。
于 2009-06-02T19:47:12.573 に答える
4
コードにバグが見つかりました
問題は、プロセス、ハードウェア、人のどこにでも見られます。
定義の意味については、採用している開発プロセスによって異なります。
于 2009-06-02T19:47:33.977 に答える
3
バグはコードで修正できるものだと思いますが、問題は使いやすさの問題です。
たとえば、ログインフォーム。ログインフォームのバグは、ログインが完了した後にフォームが正しくリダイレクトされないことです。問題は、全体的なログインプロセスが遅すぎること、または忘れたパスワードを電子メールで送信するオプションがないことです。
于 2009-06-02T19:46:05.290 に答える
3
この質問に答えるにはコンテキストが必要であり、見た目からすると、アランの答えはあなたのコンテキストに対するものでした。
ソフトウェア テストの世界では、問題とバグを区別します。バグとは製品の価値を脅かすものであり、問題とはテストの価値 (またはプロジェクトとプロジェクトの価値) を脅かすものです。特にテストの価値）。 ラピッド ソフトウェア テストは、そのことを教えてくれます。
私の経験では、追跡システムを使用すると、この 2 つを任意に区別できます。特定の追跡システムをどのように使用するかは、あなた次第です。
于 2012-03-30T00:22:36.237 に答える
3
これはあなたの質問に対する完全な回答ではありませんが、顧客との取引に関して同様の質問がありました。最高レベルでは、バグ追跡システムは通常、より開発者に焦点を当てているようです。つまり、開発者はコードの問題を追跡しようとしています。関数が正しい値を返していない、さらに検証を行う必要がある、など。
コードとうまく統合されたシステムの良い例はTracです。
問題追跡システムは、より顧客中心のようです。たとえば、顧客に「[OK] をクリックするとエラーが発生する」と言ってもらうことができます。これは、ユーザー トレーニングかもしれませんし、機能かもしれませんし、実際にはバグかもしれません。
そのため、私が取り組んできた多くのプロジェクトでは、これらを明確に区別しています。バグ追跡システムで実際のバグが作成される場合と発生しない場合がある高レベルの問題追跡システムがあります。ただし、多くのバグは、問題追跡システムで「問題」が作成されることなく、内部で追跡されます。
これら 2 つの間に見られる問題は、経験の浅いユーザーがTracのようなものにチケットを入力するのは、技術用語に混乱するため、実際にはそれほど簡単ではないということです。ただし、高レベルの問題追跡システムはコードと緊密に統合されていないため、開発者にとっては役に立ちません。
とにかく...私の$ 0.02。
于 2009-06-02T19:49:54.440 に答える
2
決定的な答えがあるとは思いませんが、私は通常、Issue Tracking を単なる「バグ」以上のものに対応する、より一般的な用語として考えています。「バグ追跡」という用語だけを使用することは、ソフトウェアの欠陥に関連する鳩の穴のようなものです。
イシュー トラッカーは必ずしもソフトウェアに関連付ける必要はありません。また、BugZilla でさえ、バグだけでなく、新しい拡張機能や機能のリクエスト、投票なども追跡します。そのように、私は「イシュー」を単なる誰かが「やり遂げたい」関心のある単一の項目。
最近では、「課題」よりも低いレベルの作業項目の追跡 ( Visual StudioやIBM/Rational Jazzなど) も増加しています。完了。より高いレベルでは、 BugZillaのマイルストーンに似たものも表示される場合があります。
于 2009-06-02T20:21:36.140 に答える
1
バグはソフトウェア開発者に固有のものです。問題はより一般的であり、グラフィックデザイナー、システム管理者、会社の幹部など、プロジェクトに関するすべてのチームメンバーの進捗状況が含まれる場合があります。
課題追跡システムは、やるべきことについて話し、必要に応じてアイテムをバグとして分類できます。
ほとんどの場合、ばかげた言葉ですが、プログラマーではない多くの人と仕事をしているので、「課題追跡システム」を使用します。お互いが何をしているのかを認識できる共通の生産性ツールを使用して、共通の言語を話す必要があります。 。
バグトラッカーを使用することはできますが、特に開発者が自分のタスクをバグであると考えなければならない場合は、開発者以外の人を混乱させるだけです。
バグは通常、既存のコードの問題であり、問題は新しい機能の要求である可能性があるため、バグとプログラマーの問題を区別することも良いことだと思います。
于 2009-06-02T20:06:21.443 に答える
0
まあ...問題は単なるバグ以上のものであるという事実以外に違いはありません。それは、タスク、新機能、または単に改善である可能性があります。バグは主に不適切なシステム動作として見られますが、問題はより広い定義を持っています。「うまくいかない」だけでなく…
于 2009-06-02T20:29:53.190 に答える