問題の再現¶
そもそも問題が存在しなければ、それを修正することはできません。したがって、問題を再現することは、それを修正するための前提条件です。ソフトウェアにおいては、問題は一般的に「バグ」と呼ばれ、問題報告は「バグ報告」と呼ばれることが多いです。
誰かがバグ報告を提出しました。報告者が説明している手順が、実際に報告されているバグを引き起こしていることを確認する必要があります。報告に記載されている内容を正確に再現することで、同じ結果を再現できますか？再現できない場合は、その理由を特定する必要があります。
問題の再現を開始するには、開発環境 を設定する必要があります。
コード内のバグ¶
理想的な状況では、バグを報告した人物と同じ環境設定を持ち、手順に従い、説明通りにバグを再現できるはずです。しかし多くの場合、そう単純にはいきません。 多くのバグ報告には、曖昧な説明と漠然とした条件設定しか記載されていません。問題は、多くのバグが関与する条件セット（操作方法、様々な前提条件、OS、OSバージョン、CPUアーキテクチャ、あるいはユーザーのマシンが古くて遅いか新しく速いかなど）によって変化する点にあります。バグを取り巻く状況に関する情報が豊富であればあるほど良いのです。 報告者が提供した条件セットを再現してみてください。それができない場合、次のステップとして、バグを報告した人物に追加情報の提供を依頼する必要があるかもしれません。
バグを再現する最良の方法は、問題が再現される最小限の例を用いることです。多くの場合、報告者は最小限の実行可能な例を提供しません。仮に例を提供したとしても、それは「実環境」のアプリケーションから直接コピーされたものになるでしょう。 あなたの目的は、問題を再現する最小限の形式に報告内容を簡素化することです。最良の再現ケースは最小限のプログラムです。この簡素化自体も有益であり、実際の問題点を特定します。誰でも最小限の例を実行すれば、報告されたバグを再現できるのです。
ドキュメントのバグ¶
ドキュメントのバグは様々な形で現れる。 書式設定の問題により表示上の不具合が生じる場合があります。時にはバグではなく、ドキュメントの誤読や単純なミスであることもあります。とはいえ、ドキュメント自体に問題がないとは限りません。内容が不明確または不正確で、混乱や誤解を招く余地があるのです。説明すべき概念が完全に未記載であるため、議論されていない可能性もあります。
ドキュメントの問題でバグが報告された場合、実際に問題がまだ存在しているか確認する必要があります。レンダリングの問題の場合は、ドキュメントをビルドして問題を再現できるか確認してください。コンテンツの問題は、更新が提出されていないか読み込んで確認する作業です。
問題を更新する¶
トリアージプロセスの最終ステップは、問題にコメントを残すことで調査結果を記録することです。
問題が説明通りに再現できる場合は、その旨を伝えるだけで十分です。元の報告者が説明した通りの方法で、同じ問題が発生していることを確認した旨をコメントに残してください。
追加のコンテキストを提供できる場合は、その詳細を含めてください。これには、異なるオペレーティングシステム上での問題の再現、関連ソフトウェアの異なるバージョンでの再現、または元の報告内容と異なる点全般が含まれます。
元の報告に必要な再現手順の詳細が不足している場合は、それらの詳細を含めてください。これには、元の報告に記載されていないオペレーティングシステムやバージョン情報、より完全なログやスタックトレース、問題の再現に必要な正確な操作手順の明確な指示などが含まれます。問題の再現をより簡便な方法で確立した場合（または元の報告者が再現ケースを提供していない場合）、その再現方法の詳細を含めることができます。
問題が再現できない場合も、試した内容を詳細にコメントしてください。問題が「存在しない」場所を把握することは、問題が「存在する」場所を把握することとほぼ同等に重要です。なぜなら、それが原因の絞り込みに役立つからです。 問題が再現できない理由についての仮説がある場合（例えば、使用方法の誤りによるものと考えられる場合や、最近のOSアップデートで問題が解決された可能性がある場合など）、その推測もコメントの一部として含めてください。
最後に、コアチームに対してご提案があればお寄せください。元の報告に誤りがあると思われる場合は、その問題をクローズすべきだと提案してください。問題の原因について仮説をお持ちの場合は、それも提案できます。皆様のご意見は、コアチームが問題を次の段階に進める方法を検討する上で役立ちます。
この時点で、再現した問題を修正することを選択することもできます。あるいは、調査結果をまとめ、別の問題を再現してみることもできます。