テスターと開発者のコ​​ミュニケーション

開発者-開発者、開発者-クライアント、開発者-チームマネージャーのコミュニケーションについて多くのことが書かれていますが、テスターと開発者のコ​​ミュニケーションと関係についてのガイドラインを示すテキストは見つかりませんでした。

テスターと開発者が別々のチームであるか同じチームであるかに関係なく（私の場合、私はアジャイル開発プロジェクトで唯一のテスターです）、テストが受け入れられるためには、テスターがどのように認識されるかが非常に重要であると信じています、そしてプロジェクトの質を向上させるという目標を果たすために（たとえば、彼らを警察と見なすべきではありません）。

テスターが開発者とどのようにコミュニケーションを取るべきかについてのアドバイスや研究はありますか？

更新：回答ありがとうございます。彼らはすべて私が考えていたものを確認しました。今のところ、私のチームは私の役割を非常によく受け入れており、最終的には本当に進歩しました。答えとして複数選択することもできましたが、自分で決断する必要がありました。

コミュニケーションを改善する最も簡単な方法は、開発者（およびデザイナーやアーキテクトなど）と協力してこれらのばかげた役割をゆっくりと分解し、最終的に私たち全員がテスターであることを認識することです。

アジャイルの場合は、「本によって」それを実行してください。テスターはチームの一部であり、完了時にあなたが引き渡す外部エンティティだけではありません。あなたの大切な専門知識は、開発全体を通して使用されます。まず、ユーザーストーリーを作成するときに、受け入れテストを導出して自動化するのに役立ちます。これらのテストは、開発者が作業で使用します。また、部分的および完了した作業の探索的テストに毎日時間を費やし、POと話し合ってテストを明確にし、継続的に改善します。

「一緒に仕事をする」とはそういうことです。これがチーム内のコミュニケーションがどのように機能するかを完全に確信しています。この記事はそれを非常によく説明しています。

これとは反対に、多くの組織は、すべてのテスター（およびDBA、設計者とプログラマー）を別々の部門に配置して開発を処理することを好みます。これはコミュニケーションに反して機能し、段階的な開発のアイデアを固めるだけに役立ちます。このような状況でコミュニケーションを改善しようとすることは可能ですが、期待できる小さな改善は努力する価値はありません。少なくとも、実際に人々を同じ部屋に配置し、部門を超えたチームを作ることとは比較になりません。

私は開発者とテストの間のあらゆる種類のコミュニケーションを固く信じています。

あまりにも頻繁に、各チーム間でのパンの戦いを繰り返し見たことがあります（「デザインによって閉じられて」、その後「再開されて」など）。

私はいつも一緒に仕事をしているテスターに​​、疑いがないかどうか話しかけてくれるように言います。

私が本当に嫌いなことの1つは、テストについて傲慢になり、それについて話し合う開発者です。そのため、テストチームとの良好な関係を促進するために私ができることは何でもできるようにしています。

テスターは、エラーやテストについて連絡するとき、開発者に対して非常に明確かつ正確でなければなりません。エラーを再現する手順の詳細なリスト、必要に応じてスクリーンショット...再現できない、または再現する手順が不明確なエラーのあいまいな説明は、開発者とテスターの関係を非常に早く混乱させます。

開発者とテスターの間には常に不一致があるとは信じていませんでしたが、私の親友の1人が私が働いている会社でテスターの役割を得たとき、この状況に直面する必要がありました。私が開発していたのでFUN、彼と一緒に仕事をしているので、そのような状況で他の人の意見を理解し、自分のエゴをコントロールすることは非常に重要であると言う必要があります。これは私を大いに助けてくれました。コミットメントと個人的な友情のレベル。

あなたはアジャイル環境で唯一のテスターであると述べたので（スクラムを想定）、おそらく遡及的ミーティングをオープンフォーラムとして活用して、コミュニケーションのプロセスを定義することが適切な場合があります。

ご存じのように、再帰的会合はスクラムプロセス内のしわに対処することです。これらは、開発者の時間が中断時間、電子メール月曜と合っ何週の残りの部分、口頭での通信のみのxy許可などのアイテムかもしれないあなたのチーム。コミュニケーションが1つのサイズですべてのアプローチに適合することはありません。

開発者として、主導権を示すテスターに​​感謝します。彼らは線を引いていない...彼らは欠陥を解決したい。根本的な原因に関係なく。開発者とテスターは、感情をビジネスから切り離す必要があります。人間が関与しているため、欠陥はビジネスの一部です。欠陥を解決するための最良のアプローチは、欠陥を全体的に解決するために調整されたチームセットです。ラインが浮上し始め、境界線が配置されたとき。通信が壊れます。

毎日のスタンドアップ会議を活用してください。可能な限り関与してください。テストだけでなく、製品全体についても。結局のところ、開発者とテスターは1つの目標に取り組んでおり、常にそれに焦点を合わせておく必要があります。

同じチームの一員としてテスターを見るのが好きです。その点ではコミュニケーションの問題はありません。

テスターが開発者またはその他の方法で話す必要があるときはいつでも、チャットしてみましょう。ただの日常です。

ただし、両者はお互いを尊重し、適切に仕事をする必要があります。

テスターは、バグの状態に関する詳細を提供する必要があり、仕様どおりにバグとして報告しないでください。特に、疑わしい機能のように見える何かについて、あそこの男に尋ねるだけでいいとき。

5回のクリックでバグを再現しない場合、開発者はバグレポートを真剣に受け止め、問題をクローズするだけでなく、徹底的に調査する必要があります。

プロの態度がすべてです。

私がテスター（SDET）として開発とテストの関係を改善するために活用できることがわかった一番のツールは、特に開発者からメンターシップを求めるという形で、正直なお世辞です。

うまくいけば、私と一緒に働く開発者は私よりも優れた開発者です。彼らは完璧ではありません、または私には仕事がありませんが、彼らは私よりもよく知っていることがたくさんあります。それらは純粋な開発でしたが、私の注意は部分的にテストに集中しています。私は彼らがより良いことをしていることに気づき、頻繁に言及します。彼らのコードを読むとき、エレガントな詳細やデザインパターンのきちんとした使い方に気づき、それらを会話に持ち込みます。私は開発者を真似て、可能な場合は同様のコーディング規則を使用し、必要に応じて本番のコンポーネントをテストツールに統合します（たとえば、ロギング）。私は彼らの専門知識を認識しており、その結果、彼らは私のことを認めてくれてうれしいです。心に留めておいてください。より良い方法があると思うなら、私は絶対に率直に言います。しかし、私は否定よりも肯定的なフィードバックを与えることを目指しています、全体。一般に、私は否定的なフィードバックをより形式的で非個人的なもの（バグレポートなど）にし、肯定的なフィードバックを形式的で個人的でないもの（例：直接の会話）にするようにしています。

品質についての肯定的なフィードバックと否定的なフィードバックを与えてアドバイスを求めることは、関係を、論争から、チームワークや相互学習についてのものに変え、防御力を低下させます。開発者は、私が常に悪いことよりも良いことを言うように私を信頼できることを知っているので、彼らは私に耳を傾けて快適に感じます。また、開発について洞察に満ちた質問をすると、私に対する意見が高まり、「SDETは失敗した開発者」というステレオタイプ（まだ存在する場合）を突破します。

開発者とテスターの間の良好なコミュニケーションが重要であると私は固く信じています。最善の方法については、多くの良いアプローチがあると確信していますが、ここが私にとって最も効果的な方法です。

直接/個人的なコミュニケーション！メールではなく個人的なコミュニケーションが常に最も効果的であることがわかりました。開発者とテスターが個人的な関係を形成することができます。あなたがそれを手に入れたら、物事はよりうまく機能するように見え、流れる傾向があります。彼らは特別なテストを実行したり、あなたのために余分のマイルを行くことに問題を抱えたことはありません。同じことが開発者にも当てはまります。私は常に余分な時間をかけて、彼らが助けを必要とする、または問題を抱えていることを確認します。私の経験では、問題の解決が速くなり、無駄な時間が減っています。