Web 開発者の責任 (翻訳)
2009-05-06


バグを適切に分類することは重要な第一歩です。しばしば、(レイアウトや DOM といった) 特定のモジュールのオーナーは、新しく来た提出をすべて監視しています。バグを適切な分類に割り当てることは、そのバグを修正するのにもっとも適した人物の眼前へ、直ちにバグを持ち込むことになります。

バグの分類はブラウザ次第です。(Opera や Internet Explorer のような) いくつかのブラウザがバグの登録に簡易的な分類を用意している一方で、他のブラウザ (WebKit/Safari や Mozilla/Firefox) は機能が存在する特定のモジュールを示すために複雑な分類を使います。

Mozilla/Firefox: コンポーネントを選択してください。最も一般的なのは DOM、Layout、JavaScript Engine などです。

WebKit/Safari: コンポーネントを選択してください。最も一般的なのは HTML DOM、Layout and Rendering、JavaScriptCore などです。

Google Chrome: Chrome に対して登録すべきか判断するのには注意が必要です。最初に Safari の最新リリースと最新の WebKit ナイトリーとの両方でバグをテストしてください。もしバグが Chrome のみに存在するのならそこに登録し、そうでなければ WebKit/Safari にバグを登録しましょう。しかし、もうひとつ問題があります。Chrome の JavaScript エンジン (V8) にのみ存在するバグは、(どさくさにまぎれて行方不明にならないよう) Chrome ではなく V8 のバグトラッカーに登録されるべきです。

また、Chrome は明示的な分類手段を提供していません。すべてのバグは開発者によりレビューされ、それから分類されます (このプロセスを制御することはできません)。

複数のプラットフォーム (OS X と Windows、Windows と Linux など) でのテストも手早く行うべきです。バグが複数のプラットフォームに存在することを特定すれば、ブラウザの開発者がバグの原因の発見に必要とする時間を削減するのに劇的に役立ちます。

テストケースを提供する

再現可能なテストケースは、どんな形式であれ何もないよりは優れています。問題が封入された Web ページは一般的に良い取っ掛かりとなります。もし Web ページをバグ報告に直接添付できるのなら、さらに良いでしょう (ブラウザの開発者がそのチケットに取り組むのには、しばらく時間がかかるかもしれません。指定された URL にテストケースがもはや存在しなければ、開発者は単にチケットを閉じてほかの作業へ移るでしょう)。

そうはいっても、悪いテストケースというべきものもあります。最悪なのは「http://example.com の Web サイトを見たら、ブラウザ X では動かなかったので、修正してください」といった類のものです。これは、失敗の正確な理由を見つけだすため、誰かに膨大な時間をとらせることになり、バグをキューのより後ろへと押し出すでしょう。

最良のテストケースは単純さを提供する類のものです。

単純さを提供する

単純なテストケースを提供することは、間違いなくバグ報告を作成する上で一番難しく、かついらだつ部分です。しかしこれは、大概報告に気づき修正してもらう上での重点でもあります。最も資質のある開発者でさえ、十分良いテストケースを作成するのに 30 分もかからないでしょう。

このようなテストケースを作成する手順は単純です。バグがあるページを持ってきて、バグの再現に影響しないものをすべて切り取ってしまうのです。これは、スタイルシート、画像、JavaScript ファイル、JavaScript ライブラリ、そして HTML を含みます。

たとえば、しばらく前に私が Dromaeo テストスイートを走らせていたとき、WebKit がある地点に到達すると常にクラッシュすることに気づきました。私はまず、不必要な HTML、CSS、画像などテストを切り取ることから始めました。最終的に私は単独のテストにたどり着きました。文字列の分割です。それから私は、外部依存が必要なくなるように、可能な限りテストスイートを剥ぎ取っていきました。

最終結果に注目してください:


続きを読む
戻る
[Web 関連技術]

コメント(全0件)
コメントをする


記事を書く
 powered by ASAHIネット