再現可能なテストケースが存在しない場合、バグを回避しますか？
顧客が、行ったアクションが複雑なために再現できない問題があり、段階的に覚えられない場合、プログラマーはテストケースを見逃しています。
確かに、この問題は本物であり重大であると思われるので、そのようなバグを回避することは正しいと思いますか？ここで何が問題になっていますか？私にとっては、コードが複雑すぎるため、プログラマーがすべての依存関係を確認できないように見えます。彼らは、コードが間違いなく正しいとは本当に言えません。
そのような状況でどのような振る舞いが望ましいと思われるかを教えてください。ちなみに私の会社のプログラムは、Delphi（スタンドアロンとウェブ）で作られた技術選択ソフトウェアです。
ここでの答えは、あなたの組織とそのプログラマーが何をしたいかによります。何百万人ものユーザーが使用する大規模で複雑な製品を提供している会社（たとえば、Microsoftですが、その会社が実際に社内でどのように機能しているかはわかりません）の場合、バグに注意を払う時間がない人がいるかもしれません。再現する手順はありません。あなたが小さな店なら、誰かが最終的に座ってバグを再現しようとする時間が少しあるかもしれません。
あなたは潜在的にバグを再現しようとする可能性があり、バグレポートで再現する手順を提供できる立場にありますか？もしそうなら、あなたには時間があり、あなたはそのルートに行くことを望むかもしれません。
そうでない場合は、「バグを再現できない」などのステータスをすぐにマークする場合でも、少なくともバグ追跡システムにバグを記録することをお勧めします（そのうちの1つはありますよね？）。これにより、数ヶ月後に同じクライアントまたは別のクライアントで同じバグが発生した場合、バグの修正に役立つパターンを見つけることができます。
最後に、残念なことに、一部のバグは人員による修正にかかるコストに見合う価値がないと考えられます。このバグが孤立したインシデントを表す場合、またはクライアントのごく一部に影響を与える場合、特に利用可能な回避策がある場合は、ビジネスの観点から修正する価値があるとは見なされない可能性があります。
これがお役に立てば幸いです。
番号
お客様->「この問題があります」
開発者->「再現できないので存在しません」
すみませんが、それは受け入れられるではありません。さらに、アプリケーションのクリティカルの一部である場合はそうです。
バグを無視することは「砂の頭」のアプローチが必然的に長期的にはマイナスの状況につながります。
まず第一に、あなたの修正が実際に問題を修正することを保証することができないので、それを再現することができない場合、あなたはバグを修正することができません。
これは、後で状況を再現できるときにできるだけ多くの情報を得るために、後で情報を保持する必要があるため、問題を回避する必要があるという意味ではありません。つまり、課題トラッカーで「再現不可」としてマークします。
いくつものルートがあり、コストと利益のバランスにかかっています。
1つの可能性は、複製を容易にするために、いくつかのロギングおよびトラッキング機能を配置することです。すると、今はバグを再現できないかもしれませんが、おそらく数週間または数か月で、問題が明らかになる可能性があります。
2番目の可能性は、情報を回復して保存する手順を実行すること、失われた情報を検出して復元する方法です。
顧客が支払っている場合は、再現不可能な問題の調査に時間がかかることを説明できます。次に、お客様は調査して解決する価値があるかどうかを判断する必要があります。 （これは、顧客が実行する複雑なアクションが予測されなかった場合に当てはまる可能性があります。）
たとえ顧客が支払っていない場合でも、それを解決することを約束できないことを説明できますが、その影響を最小限に抑えるよう努力することを約束できます。
再現が難しいバグを無視できるかどうかは、開発しているソフトウェアの種類によって異なります。ビデオゲームを開発している場合は、おそらくこれらの問題を無視するでしょう。あなたはすでに顧客のお金を持っています、そして問題が製品の評価に影響を与えないほど十分にまれである限り、なぜわざわざ。スケールの反対側で、この「まれな問題」がお金の損失または人命の損失さえも意味する場合は、間違いなく調査する必要があります。リピーターがいて、ハッピーにしたい場合は、おそらくそれも検討するでしょう。
問題を解決することが理にかなっていると判断した場合、最初のステップはおそらくコードを変更して問題に関する詳細情報を取得することです。たとえば、おそらくバグの理由であるコードにログを追加します。
会社のバグ修正プロセスを説明するものはありますか？たとえば、どのようにバグが開発者に割り当てられているか、状態の変更（つまり、正式なテストチームまたはある種の正式なリリースサイクルへの移行）を呼び出すために「十分に修正された」とは何ですか。軽量プロセスの会社で働いている場合でも、誰かがバグをシステムに出入りさせる方法のフローチャートを描くことができるはずです。多くの場合、これがどのように機能するかの説明は、バグをどうするかについての洞察を提供します。ほぼすべてのバグ修正プロセスには、開発者がバグを拒否する何らかの方法があります。これは、重複、または以前に導入された修正の副作用として修正されたバグになる可能性があるためです。
通常、重大度の評価もあります-重大度の高いバグ（システムをクラッシュさせたり、回復不能なエラーを引き起こしたり、機能が完全に機能しなくなったりする）には、通常、重大度の低いバグよりもさらに注意深く修正する必要があります。バグを再現できず、それによって顧客の速度が低下しなくなった場合は、重大度を下げて、「いつか修正するが、今日は修正しない」プールに入れることができるかもしれません。 。これには、より多くの情報を提供するために他の同様のバグが発生した場合に備えて、まだ有効であるという利点があります。
また、顧客と一緒にバグを追跡するためのプロトコルは何ですか？お客様と直接やり取りする機会はありましたか？時々、相互の合意がバグを断る理由を与えるのに十分です。
あなたがかなり新しい開発者である場合、これはあなたの経営者に尋ねるのに完全に適切な質問です-彼らはあなたとそれについて話し合い、あなたが試したことを聞いて、あなたに何をすべきかについて判断を下すことができるはずです顧客の性質とバグの両方の。
再現可能なテストケースは、バグが実際に存在する証拠です。証拠のないバグレポートは、噂に過ぎません。これは実際のバグである可能性があります。または、ユーザーエラー、システムのハードウェアの問題、またはRAMのどこかでビットを反転する宇宙線でさえも発生する可能性があります。
バグレポートを受け取り、コードベースに精通している場合、一般的には、「Xを実行しようとしたが壊れた」タイプのレポートから、何が起こっているのかをよく知ることができます。そうでない場合は、次のいずれかの詳細情報を要求します。
- 該当する場合、自動エラーレポート。 （あなたは例外ロガーを持っていますよね？）
- 再現手順の詳細なリスト。
- データのコピー
- 他のすべてが失敗した場合、オンデマンドで問題を再現するユーザーの能力を示すスクリーンキャップビデオ。
これらのいずれかを使用して、バグが存在するという確かな証拠を得ることができれば、コードを掘り下げて追跡を開始するための出発点となります。しかし、バグをオンデマンドで再現できない場合はそしてユーザーもそうではありません場合、実際にバグが存在するという証拠がないため、修正するためにできることは何もありません。最初の場所。これが「申し訳ありません、私はあなたを助けることはできませんが、一貫してそれを実現する方法を思いついたら、バグレポートを遠慮なく更新してください」と私が言うポイントです。
ありがたいことに、それほど頻繁に行う必要はありません。
バグを記録します。それについて可能な限りすべてを文書化します。それが起こったとき、彼らは何をしていましたか。 <-見つけることができる場合、これは重要です。 （それが起こったときも問題になる可能性があります。）
その後、コードのセクションで作業すると、誰かが「潜在的な」バグを見つけるでしょう。
そして、それはバグ追跡システムに追加されます。そして、その開発者はバグについて考えます。その投影された外観。そして、最終的に2つのバグは同じバグとして識別されます。
実話
再現する手順のない多数のバグがある場合、それらはデータポイントです。
これはあなたに言います：そこにバグがあります。
それらは頻繁には起こりません。
したがって、後で実際のコードにバグが見つかった場合は、すでに持っているデータポイントに適合する可能性があります。
Googleの「データマイニング」...バグトラッカーは、バグの場所をすでに知っているかもしれません
以前は再現できないバグがありましたが、最初にできることは、ロギングを追加してコードを10,000行以内に絞り込むことでしたが、数回繰り返した後、修正可能になりました。
また、ヒットできないはずの状態のバグも確認しました。この不可能な状態を明示的に確認し、スタックトレースをログに記録して、segfaultingの代わりに正常に戻ることしかできませんでした。根本的な原因が何であるかはまだわかりませんが、現時点ではどの顧客にも影響を与えていません。影響がある場合は、それを修正するための詳細情報を入手できます。
somethingがなかったバグは一度もありませんでした。答えに近づくためにできることがありました。お客様が保持できるコードを追加したことだけでお客様がとても喜んでいますそれが再発した場合に彼らが傷つきすぎないようにし、次にそれを理解するのに役立つより多くの情報を提供するためのコード。
この場合、どれほど重要ですか？
私たちのケースでは、重大なバグがあり、クライアントが私たちの製品にたくさんのロット（tm）を支払うことを考慮して、クイックフィックスチーム（2 ppl、テスト+開発者）を作成してそれを見つけ、スキッシュしますそれ。
それ以外の場合、再現できない場合はno reproとして閉じられます。他の人が言ったように、再現手順なしで、暗闇の中で推測して撮影しているだけです-私たちはそれに取り組むために他の重大なバグをたくさん持っていますcan修正します。
これは、重大度と確率という2つの要因に依存します。データの破損やセキュリティ違反などのバグが致命的である場合、顧客のビジネスに潜在的な損失を引き起こす可能性があるため、バグが見つかるまで掘り下げて修正する必要があります。それが致命的ではないが非常に可能性が高く、顧客を苛立たせ続ける場合、ユーザーが低品質のバグのある製品であるとユーザーが言う製品の評判を台無しにして組織に問題を引き起こすため、それを見つけなければなりません。それが極端なコーナーケースであり、データに害を及ぼさず、まれにしか発生しない場合は、無視してかまいません。
また、これらのほとんどの場合、開発者はテスターと協力してバグを検索する必要があります。バグを1人で見つけるのは難しいためです。