問題タブ [bug-tracking]

自動化によって表示される IE7/8 で明確な正方形のバグを見つけました (まだ回避策を探しています)。

そのため、このバグをログに記録する方法を見つけようとしましたが、うまくいきませんでした。フォーラムの方法を試してみましたが、このサイトは最近あまり活発ではないようです。

私はクリス・ウィルソンにメールを送ろうとさえしましたが、正直なところ、私はこの試みにあまり希望を置いていません ;o)

では、IE のバグを記録する方法を知っている人はいますか?

ありがとう、ヴィンセント

私の会社では、ソース管理と CR 管理に StarTeam を使用していますが、ソース管理を Subversion に切り替えたいと思っています。ClearQuest と ClearCase を知っている方のために説明すると、StarTeam にはチケットを作成する機能があり、後でコードの変更に関連付けることができます。

Subversion とうまく統合できる同様の製品はありますか (できれば無料ですが、商用アプリのアイデアに必ずしも反対というわけではありません)。しばらく前にtracをいじりましたが、あまり感銘を受けませんでした。

アプリケーションから未処理の例外をバグ追跡システム (この場合は Team Foundation Server ですが、任意のバグ追跡システムである可能性があります) に記録する「概念実証」アプリケーションを開発しました。この考えの制限は、同じ例外がスローされるたびに重複する Bug Items を開きたくないということです (たとえば、多くのユーザーが例外に遭遇しますが、それはまだ 1 つの「バグ」です)。

私の最初の試みは、例外タイプ、メッセージ、およびスタック トレースをフィールドとしてバグ追跡システムに保存することでした。次に、ロギング コンポーネントがバグ「ストア」に対してクエリを実行し、同じ情報を持つ未解決のバグがあるかどうかを確認します。(この例は .NET ですが、概念はプラットフォームに依存しないと思います)。

問題は明らかに、これらのフィールドが非常に大きくなる可能性があり (特にスタック トレース)、それらを格納するために「フルテキスト」タイプの実装が必要であり、検索に非常にコストがかかることです。

この問題に対してどのようなアプローチが定義されているのか疑問に思っていました。たとえば、FogBugz には自動バグ追跡機能があると聞いていたので、それがどのように実装されているのか興味がありました。

個別にリリースされた複数のアーティファクトに影響を与えるバグの変更やテスト作業をどのように追跡していますか?

コード共有は、コードを介したパスの総数を減らすため、優れています。つまり、より少ない変更とより少ないバグ (またはより少ない変更でより多くのバグに対処) でより多くの影響を与えることを意味します。たとえば、同じファイル処理パッケージまたはモデル パッケージを使用する検索ツールとインデクサーを構築する場合があります。

変更がすべての適切なコンポーネントでテストされ、どの変更がどのリリース済みツールに含まれていたかを追跡できるようにする必要があります。また、すべてのアプリケーションで同時に変更をリリースする必要はありません。

目標: 1 つのバグをテストし、リリースされた各アプリケーションに対して個別に追跡をスケジュールします。アーキテクチャを理解する自動化されたシステムにより、正しい選択を行うことができます。

バグ分割リリース シナリオ:

ユーティリティ ライブラリのパフォーマンス修正を含む検索ツールのパッチをリリースする場合があります。検索ツールにとって重要な修正プログラムは、インデクサーではあまり見えないため、次のメンテナンス リリースまで待つことができます。検索パッチで 1 つのバグをスケジュール、追跡、リリースし、インデクサーの次のメンテナンス リリースまで延期したいと考えています。

そのため、追跡システム (JIRA) でバグを作成すると、魔法のように複数のオブジェクトになるようにしたいと考えています。

• 問題を説明し、開発作業を追跡する主要な問題
• テスト作業を追跡し、影響を受けるアプリケーションごとにこの問題がどのようにリリースされたかを追跡できるようにする一連のタスク。

どの変更がどのリリースに影響を与えるかを知らずに、または人々に多くの重複したバグを入力させることなく、より多くのコード共有を促進するために、コード共有のユーザー エクスペリエンスを低労力で作成するにはどうすればよいでしょうか?

Eclipse から Linux ディストリビューションまでの大規模なプロジェクトは、この種の問題に直面しており、どのように解決したのか疑問に思っていることは確かです (次はそれらについて詳しく説明します)。

この種の状況を経験したことがある人はいますか?どのように対処しましたか?

私はバグ追跡自体を探しているわけではありません。しかし、ビルド ツールのようなものです。開発者として、コードをコンパイルまたは実行しようとするたびに、デバッグ出力をリダイレクトし、最も一般的に発生するバグ、解決にかかる時間などを記録できれば素晴らしいと思います。

このようなものはありますか？

現在、バグトラッカーとして Mantis を使用していますが、これにはかなりうんざりしています。開発者はより多くの SVN 統合を望んでおり、顧客はより簡単に操作できるシステムを望んでいます。

そのため、新しいバグトラッカーを探しており、現時点では Redmine を検討しています。ただし、デフォルトの設定では、望ましいワークフローと一致しないか、少なくとも Mantis よりも優れているとは言えません。

次のワークフローがあり、それに一致するバグトラッカーが必要です。

• バグが (多くの場合顧客によって) 報告され、「新規」と見なされます。これらのバグは定期的にレビューされ、承認されるか (バグである)、機能としてマークされ (顧客は多くの場合、料金を支払う必要があります)、金銭的な部分が解決されるまで延期されます。
• バグは開発者によって割り当てられ、処理されます。
• 完了すると、「レビュー準備完了」とマークされます (別の開発者による)。
• レビューされると、「レビュー済み」としてマークされます
• 「レビュー済み」としてマークされた場合、元の開発者は新しいコードをステージング環境に配置し、バグを「テスト準備完了」としてマークします (バグ報告者によって)。
• バグレポーターはバグを「解決済み」としてマークします
• 本番環境に置かれると、バグレポーターはバグをクローズします

もちろん、特に初期段階ではフィードバックが必要になることがよくあります。誰が次のステップに進む必要があるのか​​、誰にバグが割り当てられているのか (開発者) を区別する方法を探しています。また、お客様には簡単な GUI を使用して、担当者を自分のアカウントから開発者に変更するよう依頼するか、さらに難しい: サードパーティ (デザインエージェンシーと考えてください) は、通常のギの。GUIは、何をすべきか、どのオプションがあるかを表示する必要があります-それらを検索するのではありません。

このように機能するバグトラッカーの経験がある人はいますか? 私たちのワークフローは本当におかしなことですか? バグがどこにあり、誰がどのステップを踏む必要があるかを、関係者全員が理解できるようにするにはどうすればよいでしょうか?

最適なツールを求める質問がたくさんありましたが、機能を求める質問はありませんでした。本当に必要ですか? そして、あなたが本当に必要としなかった機能は何ですか?

(機能マトリックスでツールを比較していることに気付きました。最終的には、最も重要な 3 ～ 4 個の機能のみを使用し、残りはそのままにしておくので、嫌いなことです。)

タイトルが示すように、私は現在 1 つのプロジェクトを開始しており、プロジェクトのインフラストラクチャ (SVN、電子メール、バグ追跡、オンライン フォーラムなど) をレイアウトしようとしています。

では、Bugzilla か Mantis か。

PHP で書かれたTracに相当するものはありますか? SVN と統合された無料のものが必要です。SVN ソースをブラウズし、何らかのバグ追跡を行い、SVN の最近の変更を表示できるようにする必要があります。wikiは必須ではありません。

前もって感謝します。

私はキャリアのさまざまな時期に、ソースコード以外の開発プロセス（要件、テスト、設計）の成果物の欠陥を追跡するために協力したり管理したりするスタッフを奨励してきました。要求が驚き、混乱、抵抗で満たされるたびに。人々がその考えに抵抗するとき、私はいつも少しショックを受けるのは私にはとても明白に思えます。

この演習から得られるのは、バグが作成された場所とバグが見つかった場所（プロセスのどの部分）の図です。悪い要件を構築している場合は、それを認識し、それらを改善するために取り組むことができます。

ソースコードにない欠陥に関する情報を収集している人は他にいますか？