testing - QAの問題が欠陥であるかどうかをどのように判断しますか？

Question

私は開発者としていくつかの会社で働いていましたが、最近、新しい会社でQA自動化に移行しました。会社はそれぞれ異なり、私が本当に好きなこれを処理する方法をまだ見ていません。多くの場合、QAは何かが問題であると言い、応答は「まあ、それは難しすぎて修正に時間がかかりすぎる」または「バグではなく、機能です！」のいずれかです。
QAがバグであると言っていることが修正する必要があるかどうかを判断するための合理的な方法を見つけた人はいますか？

Answer 1

開発者として、QAで（息を切らして）誓うバグが常に発生することは知っていますが、言い訳で示されているように、修正/修正しないという決定を開発者に与えるべきではないと思いますあなたが言及する！最も謙虚なプログラマーは、自分のコードに現れるバグに憤慨しているため、苦労する誘惑に駆られる可能性があります。テスターと開発者の間の少しの摩擦は必要な悪だと思います（一日の終わりに彼らにビールを買うことを提供します！）。「それはバグではなく、機能です」は一般的なレトルトですが、有効な場合もあります。そのため、関与する重要な人物はおそらくビジネス側の人物です（それがあなたの仕事に意味がある場合）。

私の経験では、現時点で修正できない場合でも、記録する価値があります。いつでもスライディング優先度スケールを割り当てて、特定のレベルまで修正することができます。テスター/開発者と一緒に定期的にバグを確認することも役立ちます。

Answer 2

私が以前行っていた方法は、1人の担当者（プロダクトマネージャー）がバグと新機能の優先順位付けを担当するというものでした。PMは、次の基準に基づいて、各アイテムがバグであるか新機能であるかを判断しました。

• ソフトウェアが明らかに間違っていること（つまり、誰かが望んでいたことや意図したことではないこと）を実行する場合、それはバグです。
• ソフトウェアがソフトウェアの設計ドキュメントに反することを行い、明らかな利点がない場合、それはバグです。
• ソフトウェアが顧客（または他の誰か）が望んでいないことを実行するが、動作が設計ドキュメントに準拠している場合、それは機能要求です。

PMは、各バグまたは機能の要求について、エンジニアリングおよびクライアントの代表者と話し合い、それに基づいて（常識と経験とともに）各項目に優先順位を割り当てます。さらに、エンジニアリングは各アイテムのおおよそのタイムスケールを示すように求められ、PMはこれを使用して次の反復を計画します。

要するに、バグとは、ソフトウェアを設計した人が計画したことを実行しない場合であり、機能要求は、誰かがソフトウェアに計画外のことを実行させたい場合です。

Answer 3

SCRUM手法は、この質問に対する答えを提供します。プロダクトオーナーは、何かがバグであるかどうかを判断し、プロダクトバックログリストにアイテムを作成します。次に、アイテムはその優先度に応じて反復にスケジュールされます。

Answer 4

機能のバグと UI のバグは見つけやすく、議論の余地もありません。設計バグは、意見を得るために BA と開発チームを通過する必要があるものです。また、環境関連の問題は個別に追跡する必要があり、バグのカテゴリに分類されない場合があります。

Answer 5

いくつかの方法があります。それらのいくつか：

1. ソフトウェア要件は完全に記述されている必要があります。いくつかの要件が満たされていないことがわかった場合、それは明らかにバグです。

2. 要件が満たされていることがわかりますが、明らかではない形になっています。それもバグです。しかし、これは開発者が「すべて問題ありません」と言ってバグをクローズしようとする状況です。次の方法で、(欠陥が存在するという) 自分の意見を見つけることができます。

   • 同じ製品に類似したものがどのように実装されているかの例。
   • 同様の製品で同様のことがどのように機能するかの例 (たとえば、メール ホスティングの例として gmail を使用できます)。
   • 人々がこの機能に何を期待しているか、エンド ユーザーの観点からどのように機能する必要があるか、セールス マネージャーやカスタマー リレーションシップ マネージャーに尋ねてください。
   • 業界のベスト プラクティスを使用します。

3. 何かが機能していることがわかりますが、改善の余地があります。それも欠陥です:)。これはポイント 2 に似ており、そこに配置されたすべての推奨事項はこの場合にも役立ちます。

PS そして、他の部門の人々と議論、議論、議論します。