-
元のアドレス: なぜバグが修正されないのか
著者: Alan Page 氏、Microsoft のテスト エンジニアリング エクセレンス ディレクター、著書『How We Test Software at Microsoft』 (中国語訳は「Microsoft のソフトウェア テスト方法」) の共著者。
翻訳：ルー・ユエリ、ルー・メンヤン、ワン・ホン
最近、バグのある製品をリリースすることに驚いている人に出会うことが増えました。驚いたのは、これらの人々の多くがソフトウェア テスターであり、このことについてはすでに知っているだろうと思っていたことです。まず、Eric Sink の以前の (ただし優れた) 記事を読むことをお勧めします。このトピックにどれだけ貢献できるかわかりませんが、試してみたいと思います。
多くのバグは修正する価値がありません。 「あなたはテスターですか？」とあなたは私に叫ぶでしょう、「テスターは製品品質の守護者です。」もう一度繰り返しますが、（必要であれば）多くのバグは修正する価値がありません。 「その理由を教えてください。ほとんどの場合、バグを修正するにはコードの変更が必要です。そして、コードの変更にはリソース (時間) の投資が必要であり、リスクが生じます。それはひどいことですが、それは本当です。場合によっては、リスクと投資がはるかに遠い場合もあります」バグを修正する価値を上回るため、修正しません。
バグを修正するかどうかに関する私たちの決定は、「感覚」に基づいたものではありませんし、そうすべきではありません。私は意思決定を支援するために「ユーザーの痛み」という概念を使用するのが好きです。私は「ユーザーの痛み」を考慮し特定するために 3 つの重要な要素を使用します。
1. 重大度 - このバグはどのような影響を及ぼしますか - プログラム全体がクラッシュしますか?ユーザーの情報が失われることはありますか?それともそれほど深刻ではないのでしょうか？もっと簡単な解決策はありますか?それとも単に無関係な問題なのでしょうか？
2. 頻度 - ユーザーはこの問題に頻繁に遭遇しますか?それはプログラムの主要なワークフローの一部ですか?それとも、一般的には使用されない機能に隠されているのでしょうか?プログラムの最も一般的に使用される部分に存在する小さな問題はおそらく修正する必要がありますが、プログラムのあまり一般的に使用されない部分に存在するいくつかの大きな問題は脇に置かれる可能性があります。
3. 顧客への影響 – 下調べをしっかりと行っていれば、顧客が誰であるか、各顧客グループに何人のユーザーがいるか (または何人のユーザーがいると予想しているか) がすでにわかっているはずです。次に、この問題がすべてのユーザーに影響を与えるのか、それとも一部のユーザーのみに影響を与えるのかを判断する必要があります。顧客が製品をどのように使用しているかを追跡できれば、より正確なデータを取得できます。
上記の 3 つの要素が式を構成します。上記の各要素に一定範囲の値を割り当て、計算を実行します。アプリケーションや市場要素に基づいて、直接加算、乗算、または重み付けを行うことができます。たとえば、加算を実行して各バグに 10 ポイントの数値範囲を割り当てるだけです。
バグ #1: たとえば、これはプログラムをクラッシュさせるバグ (10 ポイント)、プログラムの主要部分に存在する (10 ポイント)、顧客の 80% に影響する (8 ポイント) ため、このバグは原因「ユーザーの痛み」「ボリュームは 28 ポイントですが、きっと修正されるでしょう。
バグ #2: これは単なる配置のバグです (2 点)、二次ウィンドウに表示されます (2 点)、バグがあるプログラムの部分は古いバージョンでのみ使用されます (2 点)。したがって、このバグの「ユーザーの痛み」値は 6 ポイントであり、おそらく修正されないでしょう。
残念ながら、多くの状況は上記のように単純ではありません。バグ #3 は、アプリケーションの主要部分に存在するデータ損失の問題 (10 ポイント) ですが、特定の状況下でのみ失敗します (5 ポイント) (データは主観的なものです)。顧客調査により、ほとんど使用されていないことが証明されました (2 ポイント)。したがって、その「ユーザーの痛み」の値は 17 ポイントになります。これは、変更できるかどうか不明瞭なデータです。一方で、修正に必要な投資は価値がないかもしれませんが、問題が理解され、死角がない限り、バグを無視するのがおそらく正しいアプローチです。
一方で、システム内の他のバグと比較検討する必要があります。ここでは「割れ窓」効果を適用します。アプリケーションにそのような中しきい値のバグが多すぎると、製品の品質 (または少なくとも品質の認識) が大きな影響を受けます。システム内の各バグを考慮するときは、システム内の他の (既知の) バグも考慮し、これを使用して分析し、どのバグを修正する必要があり、どのバグを修正する価値がないのかを判断する必要があります。
正式にリリースされたソフトウェアにバグがあることは確かに非常に悪いことです。しかし、既存の開発ツールと開発言語に基づくと、より合理的な解決策はまだ見つかりません。
補充:
これを書いているときに、式の 4 番目の要素、つまりリリース日が抜けているように思います。この要素は、リリース日が近づいたときにバグを修正するか修正しないかを決定する際にも重要な役割を果たします。ただし、それが 4 番目の要素なのかどうか、リリース間近にバグを修正するために必要な「ユーザーの苦痛」の量の閾値がどのくらいなのかはわかりません。