art bug reporting
なぜバグのマーケティングが必要なのですか?
この記事を書き始めたときに最初に頭に浮かぶのは、 Cem Kaner - 「最高のテスターは、最も多くのバグを見つけたり、ほとんどのプログラマーを困惑させたりする人ではありません。最高のテスターは、ほとんどのバグを修正したテスターです。」
今–の違いは何ですか ほとんどのバグを見つける そして ほとんどのバグを修正する ?
ログインしたバグがあることは明らかではありませんか バグ管理システム 開発者が修正する必要がありますか?答えは「いいえ」です。製品を販売する時間、プロジェクトをスケジュールどおりに完了する時間、開発者が作業する時間などの要因 非現実的なタイトなスケジュールなどにより、企業はユーザーに大きな影響を与えないバグがほとんどない状態で製品をリリースする必要があります。
[画像 ソース ]
製品に存在するバグが顧客の信頼性、信頼性、および利害関係者の利益に影響を与えないと述べて、経営陣に信頼を与えるのは誰ですか? –テストエンジニアまたはテストチーム–製品の品質に悪影響を与える可能性のあるバグを修正するのは、各テストエンジニアの義務です。
バグの優先順位 私の意見では、問題がテスターによって開発チームと管理チームにどのように提示されるかに大きく依存します。
問題の宣伝やマーケティングのように考えてください– これには2つのステップが含まれます。
- 書くまたは バグを正しく報告する
- バグについてすべてを知っているので、詳細をよりよく説明できます
学習内容:
バグレポートの芸術
はい、バグ報告は芸術です 。バグの記述方法は、テストエンジニアの技術スキル、ドメインの専門知識、およびコミュニケーション能力を示しています。
通常、バグには次の情報が含まれている必要があります。
- バグの概要
- 再現する手順
- 添付ファイル(スナップショット、ログファイルなど)
- バグの再現性
- バグの重大度
- ソフトウェアバージョン、環境情報
- 組織の要件に基づくその他の情報。
重要な注意: 問題の根本原因を見つけて報告するために、常に深く掘り下げてください。たとえば、ユーザー名とパスワードの正しい組み合わせによる単純なログインの失敗は、次のようなさまざまな理由に関連している可能性があります。
- ログイン資格情報がまったく検証されていません
- リモートログインの場合のネットワークタイムアウトの問題
- システムは、すべてのCAPSを非CAPSと見なす場合があります。
したがって、テスターとして、バグの要約ステートメントに従いながら、違いを解読できるはずです。
- 「正しいユーザー名とパスワードでログインできません」
- 「ユーザー名またはパスワードにCAPSと非CAPSのアルファベットが混在している場合、正しいユーザー名とパスワードでログインできません。」
後者は問題の非常に明確な説明であり、明確です。これにより、テスターとしての信頼性が高まるだけでなく、症状ではなく実際の問題を報告することになります。
それでは、バグレポートに関係する各フィールドを見て、それぞれの重要な側面について説明しましょう。
#1。バグの概要
バグの概要は、問題が正確に何であるかについての簡単なスナップショットを提供する必要があります。それは正確でよく方向付けられている必要があります。
例 :
理論とは別に、例を挙げて説明しようと思います。
単純なログインモジュールを想定しましょう。 Webサイトにアクセスする新しいユーザーが、デフォルトのパスワードでログインできないという問題を想定してみましょう。トレーニングの初期段階でトレーニングした多くの学生に同じシナリオを提示したところ、バグの要約としていくつかの回答がありました。以下に、要約がどのように表示されたかのサンプルをいくつか示します。
実行可能なjarファイルを開く方法
「」 新しいユーザーはログインできません」
「ユーザーログインが期待どおりに機能していません」
「ユーザーは正しいパスワードでログインできません」
上記のサンプルから、実際に問題を説明しているステートメントを1つ選択できますか?そうは思いません。要約には、失敗したシナリオに関する完全な情報が常に含まれている必要があります。
次のステートメントを検討してください。
「新しいユーザーは、電子メールまたはSMSで提供されたデフォルトのパスワードでログインできません」
ご覧のとおり、上記のステートメントから、開発者は問題が何であるか、問題がどこにあるかを明確に理解できます。
したがって、情報を直接提供する要約を説明する適切な単語を見つけるようにしてください。 「正しく機能しない」、「期待どおりに機能しない」などの一般的な記述は避ける必要があります。
#2。複製と添付の手順
再現不可能なバグは、重大な場合でも常に後部座席になります。したがって、手順を正しく説明的に書くように十分注意してください。
手順は正確で、問題の原因となった手順とまったく同じである必要があります。機能関連のバグについては、次のサンプルが最良の例です。
例 :
前のセクションで述べたのと同じ問題を考えてみましょう。
- ホームページの[サインアップ]オプションを使用して新しいユーザーを作成します。 (サンプルユーザー名:HelloUser)
- 電子メールとSMSはデフォルトのパスワードで受信されます。 SMSの電子メールIDと携帯電話番号は、ステップ1でユーザーを作成するときに提供されます。 (サンプルメール: HelloUser@hello.com 、サンプル携帯電話番号:444-222-1123)
- ホームページで[ログイン]オプションを選択します。
- ユーザー名のテキストフィールドに、手順1で指定したサンプルユーザー名を入力します。
- [パスワード]フィールドに、電子メールまたはSMSで受信したデフォルトのパスワードを入力します。
- サインインボタンをクリックします
- 期待される結果: ユーザーは、提供されたユーザー名とパスワードでログインし、ユーザーアカウントページに移動できる必要があります。
- 実結果: 「ユーザー名/パスワードが無効です」というメッセージが表示されます。
上記のサンプルで提供されていない情報がある場合は、 コミュニケーションのギャップが生じる 開発者は問題を再現できなくなります。手順は、テスト中に使用するサンプルデータを使用して、具体的かつ詳細にする必要があります。
可能であれば、または該当する場合は、 スナップショット 画面に正確に表示されるものの。このように、それは開発者に問題の良い見方を提供するだけでなく、あなたのテスト結果の証拠も提供します。
ザ・ 機能しない 上記の詳細に加えて、ストレス、安定性、パフォーマンスのテストケースなどのテストケースに加えて、システムにストレスを引き起こすシナリオに関する情報をそのまま報告できます。さらに、実行されるすべての操作のログを報告するシステムはほとんどありません。ログは通常、開発者がコードで提供する印刷ステートメントです。モジュールが実行されるたびに、対応するログが印刷または表示されます。ログが利用できる場合、それは開発者が問題を再現するのに大いに役立ちます。
#3。バグの再現性
大小の問題は、再現性に基づいて優先されます。それは常に、時々、めったに、あるいは一度だけ見られることがあります。 「常に」として再現される問題は、他の問題よりも優先されます。
したがって、常に再現される問題についてシナリオを正確に追跡することは、テストエンジニアの義務です。テストエンジニアが制御できない問題がほとんどない場合があり、その結果、問題が数回だけ再現されますが、複数の試行が行われます。このような場合は、常に試行回数を記載してください。特定のシナリオが実行され、それらの試行中に問題が発生した回数も示されます。
これにより、あなたが言及したバグレポートに信頼性が追加されます。繰り返しますが、これによりテスターとしての評判が向上します。評判が良い理由については後で説明します。
#4。バグの重大度
重大度は、間違いなく、バグを優先する最大の影響力の1つです。
以下は、重大度のさまざまなカテゴリです。これらは単なる一般的なサンプルであり、会社によって異なることに注意してください。
- 重大度1–ストッパーの表示–壊滅的なバグの場合、修正しないと、ユーザーはソフトウェアを使用し続けることができず、可能な回避策はありません。
- 重大度2–高–重大度1と同様のバグの場合、回避策があります
- 重大度3–中
- 重大度4–低
- 重大度5–些細なこと。
たとえば、2つの類似した問題を比較してみましょう。
セットトップボックスでは、現在調整されているサービスの周波数情報を提供するサービスプロバイダーはほとんどありません。周波数が100.20MHzではなく100MHzとして表示されていると仮定します。これは、ユーザーによるサービスの表示には影響しない場合がありますが、セットトップの診断の監視に関しては影響する場合があります。したがって、これは重大度3の問題として提示できます。
銀行ドメインで同様の問題を想定する:アカウントの残高が$ 100.20ではなく$ 100と表示されている場合は、問題の影響を想像してください。これは重大度-1の欠陥である必要があります。どちらの場合もわかるように、問題は非常によく似ており、UIに小数点以下の数字が表示されません。ただし、影響は関係するドメインによって異なります。
ソフトウェアバージョン管理会議への効率的な参加
通常、すべての組織には、バグを調査して優先順位を付ける独自のプロセスがあります。通常、プロジェクト中に特定の間隔で会議が開催され、バグについて話し合い、優先順位を付けます。
このような会議中のプロセスは次のとおりです。
- 重大度に応じて、バグ管理システムからバグのリストを照会します。
- 概要を見て、ソフトウェア製品の使用に関するユーザーエクスペリエンスへのバグの影響について話し合います。
- リスクと影響の評価に基づいて優先順位を設定し、バグを適切な開発者に割り当てて修正します。
ステップ2では、バグがそれにふさわしい優先順位を受け取らない場合、すべてのテストエンジニアがユーザーエクスペリエンスへのバグの影響を提唱することが不可欠です。結局のところ、テストケースを作成し、製品をテストするためにユーザーの視点を考慮するのは、テストエンジニアです。
銀行のドメインで小数点以下の桁が表示されないという上記の問題の例を考えてみましょう。開発者にとっては、それほど深刻ではないように思われるかもしれません。彼は、変数を整数として宣言する代わりに、問題を解決するための浮動小数点として宣言するので、それほど深刻ではないと主張するかもしれません。
しかし、テスターとしてのあなたの役割は、顧客の状況を説明することです。重要なのは、このシナリオでユーザーがどのように文句を言うかということです。テスターは、顧客がセントでお金を失うので、これはユーザーの間でパニックを引き起こすと言うべきです。
バグを適切に販売しないことの影響
バグが適切に販売されていない場合、次のような問題が発生します。
- 欠陥の優先順位が正しくない
- 重要な問題の修正の遅れ
- 重大な欠陥のある製品リリース
- 顧客からの否定的なフィードバック
- ブランド価値の切り下げ
上記のすべての理由とは別に、あなたを構築することは非常に重要です テストエンジニアとしての評判 。それはあなた自身のためにブランド価値を開発するようなものです。
キャリアの初期段階で、「再現できない」、「詳細情報が必要」、「有効なバグではない」の数、または重大度の変化を可能な限り低く抑えることができれば、ある段階ではバグは精査されません。まったく、それらは修正される適切な開発者に直接割り当てられます。
このようなブランド価値を開発し、チームや開発/管理チームの信頼を勝ち取るには、テスト知識、ドメイン、コミュニケーションスキルの観点からいくつかの技術スキルを開発する必要があります。
結論
大小を問わず、あらゆる製品やサービスは、適切な宣伝なしに常に失敗することになります。ブランドが確立されると、どんな小さな製品でも聴衆に大ヒットする可能性があります。
そうは言っても、製品を過度に宣伝すると、評判を損なう可能性もあります。
したがって、バグは常に明確、簡潔、正確な方法で記述して、広範で網羅的なソフトウェアマップ内のバグの正確な場所を示す必要があります。これにより、ソフトウェアの品質が向上するだけでなく、ソフトウェアのテストと開発のコストが大幅に削減されることを繰り返し述べます。
今では手遅れではありません!さあ、すぐにバグを修正しましょう!
youtubeからmp3へのコンバーターウイルスなし
推奨読書
- なぜバグレポートはすべてのテスターが学ぶべき芸術なのですか?
- 'Invalid Bug'ラベルなしですべてのバグを解決するにはどうすればよいですか?
- サンプルバグレポート
- Webおよび製品アプリケーションのサンプルバグレポート
- 3つの最悪の欠陥報告の習慣とそれらを破る方法
- バグが拒否される10の理由と、テスターとして何ができるか!
- 良いバグレポートを書く方法は?ヒントとコツ
- アプリケーションのバグを見つける方法は?ヒントとコツ