テスターと開発者のコミュニケーション
開発者-開発者、開発者-クライアント、開発者-チームマネージャーのコミュニケーションについてはたくさん書かれていますが、テスターと開発者のコミュニケーションと関係についてのガイドラインを示すテキストは見つかりませんでした。
テスターと開発者が別々のチームであるか同じチームであるかに関係なく（私の場合、私はアジャイル開発プロジェクトで唯一のテスターです）、テストが受け入れられるためにはテスターがどのように認識されるかが非常に重要であると信じています、そしてプロジェクトの質を高めるという目標を果たすために（たとえば、彼らは警察と見なされるべきではない）。
テスターが開発者とどのようにコミュニケーションを取るべきかについてのアドバイスや研究はありますか？
更新：回答ありがとうございます。彼らはすべて私が考えていたものを確認しました。今のところ、私のチームは私の役割を非常によく受け入れており、最終的には本当に進歩しました。答えとして複数選択することもできましたが、自分で決断する必要がありました。
コミュニケーションを改善する最も簡単な方法は、開発者（およびデザイナーや建築家など）と一緒に作業し、それらのばかげた役割をゆっくりと分解し、最終的にはallはテスターですが、一部の人は他の人よりも経験が豊富です。
アジャイルの場合は、「本によって」それを実行してください。テスターはチームの一部であり、完了時にあなたが物を引き渡す外部エンティティだけではありません。あなたの大切な専門知識は、whole開発中に使用されます。まず、ユーザーストーリーを作成するときに、受け入れテストを導出して自動化するのに役立ちます。これらのテストは、開発者の作業で使用されます。また、毎日、部分的および完了した作業の探索的テストに時間を費やし、POと話し合って、テストを明確にし、継続的に改善します。
「一緒に仕事をする」とはそういうことです。これがチーム内のコミュニケーションがどのように機能するかを完全に確信しています。これは 記事 で説明しています。
これとは逆に、多くの組織は、すべてのテスター（およびDBA、設計者とプログラマー）を別々の部門に配置して開発を処理することを好みます。これはコミュニケーションに逆らって機能し、段階的な開発のアイデアを固めるのに役立ちます。そのような状況でコミュニケーションを改善しようとすることは可能ですが、期待できる小さな改善は努力する価値はありません。少なくとも、実際に人々を同じ部屋に配置し、部門を超えたチームを作成することとは比較できません。
私は開発者とテストの間のあらゆる種類のコミュニケーションを固く信じています。
あまりにも多くの場合、私は各チーム間でのパンの争いを見ました。
私はいつも一緒に働くテスターに、疑いがある場合は来て話しかけるように言います。
私が本当に嫌いなことの1つは、テストについて傲慢になり、それについて話し合う開発者です。そのため、テストチームとの良好な関係を育むために私ができることは何でもできるようにしています。
開発者とテスターの間には常に不一致があるとは信じていませんでしたが、私が働いていた会社で親友の1人がテスターの役割を果たし、驚いたことに彼がテストするために同じモジュールを割り当てられたとき、この状況に直面しなければなりませんでした私が開発していたので、実際にFUN彼と一緒に働いていました。そのような状況で他の人の意見を理解し、自分のエゴをコントロールすることは非常に重要であると言う必要があります。これは私と男たちは私たちの職業的責任と個人的な友情のレベルでうまく調和します。
テスターは、エラーやテストについて連絡するとき、開発者に対して非常に明確かつ正確でなければなりません。エラーを再現する手順の詳細なリスト、必要に応じてスクリーンショット...再現できない、または再現する手順が不明確なエラーのあいまいな説明は、開発者とテスターの関係を非常に早く混乱させます。
あなたはアジャイル環境の唯一のテスターであると述べたので（スクラムを想定）、遡及的ミーティングをオープンフォーラムとして活用して、コミュニケーションのプロセスを定義することが適切な場合があります。
ご存じのように、再帰的会合はスクラムプロセス内のしわに対処することです。これらは、開発者にX-Yの中断のない時間を許可したり、月曜日にメールのみのコミュニケーションを行ったり、週の残りの時間を口頭で伝えたりすることができます[〜＃〜] your [〜＃〜]チーム;コミュニケーションが1つのサイズですべてのアプローチに適合することはありません。
開発者として、主導権を示すテスターに感謝します。彼らは線を引いていない...彼らは欠陥を解決したい。根本的な原因に関係なく。開発者とテスターは、感情をビジネスから切り離す必要があります。人間が関与するため、欠陥はビジネスの一部です。欠陥の解決への最良のアプローチは、欠陥を全体的に解決するために調整されたチームセットです。線が浮上し始め、境界線が配置されたとき。通信が壊れます。
毎日のスタンドアップ会議を活用してください。可能な限り関与してください。テストだけでなく、製品全体についても。結局のところ、開発者とテスターは1つの目標に取り組んでおり、常にそれを重視する必要があります。
私がテスター（SDET）として開発とテストの関係を改善するために活用できることがわかった一番のツールは、特に開発者からメンターシップを求めるという形で、正直なお世辞です。
うまくいけば、私と一緒に働く開発者は私よりも優れた開発者です。彼らは完璧ではない、または私には仕事がありませんが、彼らは私よりもよく知っていることがたくさんあります。それらは純粋な開発でしたが、私の注意は部分的にテストに集中しています。私は彼らがより上手く行っていることを指摘し、頻繁に言及します。彼らのコードを読むとき、私はエレガントな詳細やデザインパターンのきちんとした使い方に気づき、それらを会話の中で取り上げます。私は開発者を真似て、可能な場合は同様のコーディング規則を使用し、本番環境のコンポーネントをテストツール（ロギングなど）に統合します。私は彼らの専門知識を認識しており、その結果、彼らは私のことを認めてくれてうれしいです。心に留めておいてください。より良い方法があると思うなら、私は絶対に率直に言います。しかし、私は全体として、否定よりも肯定的なフィードバックを与えることを目指しています。一般に、私は否定的なフィードバックをより形式的で非個人的なもの（バグレポートなど）にし、肯定的なフィードバックを形式的で個人的でないもの（例：直接の会話）にするようにします。
質についての肯定的なフィードバックと否定的なフィードバックを与えてアドバイスを求めることは、関係を論争からチームワークと相互学習についてのものに変え、防御力を低下させます。開発者は、私が常に悪いことよりも良いことを言うように私を信頼できることを知っているので、彼らは私に耳を傾けて快適に感じます。また、開発について洞察に満ちた質問をすると、私に対する意見が高まり、「SDETは失敗した開発者」というステレオタイプ（まだ存在する場合）を突破します。
開発者とテスターの間の良好なコミュニケーションが重要であると私は固く信じています。最善の方法については、多くの優れたアプローチがあると確信していますが、ここが私にとって最も効果的な方法です。
直接/個人的なコミュニケーション！メールではなく個人的なコミュニケーションが常に最も効果的であることがわかりました。開発者とテスターが個人的な関係を形成することができます。あなたがそれを手に入れたら、物事はよりうまく機能するように見え、流れる傾向があります。彼らは特別なテストを実行したり、あなたのために余分のマイルを行くことに問題は決してありません。同じことが開発者にも当てはまり、私は常に余分な時間をかけて、彼らが助けを必要とする、または問題を抱えているものを見るようにしています。私の経験では、問題の解決が速くなり、無駄な時間が減っています。
同じチームの一員としてテスターを見るのが好きです。その点ではコミュニケーションの問題はありません。
テスターが開発者またはその他の方法で話す必要があるときはいつでも、チャットしてみましょう。ただの日常です。
ただし、両者はお互いを尊重し、適切に仕事をする必要があります。
テスターは、バグの状態に関する詳細を提供する必要があり、仕様どおりにバグとして報告しないでください。特に、疑わしい機能のように見える何かについて、あそこの男に尋ねるだけでよいとき。
開発者は、バグレポートを真剣に受け止め、5回のクリックでバグを再現しない場合は、問題を閉じるだけでなく、徹底的に調査する必要があります。
必要なのはプロの態度だけです。