私のキャリアを通じて、私は QA とうまくやっていくためにさまざまな量の成功を収めてきました。個人的にバグ レポートを受け取ることは認めますが、通常は、「このプロセスはまだ機能していません!」という苦情のような形でフリーフォーム スタイルで作成され、欠陥を再現するのに十分な情報がありません。
批判に対して敏感になるように取り組んでいきたいと思っていますが、QA プロセスを非個人的にし、有益なバグ レポートを奨励するツールやテクニックにも興味があります。現在、バグは電子メールで報告されるか、場合によっては歩いて口頭で報告されます。
どのツールも、ビールのように無料で、インストールが簡単/管理が少ないものでなければなりません。また、バグ レポートに対して自分自身を鈍感にする方法についてのブログ投稿、本、または記事にもオープンです。
本物のバグ追跡システムを入手してください。FogBugz、Bugzilla、なんでも (私は Spolsky の悪ふざけではありませんが、テスターにとって FB ははるかに使いやすいシステムであり、使いやすさが本当に重要であると言えます)。これらにより、QA プロセスとバグ報告ワークフローの定義が非常に簡単になります。これにより、あなたとテスターとの間の個人的なやりとりが少なくなるはずです。
決して個人的に受け取らないでください。バグ追跡システムと個人的なやり取りの両方を通じて、常にバグが発生します。口調に関係なく、私はいつも「これを見つけてくれてありがとう、調べてみます」と答えます. 彼らは悪い日を過ごしているかもしれません、あなたは悪い日を過ごしているかもしれません、誰が知っていますか? 彼らが再現するのに十分な情報を提供しておらず、この情報を十分に一貫して提供していない場合は、#1 を参照してください (実際のワークフローを取得し、それに固執してください)。
ツールを忘れてください。これはコミュニケーションについてです。 何が問題なのか、どうやってそこにたどり着いたのか、その出来事に至った特定の状況を正確に教えてくれる規律を持った人が必要です。また、「壊れています」などの書き込みがあった場合は、フィードバックを提供できる必要があります。開発と QA の管理者は、双方から何が必要かについて話し合う必要があります。
感受性に関しては、態度がすべてに勝るということがわかりました。バグレポートを見るたびに、「これは個人攻撃ではありません。問題を解決し、何かを学ぶ機会です」という態度から始めなければなりません。 心の枠組みを設定すると、応答が続きます。
私たちが使用しているものは「ビールのように無料」ではないため、ツールの推奨事項は他の人に任せます.
あなたの最優先事項は、プロセスから自分自身を切り離す能力を育む必要があります. これは個人の問題ではありえません。そうは言っても、バグレポートを編集することは逆効果であることを（個人的に、またはCoCを通じて）QAに伝えてください（「このプロセスはまだ機能していません！」、あなたが書いたように、役に立ちません）。このプロセスの目的は、最終出力の品質を向上させることです。そのような叫び声はその目標を促進しません。
基本的に開発者 (自動回帰テスト) である QA 担当者として、私はこの問題の両面を見ることができたと思います。
他の何人かが述べているように、これはコミュニケーションの問題であり、それを解決するツールはありません。 bugzilla などのツールは通信の効率を向上させますが、通信回線を開いたままにしておくために両者が協力する必要があります。
私は、開発者がバグを個人的に受け入れるのに苦労することが多く、その問題が実際には問題であるにもかかわらず、「重要ではない」、「エッジケース」、「意図したとおり」などとしてそれらを一掃することにつながることを見てきました。問題が実際には重要でない場合でも、バグを修正する際のリスク/報酬の評価を共有するだけで、より良いコミュニケーションが促進されます。
逆に、QA 担当者は、バグの詳細とそれを再現する手順を省略していることがよくあります (私も含めて)。開発者として、不足している詳細に遭遇した場合、詳細を私たちに尋ねるのはあなたの仕事です (そして、親切かつ迅速に私たちに尋ねてください)。最悪の気分は、バグを書いて開発者に送った後、数日間何も返事がなく、「再現できません」として閉じられたときです。
最終的に重要なのは、双方からの迅速で親切なフィードバックです。私が (QA で) 開発者と一緒に仕事をしていて、私がバグを送ったときに常に反応し、問題の解決を喜んで手伝ってくれそうな場合は、時間をかけてできる限りの詳細を提供したいと思います。
開発者と同じように、QA には遵守すべき最低限の基準があります (または持つべきです)。問題を提起するときは、次の情報を提供する必要があります。
QA に行って、何が問題なのか、どのように問題が発生したのかを尋ねなければならない場合、私はイライラします。「これはうまくいかない」だけでは十分ではありません。
私が開発した 1 つのシステム (Web レポート システム) では、生成されたレポートごとにすべての入力データを生成しました。QA がレポートを実行して問題に気付いた場合、ブラインド URL に移動して、以下を含む ZIP ファイルをダウンロードできます。
開発側では、その ZIP ファイルのみに基づいてレポートを再実行できるツールを作成しました。これにはいくつかの効果がありました。
その効果は非常に大きく、それは 1 つの重要な問題を浮き彫りにしていると思います。開発者は、テストや再現が難しいものを好まないということです。同様に、QA 担当者は仕事を難しくするものは好きではなく、仕事を楽にするものは何でも好みます。
したがって、QA と調和して作業するための私のアドバイスは次のようになります。
ポール・ウィリアムズに同意します。QAが問題を提出するために使用しているプロセスを改善する必要があるようです。電子メール、および問題のステータスの口頭での伝達は、改善の余地があることを示唆しています。また、開発とQAが協力してプロセスとコミュニケーションを改善するという彼のアドバイスにも同意します。私はQAエンジニアであり、これを10年以上行っています。
あなたは誰にも爆破しないためにあなたに非常に成熟した大きな小道具に聞こえます。「まだ壊れている」という趣旨の言葉を書いても大丈夫ですが、QA担当者はもっとタクトを学ぶ必要があることは明らかです。
私はAnthonyWJonesが送信しているメッセージに完全に同意しません。どの企業にも独自の文化があることは承知していますが、彼の回答の言い方は、「壁を越えて、QAは私ではなく品質に責任がある」という態度を示唆しています。特にそれは何も悪いことではありませんが、協力的で心のこもった環境を育てたいのであれば、それは役に立ちません。より健康的な文化とは、開発チーム全体（QAを含む）が品質に対して同等の責任を共有する文化です。
非個人化するためのツールは、私には間違った方向に思えます。
「まあ、それは私たちが修正する必要がある非常に重要なバグのようです。見つけてくれてありがとう、おい。
どうやって再現しようか迷っています。あなたはなにか考えはありますか？または詳しい情報は？」
うわー、あなたが書いたそのバグ レポートは本当に素晴らしかったです。バグを特定するのに多くの時間を節約できました。ありがとう！
ビールを飲みに行きませんか？ビール、無料？
等
一緒にバグを解決したり分析したりするとき、私は QA で最高の経験をしました。プログラマーも QA エンジニアも、仲良くするのが最も簡単な人ではなく、これらのグループの間には根本的な緊張関係があります。
私のコードに対して提出されたバグレポートに問題があったときは、彼らのところに行き、正確に何を意味するのかを尋ねたり、それらを再現する手順を説明したりします. 多くの場合、問題は私が要件を読んだ方法と一致していませんでしたが、彼らはそれがうまくいくと想定していました。あなたは人間のように、ある公式に従ってではなく話し、一緒にそれを理解します (反対することに同意し、他の誰かに電話をかけてもらうことは、ここではオプションです)。
メールやバグトラッカーに提出されたバグレポートは、その言い方が不快に感じるかもしれません。バグを報告している人と話すと、世界/ソフトウェアを少し良くするという共通の目標に気付くかもしれません。
QA に対する私の態度は、それが相互尊重の関係になったという点で報われました (私たちのどちらもそれを認めませんでした:P)。何かがバグであるとすぐに主張する代わりに、彼らは最初に私に近づいてきました. 結局、私たちは皆自分の仕事をしています。ソフトウェアを書くのはプログラマーであり、そのソフトウェアに穴を開けるのは QA エンジニアです。そして、私が間違ったことを教えてくれた非常に優秀な人々と一緒に仕事ができたことにとても感謝しています。
ああ、 「これはバグではなく機能です」というフレーズは絶対に使用しないでください。
「あなたと一緒に仕事をするのは私を殺している!」を読んでください。人々はただ 1 日を過ごし、お金を稼ぎ、家に帰りたいだけであることを認識してください。「小さなことを気にしないでください。」
プロジェクトプロセスにより多くの人を巻き込むようにしてください。QA担当者が開発者と同等の意見を述べる定期的な回顧展があります。彼らは頻繁に、彼らの仕事をより簡単にし、彼らが品質を確保することをより簡単にするプロセスを改善することができる方法を提案します。そしてさらに重要なことに、これらの提案は議論され、（合意された場合）採用されます。これにより、QAと開発者は同じプロセスの一部になり、反対にはなりません。
開発者が自分のコードに責任を持つことも重要です。QAがエリア内で多くのバグを見つけている場合、それは開発者がそれを書くというお粗末な仕事をしたためです。QAが難しいからではありません。開発チームはすべてこれを認識する必要があります。
「機能していません」などのステートメントを処理する最善の方法は、返信で同様の簡潔な質問を使用することです。「ありがとう、でも、あなたが見つけたものについてもっと話してくれませんか？」. 次に、ボールをコートに残します。
返信していないという苦情がある場合は、詳細情報のリクエストを示すことができます。QA の仕事は、保証する責任がある品質を具体的に満たしていないものを定義することです。
職場に共有ポイント (またはウィキなど) はありますか? 問題ログを設定して、すべての人が無料で見られるようにするのは非常に簡単です。追跡ツールの選択については触れませんが、たくさんあります。無料が必要な場合は、SourceForge または Codeplex を確認してください。
助ける最大のことは、それを個人的に受け取らないことです - 彼らはあなたと同じように仕事をしています。現在使用している電子メールでも、「受け入れ可能な」バグ レポートの形式を設定すると役立ちます。
少なくとも、以下を含める必要があります。
まともな QA 担当者は、既にこれを行っており、スクリプトをテストしているはずです。
ツールはあまり役に立たないと思います。
QA に、問題を再現するための手順を書くように依頼します。
これにより、彼らの考えが整理され、QA が言いたいことを理解するのに役立ちます。
リモート チーム メンバーである私にとって、バグ追跡ツールは不可欠です。そして私の経験では、それらはプロセスを「非個人化」するのに本当に役立ちます.