1.ピンポン（非効率的な方法、経営者の不満の原因）
テスターはバグを記述し、開発者はコメントなしでバグを閉じ、攻撃的ステータスを「無効」にします。 テスターは、「あなた自身は無効になっています」というコメントでバグを再発見します。 開発者はコメントを書くことを余儀なくされています。 事実ではありません。
2.アンダーフィックス
Underfixは完全に修正されたバグではありません。 たとえば、2つの場所に目的のボタンがありませんでした。 修正後、ボタンは1か所にのみ表示されました。 このようなバグを検証するとき、私の意見では、ボタンが2番目に見つからないことを示す新しいバグを開始することが最善です。 元のバグを未検証のままにして、「検証は新しいバグによってブロックされています」というコメントを挿入します。
元のバグを確認した場合、2番目のバグを修正した結果、ボタンが最初に消える状況が発生する可能性があるため、これをスキップします。
3.開発バグ
開発バグは、開発者が作成したバグです。 多くの場合、開発者は、再生スクリプトを作成したり、バグで少なくとも望ましい製品の動作を作成したりしません。 したがって、ボトルがない場合や著者からの追加情報がない場合、このようなバグを検証することは非常に困難です。
この場合、「検証方法に関する情報を提供するか、自分自身を検証してください」などのコメントが役立つ場合があります。 開発者へのバグの割り当てと組み合わせたこのようなフレーズは、「情報の確認方法を提供する」よりもうまく機能します。
後者の場合、開発者に選択肢の選択肢を提供せず、開発者は自分でそれを発明し始めることができます。 たとえば、無能なテスターは行間を読むことができないと主張して、情報を提供することを拒否します。 しかし、バグを独自に検証する代替手段が開発者の完全な成長に直面するとすぐに、彼は通常、詳細な指示を作成します。
4.これはバグではなく機能です（開発者の意見）
このようなコメントでクローズされたバグは、綿密な調査が必要です。 テスターだけでなく、おそらくそのリーダーであり開発マネージャーでもあります。 結局のところ、この機能は非常に明白で直感的であるため、よりバグのように見えます。 それでもなお、製品の修正は非現実的であることに当事者が同意する場合、明白でない動作が明確に記述されるように、ドキュメントのバグを作成する必要があります。
5.これはバグではなく、機能（テスターの意見）
テスターが「Linuxの3つの新しいバージョンをサポートする必要があります」という形式のバグを見つけた場合、これはバグではなく機能です。検証プロセスにはおそらく回帰テストの完全な通過が含まれるからです。 3回。 古いバージョンのLinuxから新しいバージョンに切り替える可能性をテストすることは言うまでもありません。 したがって、このような「バグ」の検証に必要な時間は、平均よりもはるかに長くなります。 したがって、そのようなバグを始めた人は、それを完全な機能として設計することを余儀なくされるべきです。
6.現在のバージョンのバグの検証は、次のバージョンで修正が予定されているバグによってブロックされます
ナンセンス。 両方のバグの修正バージョンは、現在または次のいずれかに設定する必要があります。 これは両方のバグで必要です。
おそらく私は明白なことを書くでしょうが、私はすでに一度それを書かなければなりませんでした。
最初のバグが非常に有害であると認識され、現在のバージョンで修正されるようになり、すべてが同じシナリオで破損するようになった場合、ブロックバグはブロックされたバグと同じくらい有害です。 そのため、現在は誰もブロッカーを修正できないことを除いて、異なる修正バージョンでそれらを保持することは意味がありません。 したがって、スクリプトがまだ壊れているため、ブロックされたバグを次の修正バージョンに移動することは、製品の品質にとって絶対に安全です。
しかし、もちろん、現在のバージョンのブロッカーを修正することをお勧めします。