バグ トラッカーには多くの機能がありますが、少しやり過ぎだと感じ、独自のソリューションを展開することを検討していました。そうは言っても、既存のソリューションで頻繁に使用される可能性のあるコア機能を削除したくありませんでした。
これまでに考えられるもの: - バグの作成 - バグの割り当て - バグのクローズ - バグへの説明の追加
ありがとう！
3164 次
13 に答える
6
- 開発者とユーザーの間のコミュニケーション。
- 重大度 (そのバグがどの程度関連しているか) などの特定の情報をユーザーが割り当てる機能。
- 開発者がその優先度をオーバーライドし、可能であれば理由を示す機能。
- 開発者にタスクを割り当てる機能。
- バグ、機能強化、機能リクエストを分類する機能。機能強化と機能要求の違いは非常に微妙ですが、非常に重要です。
- ファイルを添付する機能 (スクリーンショットなど)
- カスタム フィールドを持つ機能 (OS、サービス パック レベル、アプリケーション バージョンなどを選択できるなど)。
- ハードウェアに関する詳細情報も提供するカスタム ユーザー プロファイルを持つ機能。また、必要に応じて質問できるように、ユーザーの電話番号 (LAN 上にいる場合) を取得できるのも便利です。
- プライバシー。セキュリティの悪用や財務情報を扱う情報など、一部の項目は秘密にしておく必要があります。OSS でさえ、パッチの準備が整うまで、時々これを行います。誰もが独自のルールを持っています。
- リビジョン間の変更を表示して、変更ログを電子メールで送信できるため、ユーザーは何を行って何を行っていないかを知ることができます。
- どのアイテムが取り消され、自分に割り当てられているか、またはまったく割り当てられていないかについてのリマインダー。
思いつくのはこれくらい…
于 2008-12-28T03:56:36.000 に答える
4
優れた検索エンジン。
数千ドルもするバグ追跡製品の多くが、これをひどく間違っているのは驚くべきことです。
本当にきちんとした検索がなければ、バグ追跡は「バグ ロギング」 (ログを取って忘れる) システムのようになり、ほとんど役に立たなくなります。
于 2008-12-28T05:37:19.400 に答える
3
- バグを作成する
- バグを閉じる
これは、「バグ」エンティティのライフサイクル全体を閉じるには十分です。それがあなたの目的に十分な機能であるかどうかは別の問題です.
Mantisの機能を見て、必要な機能を選択し、それらを作成するのにかかる時間を計算してから、どうしても独自の機能を作成する必要がない限り、より便利なものに時間を費やしてください。;-)
于 2008-12-28T04:36:19.947 に答える
2
バグ追跡システムのようなほとんどのシステムでは、通常、システムを便利にするのはデータの作成または編集ではありません。すべては、データを収集するだけでなく、いかに簡単に情報をナビゲートして「付加価値」を得ることができるかにかかっています。
システムを使用する人々、プログラマー、マネージャーなどについて考えてみてください。人々のグループごとに、どのような種類の情報がシステムに何度も戻ってくる価値があるかを考えてください。彼らがこの情報を入手しやすくするにはどうすればよいでしょうか?
情報を収集するのは簡単ですが、それに付加価値を付けるのは難しい部分です。
ポール。
于 2008-12-28T03:38:05.897 に答える
1
FWIW：独自のリクエスト追跡システムを導入したとき、非常に目立たないようにしたかったので、procmailと既存の内部Web認証システムを中心に構築しました。開発者に電子メールを送信するだけです（必要に応じてグループエイリアスを使用します）。 ）そして、件名に「[t]」を追加してチケットを開きます。受信者は、元のリクエストと、チケットを表示し、マウスを1回クリックするだけでチケットを閉じることができるWebページへの追加リンクを含む変更された電子メールを受け取ります。したがって、最も一般的なタスクは電子メールクライアントを介して実行されます（開く、詳細情報を要求する、返信するなど）。ただし、検索などのための単純なWebインターフェイスもあります。
書くのにほんの数時間しかかからず、7年かそこらで34000以上のリクエストチケットを受け取った後、それは本質的なコア機能だけを持っていると主張しても大丈夫だと思います。
- チケットを作成します（件名がマークされた電子メールで）
- チケットを閉じる（電子メールのリンクをクリックしてから、[完了]をクリックします）
- すべての通信は、Webインターフェイスではなく、電子メールを介して行われます（！）
- 元の電子メール（オープニングチケット）の受信者または送信者であった人は、閉じられたチケットについて通知されます（「件名：<古い件名>は<誰か>によって閉じられました」+本文内のチケットへのリンク、ほとんどの人にとって十分な情報なので、どのチケット/バグがあったかなどを見に行く必要はありません）
- シンプルなウェブインターフェースは、自分の/開く/送信した/チームチケットの検索機能を提供します
より大規模な開発チーム/より集中的なソフトウェア開発に必要となる可能性のある注目すべき欠如した機能：
- チケットの柔軟なステータス（重複、修正、再開など）
- 優先順位
- チケットを明示的に再割り当てします（私たちの開発チームでは、電子メールはそれをしなければならない不運な男に再送されます）
- 全員に送信されないコメントをチケットに追加する
- ソフトウェアの特定のバージョンにバグを割り当てる
YMMVですが、これまでのところ、バグと送信者が追跡したい単純なリクエストの両方で非常にうまく機能しています。
于 2008-12-28T04:52:17.247 に答える
1
いくつかの重要な機能を次に示します。
- バグに優先度を割り当てます (例: クリティカル、メジャー、ミディアム、マイナー、些細)
- バグが修正される特定のリリースにバグを割り当てる
- ウォッチャー機能 (ステータスが変更されたときに電子メールを受け取ることができるようにするため)
- ワークフロー (つまり、誰が作業しているか、ステータスは何か)
于 2008-12-28T04:37:05.577 に答える
1
分類、優先順位付け、および標準化。
そして、上記の 3 つのハードワークの成果を得ることができるように、クエリを実行する簡単な方法です。
また、何をするにも拡張可能であることを確認してください。私たちは、プロジェクトの進行中、ニーズや問題に応じて、バグ テンプレートを追加/編集することを常に決定しています。
優れたソリューションはたくさんありますが、おそらく独自のものを作成する必要はありません..しかし、どちらにしても同じ決定を下す必要があります. 独自のテンプレートを展開できるソリューションを使用しているため、すべてのプロジェクトの開始時に、この同じ議論を再検討しています。
于 2008-12-28T05:36:11.480 に答える
1
バグ トラッカーは、実行する必要があることのリストにすぎません。
ソフトウェアのディレクトリ内のテキスト ファイルから、何百人ものユーザーを抱える本格的なバグ トラッカーまで、シンプルなものにすることができます。
作業する必要があるものから始めて、必要に応じて拡張します。
于 2008-12-28T03:36:55.150 に答える
1
Jira を使用してください。
于 2008-12-28T03:37:43.870 に答える
0
私たちのバグ追跡システムは、私の会社とお客様の間の2つの重要なリンクの1つです（既存のお客様が改善を提案し、ユーザーインターフェイスの調整がもう一方である「ライブ」製品レビュー）。
バグ追跡システムは、何よりもまず、顧客との追跡可能な「ダイアログ」を促進する必要があります。「私がまだ抱えている問題（広く定義されている）を修正しましたか？」という質問に答える必要があります。
それは（順不同で）持っている必要があります：
- 問題または機能リクエストの簡単な説明（タイトル）
- 詳細な説明の余地
- ファイル/画像を添付する機能（スクリーンショット）
- バグ/機能に優先順位を付ける機能
- エントリをバグ、機能、問い合わせなどとして分類する機能。
- バグ/機能を領域（UI、データベース、ドキュメントなど）に割り当てる機能
- 製品にバグ/機能を割り当てる機能（5つの製品のバグを追跡します）
- バグ/機能をリリースに割り当てる機能（「バージョン5.1で修正予定」）
- バグ/機能を人々（開発者/ライター）に割り当てる機能
- バグ/機能を顧客（レポーター）に割り当てる機能
- 別の人（開発者）に再割り当てする機能
- バグ/機能を解決する機能（終了してテストの準備ができていることをマークします）
- 解決ステータスをマークする機能（修正済み、修正されない、再現できないなど）
- バグ/機能を閉じる機能（解決とテストの後でそれらをリストから外します）
- バグ/機能を再度開く機能（テストが失敗した場合は「開く」に復元します）
- バグが解決されたことを顧客に通知する機能（電子メールなど）
- すべてのステップの日付とタイムスタンプ（開く、解決する、閉じる、再度開く）
- 未解決のバグの数を報告する機能！（リリースにどれだけ近づいていますか？）
- バグレポートと解決策を表示する機能
- 日付、優先度、製品、人などでバグ/機能を検索する機能。
- 簡単にスキャンできるようにバグを一覧表示して並べ替える機能！
これらは、私たちのシステム（FogBugz）で通常使用するものです。これは長いリストのように思えるかもしれませんが、ここにリストしたすべての機能を実際に使用しています。
于 2008-12-28T05:20:14.723 に答える
0
「自分で巻く」ことに多くの時間を費やさないでください。あなたの時間は、実際の追跡システムを使用するための調査と学習に費やされたほうがよいでしょう.
見るべきいくつか
Trac、Bugzilla、FogBugz。最後の 1 つには、小さな (1 人または 2 人のショップ?) 企業向けの無料のホスト ソリューションがあります。
SOには、このトピックに関するスレッドがたくさんあります。
ワード ドキュメントやスプレッドシートでない限り、自分で作成しないようにしてください。自分で作成するのに費やす時間は、完全に無駄です。
編集
あなたが思いとどまることはないので、他の人が言及していないことをいくつか追加するかもしれません.
レポート機能が必要です。ユーザーはクエリを実行できる必要があり、「表示」するフィールドを選択できる必要があります。
欠陥のワークフロー/ライフサイクルも優れた機能です。(基本的には、欠陥が通過する状態のステート マシンです。) 実際、これは、すべてのユース ケースと機能を定義するのに役立つ演習です。あなたが大学生であり、CS 専攻としてスタートしたわけではないことを考えると、自分で多くのことを思いつくとは思えません。時間をかけて、既存の製品の機能リストとデモを参照してください。
さまざまな関係者に電子メールを送信する機能。
入力した特定の欠陥を表示できる匿名ユーザー
さまざまなアクセス レベルと権限 (管理者、マネージャー、開発者、テスター、エンド ユーザー)
于 2008-12-28T04:32:15.740 に答える
0
バグを定義します。
それについて考えると、おそらく「自分自身をロールバックする」ために多くの時間を費やすことになることに気付くでしょう.
于 2008-12-28T03:35:03.003 に答える
0
これはあなたが考えていたことを少し超えているかもしれませんが、私にとって、ソース管理との統合は必須です。バグ/問題に関連するバージョン間の差分を表示できることは非常に便利です。
于 2008-12-28T03:37:13.200 に答える