効果的なバグレポートのための9つのヒント

それは、ソフトウェアテスターが、彼が感じるものすべてを報告することが重要です。ソフトウェアテスターの役割はどのチームでの触媒のことです。彼は、一方でチームを構成していると、他にアプリケーションを分割します。ビジネスとアプリケーションの面で理解のためのコースとの大きなまたは小さいかもしれませんはっきりアプリケーションですべての問題を理解することが重要です。したがって強いバグレポートは、ソフトウェア開発ライフサイクルの明確な証拠として機能し、すべての段階で更新されるバグのステータスを提供しました。あなたのバグを報告する唯一の目的は、あなたの意図は、バグを直してもらうことであるということです。

1。バグの説明の明確さ - バグ説明は簡潔に問題を正確に向かって指して小文を指す。問題は手順のカップルはそれを再現するために必要かもしれません、しかし、バグの説明のこの小文​​では、問題の本質を正確に伝えることができなければなりません。サーバからのエラーに関する問題が発生した場合に例えば、バグの説明は明らかにそのようなそのような操作を実行中にサーバーエラーが起こることを示すことによって意味を詳しく説明することができます。

2。あなたの評決を渡してはいけない - あなたがあなたによって検出されたバグの信憑性についての自信に満ちている場合でも、あなたはバグのgenuinityであなたの評決を通過しようとしているかのように反映してバグレポートを書くのを避ける。すべての確率では、これはテスターとして優越感を反映して論争を開始することができる。バグは最終的に閉じ得るためにでなければなりませんあなたの主な目的は、あなたのバグがバグプラス唯一の動機を支える決定的な報告を維持するべきである。代わりにあなたのバグが、それによってあなたのバグレポートが不快な意思を支持して正式なステートメントを使用せずに、バグレポートに外交を使用しようとする、最良の方法は示唆的であることです。このようなアプローチは、常に良好な精神で取らなければならない。

3。手順が再現する - それは明らかにバグレポートで定義する必要があります再現するように一連の条件を十分に説明して、バグの正確な地点に到達する方法。例えば、グラフィカルなソフトウェアのため、テスターは、彼がバグを取得する前に行っていたものとして、開発者に通信する必要があります。詳細はボタンが押されたかのように、どのような順序で詳述する必要があります。プロンプトに渡ってコマンドをキー入力で実行されるプログラムは、バグを取得する前に入力したコマンドの詳細は正確に示さなければならない。

4。簡単な言語の使用 - 人々は複雑な専門用語＆早口言葉を含む長いパラグラフを読むことが好きではありません。良いバグレポートは小さいが明確な文章が含まれているような小さな箇条書きが含まれています。それが唯一の心配バグに関連する所見を記述する必要があります。あまりにも多くの事実を書き込むことにより、バグレポートが不必要に複雑で長いしないでください。バグを再現内の任意の助けになることがないかもしれない余計な詳細を語ることは避けてください。誰にでも、一般的に知られていたものを書いてはいけません。

5。見積り関連の例としては、 - ほとんどの状況では、特定のバグを再現するためには、入力のいくつかの特定のグループが不可欠であることがわかります。代わりに連絡先リストの人のフィード無効な名前のような漠然とした記述を、このように、＆保存、それはそれは、フィード名フィールドに035bbb @ $％などの無効な入力を言うことができると[保存]をクリックします。迅速に不具合を修正するためにはテスターは、関連するすべての情報/ツー·ポイントの情報を提供することで、プログラマを支援しようとする必要があります。

6。参照を提供するバック - ケースでは、特定のバグが仕様書やプロジェクトに関連する他の文書と矛盾するように起こります。バグレポートは矛盾している当該文書の特定の章や節の番号に適切な参照を提供する必要があります。

7。バグの優先順位と重要度を割り当てる - バグ報告は、バグの重要度とバグの優先度のレベルを充用なしで完全ではありません。

バグの重大度：バグがシステムに害を与えることができる方法にひどくとして危険の量子を指します。これは、バグがどのように悪いように説明しています。重症度は、バグに関連付けられている一定の自然の特徴である。
下のように説明されてバグの重大度の3つのレベルがあります：

重大度レベル - クリティカル：特定のポイントを超えてテスト作業の継続が許可されていない最も危険なレベルです。危機的な状況は、いくつかのエラーメッセージのポップアップまたは強制完全閉鎖またはアプリケーションの半閉鎖につながるシステムのクラッシュが原因で起こることができます。事態の重大性は、回避策のいずれかの型が適切ではないという事実によって判断することができる。バグはいくつかのメニューオプションが存在しないこと、またはテストされて、所望の機能へのアクセスを得るために特別なセキュリティのアクセス許可を必要とした場合に "緊急"カテゴリに分類することができます。

重大度レベル - 高：製品が目的の期待度に応じて行動するか、それによって顧客の要件を満たすために失敗の原因となっていくつかの他の機能の誤動作につながることが失敗する重大な欠陥の下のレベルです。このカテゴリの下にバグが回避策のいくつかの並べ替えを介して取り組むことができる。このタイプのバグの例としては、計算や記録の更新に失敗の原因となって、データベース内のフィールドの不正な形式の数式のミスすることができます。同様に多くのインスタンスが存在します。

重大度レベル - 中：媒体または重大度の平均のこのカテゴリに該当する欠陥は、アプリケーションのパフォーマンスへの影響はありません。しかし、これらの欠陥は、規格または企業見よの規則に不適合のために確かに受け入れられない。ミディアムレベルのバグは単純な回避策がパフォーマンスのための所望の目的を達成することが可能であるために取り組むことが比較的容易である。このタイプのバグの例には、それに対応するテキストリンクと比べていくつかの目に見えるリンクの間に不一致することができます。

重大度レベルは - 低：低優先度または軽微な欠陥のカテゴリに該当する欠陥は、製品の機能に影響を及ぼさないものである。重大度の低い障害は、一般的にアプリケーションの通常の使用中に発生すると、ビジネスには非常に少ない効果を持っていません。バグのようなタイプは、一般的にユーザーインターフェースのルックス＆フィールに関連＆自然の中で、主に化粧品ですされています。

バグの優先度：バグが修正される必要がある方法を早急にと必要性に言及。これは、バグの重要性について説明します。バグの優先度は、テストのスケジュールに従って変更されることがあります。下のように説明されてバグの優先度、の3つのレベルがあります：

高い優先度：そのようなバグすぐに修正されていない場合は、顧客側での正常な機能に影響を与えるとしている。したがって、そのようなバグは固定に即時または最上位の優先順位が与えられます。

中優先度は：顧客の機能に優れた効果を有する主要な欠陥バグに割り当てられている。これらの関連の問題が存在するソフトウェアバージョンのリリース前に解決されるようにそのようなバグは偉大な優先順位が割り当てられます。いくつかの時間の制約のため、この問題を解決することができない場合は、パッチやサービスパックのいくつかの並べ替えは解放しなければなりません

低優先度は：一般的には顧客側でソフトウェアのパフォーマンスに大きな影響を持っていないバグに割り当てられます。これが原因でこのような固定は次のバージョンのリリースまで待つことができる時間の制約に不可能な場合は努力が、現在のバージョンのリリース前にそのようなバグを解決するために作られています。

8。スクリーンショットで説明する - "絵が100語以上の価値がある"という古いことわざにあるように。我々はエラーが発生したとき、それは特定の瞬間のスクリーンショットをキャプチャすることが最善です。エラーメッセージが表示された場合は、そのスクリーンショットは、問題の正確な理解を持っていることに、開発者を支援します。これは、開発者が問題を解決しようとしない段階であり、むしろ、まず、問題を明確に理解するために彼の注意を焦点を当てています。
このようなスクリーンショットでは、証拠としてバグレポートの付録である必要があります。このようにテスターは、より良い方法で＆開発者へのより多くの明快さと彼のバグを伝えると説明することができる。

9。スタンバイあなたの本物のバグ：
ソフトウェアテスターは、それがアプリケーションのパフォーマンスに影響を与えるために起こっているので、彼のレポートの対象バグが固定を必要とする本物のバグであることを守るために彼とニーズによって見つかったバグスタンバイする必要があるときにバグレポートの中で最も興味深い部分である。この過程で、ソフトウェアテストエンジニアは、下記のいくつかのもののようなプログラマーとの状況に直面する準備ができている必要があります。

ケース1：開発者は、通常、背中の特定のバグが再現できないというヒット。バグを報告するための最良の方法は、実質的に開発者にそれを見せている。これは、コンピュータシステム上のシナリオを見てアプリケーションをロードすると問題があるイベントのライブデモを提供することを求めることによって行うことができます。これはそれらを使用すると、アプリケーションを発射していた方法として状況の実際のルック＆フィールを提供するであろう、どのようにしてアプリケーションと対話していた＆ソフトウェアが提供される入力に対してどのように反応するか。ベストプラクティスとしては、できるだけ短時間でバグの最大数を報告するための熱意に再現不可能なバグの報告をしないようにしてください。

ケース2：たまにソフトウェアテスターが故障した一貫性のないパターンを有するいくつかのアプリケーションを使用して変な状況に出くわす。テスターは、テスト対象の締め切り＆アプリケーションの圧力を検出する失敗しますが、開発者に同じを発揮しながら、アプリケーションは、その時点で正常に動作しますので、彼は、恥ずかしい瞬間に直面したとき、このような状況が発生することがあります。したがって良いテスタは＆常に彼の発言を正当化するために、テストデータとスクリーンショットなどを保存する形で防御機構を構築患者する必要があります。

ケース3：テスターは、開発者に様々なアクション＆入力等の大きなリストを提供していますが、プログラムは、開発者のシステム上で実行されたときに何も悪いことを示すために失敗した場合。これは、テスターは十分な情報が提供されていないことを意味します。これは、開発者＆テスターのシステムは、それによって開発者のコ​​ンピュータシステムに出頭しない障害を引き起こして、いくつかの設定が異なり、かなり可能です。これは、テスター＆開発者が同じディスプレイを目の当たりにしていながら、テスターは、プログラムの期待を誤解していたのは、かなり可能ですが、視点の違いに。これは、テスターに​​エラーとして、表示​​される内容は、開発者の観点から正しいかもしれないということが可能かもしれない。したがって、このような状況から出てくる、それはあなたが予想していたものとして言うことが好ましいと何が正確に＆何が起こったの見ていた。