いう記事が素晴しかったので、著者の許可を得てここに日本語訳を掲載します。開発者の最大の負担は、ブラウザのバグと非互換性への対応に膨大な時間を費やすことであるといって間違いないでしょう。開発者全員の常となっていました。ブラウザのバグは迷惑でいらだたしく、仕事を大幅に難しくします。ブラウザのバグはとてもいらだたしく、通常の開発における最大の負担です。開発者にとっての責任です。自分が見つけたバグに対して責任を持ち、「ほかの誰かがこれを見つけるだろう」とは思わないことで、ブラウザの進歩の速度は加速していくでしょう。ブラウザのバグを見つけるたびに、個別のブラウザへバグ報告を登録しましょう。自分のサイトを主なブラウザの最新のビルドで積極的にテストしましょう。開発者の圧倒的多数は、一度もブラウザベンダにバグ報告を登録したことがないばかりか、ブラウザのナイトリー版を使ったことさえありません。これは恥じるべきことです。考えてみれば、ブラウザの何が異常かを評価するのに、ブラウザでの開発に日々を費やす人ほどその資格がある人というのはほとんどいないのです。ブラウザのバグを登録せず、ナイトリーでのテストもしないプロの開発者を見たとき、私は特に驚きました。ほとんどの開発者の主な仕事のひとつに、クロスブラウザの問題を取り繕うことがあります。ことは最優先事項になります。私は個人的に全主要ブラウザベンダにバグ報告を登録してきて、良い報告を生み出すいくつかの特徴に気づきました。つのポイントは、分類、テストケース、そして単純化です。分類され、単純化されたテストケースが提供されたバグは、どんなものでもブラウザの開発者によるレビューが保証されます。バグを登録する場所から始めましょう。バグ報告を登録する大抵、バグ報告を登録するときは、実際の提出フォームへたどり着く前に、いくつかの深い層を通り抜けなければいけません。テストしておきましょう。これは、ブラウザの開発者が最初に尋ねることのひとつです。そのブラウザの現在の開発版でも依然としてバグが存在し、いまだ修正されていないことを示せたのなら、ブラウザの開発者たちはずっと簡単に取り組み始められるでしょう。多くのバグ報告ページは、報告を提出する前にアカウントの作成を求めてきます。バグを分類するバグを適切に分類することは重要な第一歩です。特定のモジュールのオーナーは、新しく来た提出をすべて監視しています。バグを適切な分類に割り当てることは、そのバグを修正するのにもっとも適した人物の眼前へ、直ちにバグを持ち込むことになります。バグの分類はブラウザ次第です。機能が存在する特定のモジュールを示すために複雑な分類を使います。コンポーネントを選択してください。コンポーネントを選択してください。対して登録すべきか判断するのには注意が必要です。ナイトリーとの両方でバグをテストしてください。バグを登録しましょう。ひとつ問題があります。バグトラッカーに登録されるべきです。明示的な分類手段を提供していません。(このプロセスを制御することはできません)。テストも手早く行うべきです。バグが複数のプラットフォームに存在することを特定すれば、ブラウザの開発者がバグの原因の発見に必要とする時間を削減するのに劇的に役立ちます。テストケースを提供する再現可能なテストケースは、どんな形式であれ何もないよりは優れています。ページは一般的に良い取っ掛かりとなります。(ブラウザの開発者がそのチケットに取り組むのには、しばらく時間がかかるかもしれません。テストケースがもはや存在しなければ、開発者は単にチケットを閉じてほかの作業へ移るでしょう)。はいっても、悪いテストケースというべきものもあります。動かなかったので、修正してください」といった類のものです。これは、失敗の正確な理由を見つけだすため、誰かに膨大な時間をとらせることになり、バグをキューのより後ろへと押し出すでしょう。最良のテストケースは単純さを提供する類のものです。単純さを提供する単純なテストケースを提供することは、間違いなくバグ報告を作成する上で一番難しく、かついらだつ部分です。これは、大概報告に気づき修正してもらう上での重点でもあります。分もかからないでしょう。このようなテストケースを作成する手順は単純です。バグがあるページを持ってきて、バグの再現に影響しないものをすべて切り取ってしまうのです。ある地点に到達すると常にクラッシュすることに気づきました。HTML、CSS、画像などテストを切り取ることから始めました。最終的に私は単独のテストにたどり着きました。それから私は、外部依存が必要なくなるように、可能な限りテストスイートを剥ぎ取っていきました。13);};残ったものは、依然としてクラッシュを起こすにもかかわらず、これ以上ないほど単純です。週間後には解決されていました。私のバグに取り組んでいますか?これは興味深い点です。これら各ブラウザでバグの状態を判断する最良の方法を以下に示します。バグは、最初に選択したコンポーネント分類のデフォルトの窓口係に割り当てられるところから始まります。これはまだ何も意味せず、単純に人々の目をチケットにひきつけるだけです。(これはその人がそのバグの進行に興味を持つという意味です)。決定的な瞬間は、誰かがそのバグを自分自身に割り当てたときで、事実上その人がそのバグの状態に責任を持ち始めます。ほとんどの貢献者はそのバグにつけられるコメントが自動的にメールされるよう設定しているので、そのバグの状態に関して何かしら疑問があれば、遠慮せずコメントを投稿できます。(日ごとに、あるいは週ごとにでさえ、更新状況を尋ねることは貢献者をいらだたせるでしょう)。そのバグを管理し完了まで後押ししてくれる誰かをただ受け入れましょう。