自分自身を修正したと思われるバグに対処する方法は?[閉まっている]


16

私は、内部システムのWebアプリケーション開発者です。ユーザーがバグがあることを報告します。

バグは、いくつかの単語を表示できなかったことです。レポートには、バグを明確に示す画面キャプチャが含まれています。しかし、レポートはほぼ1か月前のものであり、バグを本番環境で再現することはできません。

クライアントとユーザーにどのように返信すればよいですか?



1
繰り返し可能にする方法を見つけてください。
ワイアットバーネット

2
この調査にどれくらいの時間を費やすことができますか?バグはどれほど重大であり、それはマイナスの影響ですか?答えが非常に小さく、無視できる場合、実際に修正されていない状況のメモで修正済みとしてマークし、戻ってくるのを待つことは、あなたの会社のリソースの完全に許容できる使用です。
ニュートピア

2
これは非常に標準的な定型的な応答を必要とします:「親愛なる[ユーザー]、Yで報告したXの問題は、Zの最新リリースで解決されたようです。もしそうでない場合は、これにあなたがどのように遭遇したかの詳細を返送してください。
リリエンタール

1
@Lilienthalバグを再現できないからといって、バグが解決されたわけではありません。あなたは先月に新しいリリースがあったことすら知りません。
パパラッチ

回答:


32

開発環境をバグが発見されたバージョンに戻し、バグがあることを確認します。

存在する場合は、バグを調査し、現在のバージョンにバグがないことを確認できます。次に、無関係な変更によって修正されたというコメントを付けてバグレポートを閉じます。必要に応じて回帰テストを追加します。

そのバージョンでバグを再現できない場合は、ここにある他の多くの質問で説明されている戦略が役立ちます(最初のリストについてはThomasに感謝します)。


2
私の経験では、ほとんどのチームはチケットシステムの「再現できない」オプションをチェックして閉じます。「then」および「now」コードをテストして、問題が存在し、もはや存在しないことを確認することは、より良い解決策のようです。しかし、「再現できない」と言って閉じるよりも時間がかかるため、すべてのバグの選択肢とは限りません。
ポールJアバナシー

5
バグの深刻度に依存します。レイアウトが単純な場合は、実際にスタンプを複製して実行することはできませんが、より不吉な場合は、リグレッションテストが完了するまでに数時間の価値があります。
ラチェットフリーク

2
@ratchetfreakまたは、この特定の顧客がどれほど深刻かによって異なります。彼らがあなたの給料に単独で資金を提供しているのであれば、おそらく彼らをユーモアにかける価値があります;
Cort Ammon-Reinstate Monica

7
自力で解消する問題は、自力で再発します。
ピートベッカー

1
それはすべてワークロードの問題です。1か月前に再現可能だったバグがもう1つあり、もう1つのバグが現在再現可能である場合、最初に再現可能なバグを修正します。あなたが完全に退屈している状態になったら、調査することができます。そして、問題がそれ自体で戻ってきたら、もちろんそれは再現可能なバグであり、あなたはそれを修正し始めます:
gnasher729

2

バグを再現するためにできることはすべてできたが、できなかったと真剣に考えていると思います。

このような場合、多くの場合、実行中の作業の記録に失敗したアプリケーションの領域にコードを追加することをお勧めします。現在入手できない情報を把握する必要があります。たとえば、特定の入力パラメータのセットが送信されたときにのみ発生する可能性があるため、プロセスが実行されるたびにそれらを記録します。ただし、これを行う前に上司に確認してください。バグの重要性と発生した頻度によっては、上司がこれを行うために時間を費やしたくない場合があります。

次に、バグを報告した人に行きます(バグ追跡アプリケーションがある場合はこれを行うことができます、直接行く必要はありません)、あなたはバグを再現できなかったが、いくつかの追加バグが再発した場合にプロセスが実行していることの詳細を取得するためのロギング。その後、バグを閉じます。

追加のロギングを実行できない場合。バグが再現可能ではなかったこと、そして再びバグに遭遇した場合、これはあなたがそれを再現し、必要なものを伝えるために必要な情報であると報告するだけです。多くの場合、エラーが発生したときに入力したパラメータを正確に伝えるように依頼します。エラーのスクリーンショットを取得するだけで役立ちますが、エラーが発生したときにどの手順を実行し、どの情報を使用しようとしたかを正確に把握しておくと、さらに役立ちます。したがって、基本的には、エラーが再度発生した場合にエラーを報告するときに、より多くの情報を提供するために、それらに責任を負わせます。

バグトラッカーで、どの手順を試したかを必ず説明してください。これにより、バグが再び発生した場合、それを処理する人は以前に行われた作業の背景を把握できます。


1

再現性のないバッグは最悪です!それはその間に修正されたかもしれませんし、まだ残っているかもしれませんが、散発的であるか、再現手順が十分に指定されていません。バグのリスクの高さ、および調査の範囲を拡大するかどうかを判断する必要があります。オンラインのレシピマネージャーを作っていますか、それとも核ミサイル用の操縦制御ソフトウェアを作っていますか?

影響の少ないバグであり、意図せずに修正された可能性のある変更が行われたことがわかっている場合は、再現できないという注意でバグを閉じることは許容される可能性があり、修正されたと仮定します。

より懸念がある場合は、最初にバグの原因についていくつかの理論を作成し、変更ログとソース履歴を調べて、それが修正された場所を見つけることができるかどうかを確認できます。

より深刻なバグについては、ソースを最後のリリースの時点までロールバックしてから、再現を試みる必要があります。正常に複製できれば、後のコミットで修正されることを確認するテストを作成できます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.