QA 行動規範に関する適切なリソースを見つけることができませんでした。これを文書化し始めたいと思います。私が抱えている主な問題は、次のような本当に基本的なものです。
次にクライアントやチーム メンバーが「このコードはひどい」と不平を言うときに、実際には「このコードはビジネス目標を達成していない」と言うべきであるのに、配布できるドキュメントが本当に欲しいです。
これは、技術的な問題というよりも、対人関係の問題のように思えます (最後の点を除いて)。
人々が礼儀正しく、お互いを尊重していないと感じた場合、多くの解決策 (コンサルティング、コーチングなど) がありますが、それは技術的な問題ではなく、社会的な問題として考慮し、扱う必要があります。
それが不平を言う側の単純なエラーである場合、ある種の内部トレーニングが役立つかもしれません。残念ながら、私はそのための適切な行動規範を知りません。
バグを報告するためのガイドラインがいくつかあります。
https://developer.mozilla.org/en/Bug_writing_guidelines
http://catb.org/esr/faqs/smart-questions.html
これらは出発点かもしれません。しかし、多くはあなたの環境やソフトウェアなどに固有のものであるため、すぐに使用できるものを見つけることはまずありません.
古い Joel の記事が役立つかもしれません: Painless Bug Tracking、出典:
良いバグ レポートのルールを覚えるのはとても簡単です。すべての優れたバグ レポートには、正確に 3 つのものが必要です。
- 再現する手順、
- あなたが見たいと思っていたもの、そして
- 代わりに見たもの。
簡単そうですよね？そうでないかもしれない。プログラマーとして、人々は定期的に私にバグを割り当てます。
可能であれば直接、そうでなければ電話で誰かと話をするために数分を費やしてください.
バグ追跡システムの電子メールのみを使用すると、両者が問題について不満を感じるような状況が実際に発生する可能性があります。
のレベルでのコミュニケーションから得る必要があります。
「これはだめだ」
に
「これやあれをすると本当に混乱し、その後、これが起こります。」
問題が発生する理由と場所、およびテスターや顧客に多大な不満を引き起こしている可能性がある小さな問題を理解する必要があります。
また、物事がそのようになっている理由を理解するのを助ける必要があるかもしれません。
そして、問題があることを知っているかもしれませんが、それは危険であるか、より重要な問題が優先されるため、今すぐ修正することはできません.
私は混乱しています - あなた
が本当にドキュメントが欲しいと言うとき、クライアントやチームメンバーが次に「このコードはひどい」と不平を言うときに、実際には彼らが言うべきことは「このコードは達成できません」私たちのビジネス目標」です。
違いは何ですか？用語？コードがうまくいかない、または達成できない、またはさらに悪いことに、それを使用しないか、料金を支払わずにクライアントを失うと、彼らがどのように言うかを心配する代わりに、コード/アプリケーションを実際にあるべき場所に到達させる方法に焦点を当てる必要があると考えるようになります。よりポジティブな反応を得るために。彼らがフィードバックをくれて、あなた/あなたの会社を無視していないことに満足してください. できる限りすべての否定的なフィードバックを取得し、
「これは動かない」などのバグ報告があまり役に立たないのは事実ですが、誰もがプログラマーであるとは限らないことを認識しておく必要があります。
「不平を言う」ほとんどの人は、自分がどのような情報を提供すればより役立つかがわからず、自分が何について話しているかを知っていると思い込んでいます。彼らはまた、正確な書面によるコミュニケーションに常に慣れているとは限らないため、自分の「口調」に気づいていないこともよくあります (管理者タイプでさえ、これを露骨に知らないことがあります。プログラマー OTOH は、短いテキスト ブロックにぎっしり詰め込まれたセマンティクスは、彼らが生計を立てているためです)。
バグを理解するために知っておくべきことを説明する必要があります (つまり、バグを再現したり追跡したりできるようにするため)。バグ追跡システムに存在する場合、Mozilla のようなガイドラインは大いに役立ちます。バグ追跡システムの大部分が、QA が怒りの手紙を送ることで構成されている場合は、実際に直接彼らと話し、彼らが気にかけているのであれば、彼らがどのように役立つかを説明する方がおそらくうまくいくでしょう。
彼らが気にしないなら、あなたはとにかくめちゃくちゃです。
ここにいくつかの良い答えがあります。私たちは、優れたバグ追跡データベースに何が必要かを知っています。これらの同じ機能を適切に使用すると、バグ報告者の教育に役立ちます。
ここで、適切なバグ データベース モデレーションの出番です。バグはすぐに認定して分類する必要があります。欠落しているすべてのデータはユーザーの裁判所に戻されるべきであり、提供されない場合、バグは保留されます。1 か月間のデータはありません。ユーザーにとって重要ではありません。バグ レポートは閉じられています。
顧客が自分のバグの優先順位をすぐに下げる (「ときどき 1 人の顧客にしか影響しない」)、取り残される (「再現できない」、「特定するための十分なデータが提供されない」)、脇に追いやられる (「不足している情報を待つ」、「再分類される」) のを目にした場合、等々、彼らはすぐにプレートにステップアップしてボールをプレーしなければならないことに気付くでしょう. より多くの正確な情報を提供しないと、情報が山積みになり、次のマイナー リリースで完全に消えてしまいます。
ユーザーの些細で皮肉なコメントは、バグ データベースに永久にエンコードされます。丁寧な応答、またはさらに良いことに、自動化された応答は、開発者側からの唯一のものです。データの新しい入力はすべて、ありがとうとバグステータスの変更により、人間によって対処されます。
確かに、彼らはバグを適切に報告するために必要な努力の限界について不平を言うでしょう。彼らは優先順位について不平を言うでしょう。彼らは、タイムアウト後または次のソフトウェア リリースでバグがクローズされたことについて不平を言うでしょう。あなたはただ肩をすくめて言います、もしそれがそんなに重要なら、彼らはあなたと協力してあなたが必要とするものをあなたに与えるでしょう.
彼らが復讐したい場合は、問題を継続的に再現し、それに関するデータをさらに入力することで、バグを開いたままにしておくことができます。次に、バグを修正するために必要なものがあります。