私は多くの Web サービスに取り組んでいますが、実質的に主要なビルドを作成するたびに、QA がバグを吐き出し始めます。これらのバグは、サーバー側のコードとは関係なく、それらのがらくたクライアント ライブラリとは関係がないことがよくわかります。私は少なくとも、彼らがサーバーにプッシュしている XML なしでバグを報告しないというポリシーを作ろうとしましたが、彼らはしばしばこの要件を無視しています。
1450 次
7 に答える
7
これはおそらく、プログラミングよりも仕事の方針や手順に関係しています。
しかし、最も単純な形では、立証責任は QA にあり、有罪が証明されるまでは無実です。QA からバグが報告された場合、彼らは利用可能な最大のデータを使用してそれを行う必要があります。これにより、彼らの側に誤検知だけでなく、実際にバグが存在することが証明されます。これに満たないものは、彼らのプロ意識の欠如です。
ポリシーを確立し、それを順守して、無駄な時間を最小限に抑える必要があります。彼らのテストをデバッグすることは受け入れられませんし、あなたの仕事でもありません。
于 2009-05-26T20:57:13.587 に答える
5
この質問は、おそらく、より広い一般化の下で提出できます。
「どうすれば同僚に仕事をきちんとしてもらうことができますか?」
于 2009-05-26T20:56:15.087 に答える
1
「修正しない - バグではない」としてマークし、QA に戻します。
于 2009-05-26T21:32:25.107 に答える
0
2つの別々のもの。
最初の QA では、バグ レポートに XML を含める必要があります。彼らが知っている関連情報はすべてバグレポートに含める必要があります。他の人が示唆したように、必要に応じてこれをエスカレートしてください。
次に、クライアントに問題がある場合は、ユーザーが同じライブラリを使用するかどうかを確認してください。クライアント/ライブラリ/サービスをチェックする方法を変更するよう QA に依頼しない場合。質問しても問題が解決しない場合は、エスカレートして、どれだけの時間と費用がかかるかを示します。はいの場合、そのライブラリでサービスを機能させる方法を理解する必要があります。
このエスカレーションまたは別のエスカレーションが必要になる場合があります。
于 2009-11-03T22:28:52.877 に答える