バグを再現する責任

私は別のプログラマーが作成したライブラリーを使用してプログラムを開発しています（彼は同じ会社で働いています）。最近、ライブラリのリークを発見しました。これは、数時間実行した後、特定のネットワーク条件下で発生します。このリークを発生させる条件の説明を記載したバグを提出しました。その開発者は、「これは十分ではありません」、「バグを再現するのは彼の責任ではありません」と答え、このバグを再現するためにユニットテストを作成する必要があります。

1. 彼は正しいですか？
2. この状況でできることは何ですか？ユニットテストの作成は、ネットワークのランダムなタイミングに依存するため不可能です。

彼が正しいのは、おそらくあなたの会社を知らないと答えることができない質問です。しかし、彼は確かにあまり役に立ちません。

私は彼と一緒にバグを上げます（あなたがやったことです）、それがあなたのプロジェクトで問題を引き起こしている場合、私はあなたのプロジェクトマネージャーと一緒にブロッカーとしてそれを上げ、あなたが適切にバグを上げたことを非常に明確にします人ですが、すぐに修正されない場合、プロジェクトに影響を与えます。

また、開発者と話をして、単体テストを作成することが実行不可能である理由を説明しますが、それをあなたのマシンで見せていただければ幸いです（実行可能だと仮定して）。

彼は、バグを再現可能にするために十分な情報を提供する必要があるという100％の権利を持っています。

しかし、彼はこれがユニットテストの形であるに違いないと私見100％間違っています。（少なくとも妥当な時間内に高い確率で、または手動テストによって）失敗を再現できる方法でテストシナリオを説明できる場合、問題が存在するという証拠があります。それを修正する責任において。もちろん、バグをより迅速に再現するシナリオを作成できれば、それは彼にとって役立つでしょう。理想的には、それから自動化されたテストを行い、それを担当する組織に依存します。

双方がいくらか努力する必要があります。

一部の問題は単体テストでは再現できないため、ライブラリ開発者は単体テストがなくても追加の努力をする必要があります。ハードウェアである場合もあれば、プログラムの残りの部分からの正しいアクションの特定のシーケンスである場合もあり、これによりライブラリーが悪い結果を生み出します。

これはやはりライブラリのバグではなく、プログラムの残りの部分からの不正なアクションの結果であるためです（たとえば、ヒープが破損するとライブラリの動作がおかしくなります）。したがって、バグの再現に関係する非ライブラリコードを可能な限り減らすことは理にかなっています。そして、アプリケーションのコードに不慣れな人よりも、これをより速く、よりきれいに行うでしょう。

ライブラリの作成者が報告に基づいてバグを再現できない場合、バグを修正することはもちろんのこと、多くの時間を費やすことを期待するのは不合理です。

しかし、関心のある製品に取り組む時間も限られています。残念ながら、これはバグが存在し続け、それを解決する作業が行われていないことを意味する場合があります。

幸いなことに、これは必ずしも災害ではありません-理想的な世界では、すべてのソフトウェアにバグはありませんが、そうではないため、米国が引き起こす問題に基づいて優先順位を付ける必要があります。

これは、修正したい場合に再現可能なテストケースを開発することは、実際にあなたの責任であることを意味します。あなたはそれが修正されるかどうか気にしないかもしれません、そして、その場合、あなたはあなたに期待することができる、そしてそうするべきすべてをしました。修正することもできますが、現時点で再現可能にするために時間をかけるだけでは不十分です。それは完全に受け入れられます。

バグを対処しなければならないときに能力を最大限に報告することは、単に良き市民権であり、プログラムで必要でない限り、それを超える必要はありません。そして、その場合でもそうすることを望まないかもしれません、あなたが使用できる別のライブラリがあるかもしれません、または合理的な期間であなた自身のものを転がすことができるかもしれません。基本的に、あなたにとって価値のある努力とその種類を決定するのはあなた次第です。

私は今のところ眠っている犬に嘘をつきたいと思うでしょう-あなたは問題を提起し、それは彼に割り当てられています。おそらく、未解決のバグを追跡し、それらを追跡するプロセスが用意されていますか？

これをさらに積極的に進めたい場合は、マネージャーに相談して、問題を確実に再現できるテストツールがあるかどうかを確認することをお勧めします。

開発者側から-あなたが必要な情報を提供したことを考えると、彼らが何もしないことは彼らにとって非常に不活性です。ただし、ワークロードが非常に大きいため、問題の追跡に必要な時間を費やすことができない場合があります。

あなたはバグを見つけ、それを報告し、彼はそれについて気まぐれです。

あなたの二人が親しい友人だったら、彼は何かをするために何かをしたでしょうが、彼はむしろ問題を押し戻すだけでした。

詳細を報告し、メモリリークが発生しているという主張をサポートすることで、さらに多くのことができます。それでも、あなたにはあなた自身の責任があり、あなた自身の仕事を終える必要があります。

できるだけ多くの情報をバグトラッカーに記録し、先に進みます。

将来この人に再び会ったら。友好的になり、共通の関心事について話し、良い関係が物事を修正するためのはるかに効果的な方法であることを理解し、それからあなたが主張をサポートするために提供できる事実の量を理解してください。

多くの場合、同じような状況で私が遭遇したことは、すべてのバグを修正するという仮定であり、それは賞賛に値するものの、間違いなく素晴らしい目標です（それに直面して、バグを書くことは決してありません！）、それは最終的に非現実的ですバグであるという理由だけでバグを修正するための適切なサイズのプロジェクト（見つけることができる場合！）

だから、図書館の所有者の防衛で私が言うことの1つは（そして私がいくつかの大きなプロジェクトに取り組んだときもそうでした）、開発時間はお金がかかり、有限のリソースであるため、レポートの処理方法に関する決定は、誰が調査し、どのテストを作成/必要とし、最終的に修正が実施されているかどうか（もしそうである場合）は、純粋にビジネスへの影響に基づいています。長時間実行されているプロセスが失敗した場合、たまにそれを再起動すると、それを簡単に自動化できますか（そして、おそらく防御的なプログラミング手段として既にあるべきではないでしょうか）、それはただの時間ですか、それ以上ですか？ ？

また、彼らの観点から見てください、コードと関連してのみ、おそらく1台のマシン上で、異常なタイミングのセットの下でのみ発生する、非常にまれなコードの予測不可能な問題の1人のユーザーからのバグレポート可能であれば、条件は開発時間の大部分を見つけて修正するための強力な正当化を持ちません。しかし、そのユーザーが時間をかけて徹底的に調査し、信頼できるテストケース/アプリケーションまたは根本的に詳細な問題の説明を最初の説明よりも提供するのに十分な強力なビジネスケースである場合は、他の完全なゲームとなる可能性があります。

これはおそらく、図書館の所有者がそのように考えていないコミュニケーションの問題であり、強力なビジネスケースがある場合（コードがビジネスに費用がかかる、法的コンプライアンス要件、セキュリティホール、または他の主要なノックオン効果）それから、経営者にそれをキックして、彼らにそれを戦わせます。

「このリークが発生する条件の説明を含むバグを提出しました」と述べました。

説明がバグを再現するのに本当に十分であると確信しているなら、あなたはすでに正確な条件を知っています。条件を知った後で単体テストを記述できない場合、関連するコンポーネントの一部をモックできないか、コードの一部が密結合して実用的な単体テストを作成できないことを明確に意味します。

ユニットテストを作成できるように、コードのリファクタリングをライブラリの所有者に依頼する必要があります。ユニットテストの作成を妨げるライブラリの内容を明確に説明する必要があります。彼はコードをリファクタリングする必要があります。そうしないと、現在のコードでは単体テストが不可能であることを認めます。両方の方法で、あなたは勝ちます。

これが機能しない場合、次のオプションがあります。

• より多くの証拠でバグを再現できます。
• より高い権威を巻き込み、あなたの証拠を評価するように彼/彼女に依頼してください。
• バグを再現するためだけにコーディングされるように、モック環境のプロトタイプアプリケーションでライブラリを使用してみてください。そうすれば、少なくともバグが存在することを証明できます。