時折、構成を変更したり、ロジックの一部を無効にしたりすることで修正できるバグが本番環境で発生します。
私は上司に、バグをローカルで再現して修正が機能することを確認する必要があると主張しました。さらに重要なのは、開発者と QA がこれらのケースのチェックを通常のリリースの一部として含めることができるようにすることです。
私のマネージャーは、ソリューションが機能するため、ローカルで再現する必要がないため、時間の無駄だと考えています。
では、修正を確認するためにローカルで再現する必要がありますか? あなたが私に同意する場合、この点を私のマネージャーに売り込む方法についての指針はありますか?
バグを再現していない場合、「修正」は推測にすぎません。
私の頭の上から：
私は、経済的に実行可能な場合は、バグを再現することを強く信じています (たとえば、環境を再現するためだけに、一部のユーザーのハード ドライブ全体をローカル マシンにコピーしないなど)。
バグの残念な性質は、多くの場合、バグを修正する方法は 1 つしかなく、それを隠す方法は多数あり、多くの修正では実際に修正するのではなくマスクすることです。根本的な原因が見つからない可能性があるため、バグが再び発生するか、後で別の一見異なるバグが発生する可能性があります。
それが起こった例を見つけることができれば (たとえば、同じ根本原因による 2 つの無関係なバグ)、上司を説得できるかもしれません。
バグの性質も問題です。
単体テストで欠陥を迅速に再現できるか? その場合、修正に取り組んでいる開発者は、上記の単体テストを作成し、それをより完全な回帰スイートに統合する必要があります。これにより、将来の作業で欠陥が再発しないことが保証されます。
プログラムで (たとえば、Perl または Python スクリプトを使用して) 欠陥を再現できますか? もしそうなら、QA チームはおそらくそれをカバーする自動化されたテスト ケースを用意し、すぐに検証に使用できるはずです。
一連の段階的な手順に従って、欠陥を再現できますか? その場合、QA チーム (または最初にバグにフラグを立てた人) は、再現のための絶対的な最小ステップ数を提供する必要があります。
これら 3 つの原則は、私のテスト チームで QA プロセスを推進するのに大いに役立ちます。
通常、開発者自身が欠陥を再現することが最善の利益になります。これが不可能な場合 (ハードウェア リソースの不足など)、QA (または最初にバグにフラグを立てた人) と直接協力することが次善の策です。一部の欠陥は十分に明らかですが (メニュー オプションのスペル ミスなど)、アプリケーションの基本的な状態を知っている開発者が発見できる重大な結果をもたらすものもあります。
開発者に欠陥を再現してもらい、実際に欠陥であることを確認することも役立ちます。テスターは必要不可欠ではありますが (ソフトウェア テスターとして言えば ;))、多くの場合、アプリケーション コードの詳細な知識が不足しており、動作が期待 (または仕様) に準拠していない理由についてしっかりと理解していない可能性があります。
ローカルで再現すべきではない唯一のケースは、それが不可能な場合です。大量のデータ、独自のデータ、ハードウェアが必要な場合もあれば、より複雑なセットアップが必要な場合もあります。
社内でセットアップを複製できなかったため、何度かやらなければなりませんでした。(一部の開発作業はクライアントのシステムで行われていました。) クライアントは最初から、私たちが再現できる範囲を超えていることと、これによって引き起こされたバグに対処するのが面倒になることを知っていました。
テスト駆動開発の背後にある基本原則は、何らかの機能を実証するテストを用意することです。
この場合、バグを示すテストを作成します。テストは失敗します。
あなたはバグを修正します。テストに合格します。他のすべてのテストと同様に。他の問題を引き起こすことなく、実際にバグを修正しました。
この質問に対する適切な回答はたくさんありますが、そのほとんどは状況の経済性について直接話していません。これはおそらく、マネージャーに影響を与える可能性のある主なものです。
再現しない場合は、
リスクを軽減するための労力のトレードオフを比較検討することは、状況によって大きく異なります。つまり、作成しているソフトウェアの種類、顧客の数、本番環境での「悪い」バグの程度 (たとえば、販売サイトがダウンして損失を被ったかどうかなど) です。 1 日あたり 100 万ドルか、それとも Web フォーラムがダウンして、オンライン チャットを明日まで待たなければならないか)、テストの自動化の量 (バグを再現/後退させる労力に影響します)、...
多くの (ほとんどの?) マネージャーはリスクを嫌うので、説得に関しては、さまざまなリスクを説明するようにしてください (他の機能の後退、実際には修正されない修正の展開 (そして顧客にはばかげているように見える)、... ) だけでなく、そのリスクを軽減するために費やす必要がある労力 (再現して修正に自信を持つためのコスト) を見積もることもできます。
あなたは急いでいますか？その場合は、エラーを再現してください。これにより、さらなる問題を防ぐために必要な整然とした考え方が生まれます。再導入された古いエラーを発見するには、他にどのような方法がありますか? エラーを再現すると、他の人の注意を引くことができます:
グッドマネージャー：「何をしているの？」
Good Developer : 「またエラーが発生しました。再生できるようにテスト環境を再構築しています。」
良いマネージャー: 「なんてこった? Dave がそれを修正したと言ったと思っていたのに? ねぇ Dave、そのエラーを修正しなかったの? なぜ私たちはこれでまた時間を無駄にしているの?
対：
お尻のマネージャー：「何をしているの？」
Good Developer : 「またエラーが発生しました。再生できるようにテスト環境を再構築しています。」
Ass-hat Manager : 「いいえ - 時間がありません。修正して元に戻してください。ミーティングについてのメールに返信しましたか? 私は行かなければなりません - スティーブと 10 にならなければなりません。いいです。ああ、それを元に戻します。 、そしてそのメールを送ってください。」
ディレクターとして、私はすべてのチームに「今日は時間を取って」正しく処理するように伝えているので、真夜中に起きないようにしています。
しばらく前に、バグを再現するだけでなく、修正後にも推奨するデバッグに関する優れた本を読みました。
その理由は、バグを修正しようとしてかなり苦労する可能性があるためです。これにより、バグを修正したことを知ることができます。修正したことがわからない場合は、まだ壊れている可能性があります。
(先日、このようなケースに遭遇しました。関係のないように見えるコード行が、Web サイトの動作を奇妙にしていました。コード行を削除すると、サイトは機能しましたが、コードを挿入すると、サイトは機能しました。 , サイトは問題ありませんでした. しかし、それは単なる偶然であることが判明しました. サイトは、私が何をしても、ログインとログアウトが微妙に行われていたため、1回おきに正しく機能しませんでした. あなたの修正が本物であることを知っておく必要があります修理。）
編集： 私は、修正されたと主張されていたが修正されていないバグについて所有者が非常に不機嫌になった場所で働いていました。これは、私 (または別の開発者) がバグを再現できたとしても、テスターが作成したのとまったく同じ方法で再現できなかったために発生しました。バグを再現するだけでなく、テスターが行ったのとまったく同じ方法でバグを再現していることを確認する必要があります。
(ただし、最初に自分で試してみたい場合は、先に進んでください。別のバグが見つかるかもしれません。その後、バグの作業を開始する前に、テスターに再現を実演してもらいます。)
常にTRYする必要があります。それがバグなのか、エラーなのか、欠陥なのかを特定する必要があります。問題を理解せずに、問題を修正または軽減するにはどうすればよいでしょうか?
レコードまたはテスト スイートについては、どのように解決されますか?
「修正済み」、「オープン」、「再現不可」、「修正予定なし」、「機能」のステータスは適切ですか?
再現できない場合でも、決定を下す必要があります。/dev/null に漂流させることは、戻ってきて噛むことを求めています。
バグをローカルで再現しなければならない最も重要な理由は、バグを修正する際に他のことをしないようにすることです。修正が単なる構成または再コンパイルを必要としないものである場合、コンパイルされたものはすべて既にテストされているはずなので、この引数はあまり強力ではありません。
マネージャーがこの点を理解していない場合、バグを修正すると実際に何かが台無しになり、ローカルでバグを再現するよりもさらに遅れが生じる実際のケースを示す以外に、マネージャーを説得するためにできることはあまりありません。 .
これに対する答えは、バグのテスト方法に依存すると思います。
上記の質問に対する答えが全面的に「はい」でない限り、バグ修正が行われたことを確認するためのチェックを組み込むことは、退屈で骨の折れる作業です。また、これらのチェックを組み込むために時間を割くようマネージャーを説得するのも難しいでしょう。
自動化されたソリューションに時間を費やす場合、バグを解決するための最初のステップは、ローカルで問題を再現するテストを作成することであるため、これらのテストをビルド プロセスに追加することは簡単です。
私のプロジェクトでは、ソース管理に Subversion、アクティビティ管理に Jira、ビルドに Hudson、テストに Fitnesse と MSTest を使用しています。これらはすべて、継続的インテグレーションを使用して結び付けられています。Fitnesse は受け入れテストを行い、MSTest は単体テストを行い、ビルドが実行されるたびに自動的に実行され、ビルドがどの程度「良好」であるかを定量的に示します。
バグを修正するためにバグを再現しないという考えは、奇妙に他なりません。
結局のところ、再現できるようになるまで、何かが問題であると確信することはできません。それまでは単なる推測です (十分な情報があったとしても、それはまだ推測です)。
再現性は単にバグを見つけたかどうかの問題であるため、単体テストを行うかどうかはこの議論には関係ないと思います。単体テストは、間違ったことをテストしている場合、誤った仮定に取り組んでいる場合、または実際に何が起こっているかについての (おそらく漠然とした) バグレポートを単に誤解している場合には役に立ちません。
そのため、問題を再現します。
単体テストが解決策であり、それらを使用すればバグを再現する必要がないというのは良いことですが、実際には機能しないと思います。彼らが現場でバグを再現していないということは、再現はおそらく簡単ではないということです。これはおそらくソースが複雑であることを意味します。問題が単体テストで表現するのが簡単な場合、その単体テストはバグの再現になります。再現していない場合、単純な単体テストを作成できない可能性があります。
バグを再現していない場合は、真に理解していません。システムのバグを見つけたとしても、顧客が見ていたバグを発見したとは限りません。
バグを再現できない場合、それが本当に修正されているかどうかはわかりません。根本的な問題ではなく、問題の症状のみを治療している可能性があります。お客様は、同じ主要な問題に対して別のベクトルを持っている可能性があり、その問題は解決されません。
はい、可能/実行可能な場合; 回帰テストを参照してください
ほとんどの場合、再現したバグが顧客が経験しているバグと同じであることを知ることはできません。そのため、再現は問題が実際に修正されていることを保証するものではありません。
たとえば、私が取り組んでいたプロジェクトで顧客がコミュニケーションのバグを経験したとします。コードを調べて、考えられるバグを修正しました。バグの 1 つは PIC マイクロプロセッサの ASIC バグに関係しており、チップの正誤表は私たちが実装した回避策を提供しました。その後、同僚の 1 人が極端な手段を講じてバグを再現し、顧客の問題はおそらく修正されたと主張しました。
そうではありませんでした。
最終的に、多くの防御的なコーディングを追加したため、顧客は二度と問題を経験することはありませんでした。どの修正が問題を解決したのか正確にはわかりません。お客様が抱えていた問題を知り、再現できれば素晴らしいことですが、結局のところ、それは問題ではありません。重要なのは、ソフトウェアが機能することだけです。
したがって、バグを再現して問題の原因を深く理解できることは素晴らしいことですが、バグを再現してもお客様の問題を解決できる保証はありません。動作するソフトウェアの方が重要です。
あなたの職場は、スペクトルの「何も再現しない」端に行き過ぎているように思えます。少し余分な作業を行うことで、はるかに信頼性の高いソフトウェアを作成できるのは残念です。この投稿では、スペクトルの反対側もそれほど優れていないと主張したので、その中間の何かを推し進めようと思います.
私は上司に、バグをローカルで再現して修正が機能することを確認する必要があると主張しました。さらに重要なのは、開発者と QA がこれらのケースのチェックを通常のリリースの一部として含めることができるようにすることです。
開発者とチェックを含む QA に関する部分に特に同意します。これは、日本人が自働化と呼んでいるもの（「自動化と人間のタッチ」の略）の一部です。
[...] 自動化は、不良品の生産を防ぎ、過剰生産を排除し、問題を理解し、再発しないようにすることに注意を向けます。これは、次の 4 つの原則を適用する品質管理プロセスです。
- 異常を検出します。
- 止まる。
- 即時条件を修正または修正します。
- 根本原因を調査し、対策を講じます。
再発を防ぐための対策があります。これが、ポカヨケ（間違いのない）プロセスを構築する方法です（そして、欠陥を発生させるプロセスは欠陥プロセスです）。優れた管理者はそれを取得する必要があります。
愚かなことを理由にマネージャーをクビにして、彼の仕事を手に入れてみてください。それはチャンスかもしれません!
すでに書かれていることを繰り返すかもしれませんが、はい!!! 根拠は、バグを 1 回だけ見つけることです。バグを再現するテストを書くことができれば、手動で再度テストする必要はありません。自動化されたテストがバグを見つけてくれます。
そのため、バグを修正すれば、ソフトウェアがこのバグに二度と悩まされることはないという知識で安全になります. これはいい。時間を節約できます。それはあなたのお金を節約します。
フィールドからのランダムなクラッシュの場合、それらを再現できない場合があります。Microsoft の Windows エラー報告サービスによって収集された事後分析クラッシュダンプを使用して、まれな競合状態と「不可能な」クラッシュをデバッグしました。Microsoft の第一人者 Raymond Chen は、これを「サイキック デバッグ」と呼んでいると思います。
あなたの会社が Windows ソフトウェア (C++ または .NET) を公開している場合は、Microsoft の Windows エラー報告 (WER) サービスを使用することを強くお勧めします。商用ソフトウェア会社であっても無料です。独自のエラー報告とクラッシュダンプ収集サービスを作成するよりも簡単です。WER はすべてのスタック トレースを照合することもできるため、どのクラッシュが重複しているかがわかります。これは、何千もの重複したクラッシュをデバッグしたくない場合に役立ちます。:)