10 reasons why your bugs are getting rejected
私は彼女を惜しまないつもりです。彼女は過去3日以内に7つのバグを拒否したと私は報告しました。彼女がプロの剣として個人的な恨みを使っていることを私は知っています ……
チームメイトが発煙していて、他のチームメイトのカップルが他の開発者と同じ経験を共有することに参加したとき、議論は突然発火しました。チームミーティングは、バグの拒否に関する議論のポイントになりました。いくつかの議論の後、私たちは皆、将来、拒否されたバグの屈辱から身を守るために簡単な演習を行うことにしました。
私たち一人一人が、過去10のバグのバグ拒否の理由としてメモを取り始め、報告され、拒否されました。これらの拒否ノートのリストは、バグ報告の将来の軌跡と、間違った仮定が何であったかを理解するのに役立つことがわかりました。
バグの拒否とその背後にある理由
リストを公開するのではなく、リストの結果の箇条書きを共有したいと思います。ここにあります -
＃1）要件の誤解：
どういうわけか、要件を正しく理解していなければ、実際の実装で誤って解釈された要件に間違いなく気を配り、それが見つからない場合はバグであり、最終的に拒否されます。
実際の例 ：レシピをテストしたところ、塩を加えていないので味がないことがわかりましたが、提供時に塩を加えることになっていることを知りませんでした。そうしないと、レシピの外観に影響を与える可能性があります。
＃2）要件の実装：
以前の議論の一部として、特定の要件がXYZ方式で実装されることに気づいていました。しかし、開発中に、開発者はXYZパスをたどることができないことに気づき、ABCパスをたどりましたが、それはあなたに伝えられませんでした。
最終的には、要件が説明された方法で実装されていないことがわかったときに、バグを報告することになります。
実際の例 ：あなたは仕立て屋にシャツを準備するように頼みました、そしてあなたが裁判を求められたとき、あなたはそれにボタンが見つからなかったと言ってそれを拒否しました。仕立て屋が、前面にボタンを付けるとシャツの全体的な外観に影響があり、それゆえにシャツを前面の境界線の内側に置くと説明すると、間違いなく唖然とします。
＃3）明確な要件がない：
明確な要件がない場合は、誰もが自由に要件を引き受けることができ、個人レベルでの引き受けにつながります。個人的な仮定が満たされていないことがわかったら、それをバグとしてマークします。
実際の例 ：先生が生徒に自転車を引くことを期待していると発表したときに、サイクルを描く必要があります。 30分後、全員の絵を確認したところ、期待に一致する人は見つかりませんでした。誰もが自分のやり方で漠然とした声明を出し、その結果は三輪車、赤ちゃんのサイクル、多すぎるサイクル、車椅子でのサイクルなどでした。
＃4）要件の変更：
ほとんどの場合、誤解の別の例。テスターが要件の変更について通知されない場合、より多くのバグが報告され、最終的に拒否されます。
実際の例 ：注文したバナナブレッドではなくハニーパンを使用していることがわかった場合、サンドイッチは間違いなく拒否されます。あなたが電話をしている間にあなたのパートナーが注文のためにパンの種類を変更したことをあなたが知っていることはほとんどありませんでした、そしてもちろん彼/彼女はあなたとそれを共有する必要はないと思いました。
＃5）範囲を理解する：
テスト中に、特定の時点でテスト可能と見なされるべきではない、または製品基準でまったくカバーされていないもののテストを開始します。あなたはバグ拒否の犠牲者になるでしょう。
実際の例 ：あなたは部屋を掃除することになっていて、それが唯一の焦点です。それでも、他の領域の混乱について不平を言うなら、あなたは間違いなく無視されるでしょう。
＃6）テスト環境：
アプリケーション/製品は、メジャーとマイナーの両方の多くのハードウェア要件とソフトウェア要件の組み合わせであり、適切なテスト環境が使用されていないか、テスト環境に何かが欠けていると、アプリケーション/製品がクラッシュし、重大なバグが報告されます…。
Gmail用の最高のメール追跡ソフトウェア
次に何が起こるかというと、詳細な調査です。ほとんどの場合、使用したテスト環境に関する細かい詳細を意図せずに提供することはなく、開発者の作業が増えるためです。最終的にバグは拒否されます。
実際の例 ：数日前に友人の家で味わったおいしいマフィンは素晴らしく、レシピに従った後、マフィンはあなたが持っていたものにさらに近づきませんでした。
さて、新鮮なバターが入手できなかったので、古いバターを使用することは想定されていませんでした。味を追加する可能性があると思ったので、ベサンを少し加えることは想定されていませんでした。オーブンとして鍋で調理することは想定されていませんでした。故障していた。
推奨読書=> 「テスト環境」を効果的に準備する方法。
＃7）使用したテストデータ：
テストに使用されたテストデータは、要件と一致していませんでした。
実際の例 ：電卓が特殊文字を追加しようとすると数値処理に役立つことを知っていても、電卓が予期せず応答した場合は、不適切だと思います。本当に？
推奨読書=> テストデータを設計するためのヒント そして テストデータ管理技術 。
＃8）重複するバグ：
誰かがすでに同じバグを報告していて、バグを報告する前に同じものをチェックするように注意していませんでした。再び拒否。
実際の例： カスタマーサポート担当者は、各家族から同じ製品に対する苦情の電話を何度も受けた場合、満足することはありません。 1回の電話では不十分だったと彼は思います。
＃9）不適切なバグの説明：
開発者がバグレポートを介して伝えようとしていることを理解できない場合、他のタスクもロードされているため、またバグレポートで適切な説明と必要な詳細が見つからない場合は、どのようにしても拒否されることを期待してください。重大なバグは、拒否としてマークされることが期待されていることです。
推奨読書=> 良いバグレポートを書く方法は？ ヒントとコツ。
実際の例： 車のロックを解除し、座って、キーを時計回りに動かすことから始める必要があります…。車が始動しなかったので、あなたは動揺しています。ガソリンをチェックするように指示されていませんか？ああ、デフォルトでチェックする必要があることを確実に理解することを前提としていたマニュアルの間違い。
＃10）再現不可能なバグ：
バグを報告している間、バグの再現性の重要性に気づいたことはありません。バグが常に再現可能であるかランダムに表示されるかを確認するだけで、作業時間と拒否されたバグをもう1つ節約できます。
実際の例： あなたがひどい風邪について不平を言ったが、彼が何の症状も見つけなかったとき、医者は何をチェックしますか？ ああ、くしゃみをしていました 、状況を改善することはありません。
結論
ほとんどの場合、私たちの人間性により、報告されたバグが拒否されたときに否定的に考えることができます。本当のところ、開発者は、バグが有効である場合にバグを拒否する特定の理由を見ていません。
したがって、次回以降は、バグ数に焦点を当てないでください。最終的に重要なのは、報告したバグの数ではなく、製品の品質の向上にどのように役立ったかであるため、適切な詳細を含む定性的なバグに焦点を合わせます。
また、読む=> 「無効なバグ」ラベルなしですべてのバグを解決するにはどうすればよいですか？
著者について： この有用な記事は、STHチームメンバーのBhumikaMehtaによって書かれました。彼女は、7年以上のソフトウェアテストの経験を持つプロジェクトリーダーです。
ハッピーテスト！いつものように同じ上であなたの意見を待っています。
推奨読書
- 'Invalid Bug'ラベルなしですべてのバグを解決するにはどうすればよいですか？
- なぜバグレポートはすべてのテスターが学ぶべき芸術なのですか？
- バグレポートの技術：バグを売り込み、修正する方法は？
- ソフトウェアにバグがあるのはなぜですか？
- すべてのテスターが知っておくべき7種類のソフトウェアエラー
- あなたがテスターであることを知る11の方法。
- サンプルバグレポート
- 大胆で自信に満ちたソフトウェアテスターになるための5つの方法