プログラマーとしての私のキャリアの間に、私はさまざまなプログラマーとテスターを見てきましたが、それらの多くはお互いが好きではありませんでした。つまり、プログラマーはテスターの仕事は「本当の」仕事ではないと考えており、テスターはプログラマーがあまりにも「誇りに思っている」と考えています。
これは私によってなされた正しい決定ですか、なぜですか、これらの種類の問題を回避するために私たちは何ができますか？
回答:
私はそれが一般化と単純化の大過剰だと思います。
私は現在テスターです。開発者とほぼ同じくらいのコードを書いています（テスト段階に依存します）。会社の私の親友は開発者であり、私たちは皆仲良くしています。
あなたはあなたの答えを見つけるために、企業文化とチームがお互いに関して仕事をする方法を見てみたいと思うかもしれません。私の経験では、非常に反動的なワークフロー（つまり、開発者が「壁を越えてビルドを投げてテストし、バグを投げ返す」）がある場合、異なるフォーカスポイントまたは「攻撃ベクトル」から一緒に作業するのではなく、両方の部門は一般的に、お互いを嫌うでしょう。
私が働いている場所では、すべての機能チームまたは設計チームが、出力を生成するために協力している開発者とほぼ同じ数のテスターを持っています。その出力は、テストコードで定められた要件を満たす製品コードです。
編集する
また、テスターは開発者よりもテスターに責任があり、両者の関係をサポートしていると思います。
開発者の生活を良くしたり悪くしたりするのはずっと簡単ですが、目標は単に「バグを見つける」だけでなく、潜在的な解決策を見つけることです。できない場合はできません。その時点でバグを割り当てられた人と協力して解決策を見つけます。しかし、それが単純なソリューションである場合は、さまざまな要件と最終的な回帰テストを作成する潜在的な修正と思われるものを提供します。
私は愛、私のテスターを-彼らは私トラブルシュートと私は問題としては考えられないだろうが、我々の顧客があろうとスポット物事を助けます。そして、私にとって最も重要なのは、悪いコードで誰かを殺さないようにすることです。
なぜ問題が発生するのですか？
上記とポジションの性質の組み合わせは、現在の怒りとフラストレーションをお互いに簡単に取り除くことができることを意味します。それを抜け出すのは難しく、誰にとっても良くありません。
プログラマがプログラムを作成し、テスターが実際に最終製品の改善の一部であるにもかかわらず、テスターがその欠陥を見つけようとするために起こると思います。誰かがあなたが多くの努力を注いだものに欠陥を見つけるときはいつでも、おそらくそれらに否定的に反応することは自然な反応です。
これを軽減する方法は、開発者とテスターが完成した製品をチーム全体（テスターと開発者を含む）の出力と見なし、テストがスタンドアロンの障害発見ミッションではなく、テストの重要な部分であることを理解させることです。開発プロセス。開発者がテストを実際の仕事だと思わない場合、または簡単だと思う場合は、テストマトリックスの作成、数百のテストケースの実行、すべてのステップとすべての結果の文書化を依頼してください。
私は特定のプログラマーと特定のテスターを知っていますが、あなたが述べた理由ではなく、お互いのために働いているからです。
それは獣の性質です。私が知っている特定のテスターの中には、コードが不注意/怠lazなどでエラーを起こしやすいと感じたため、特定のプログラマーを気にかけなかった人もいます。特定のテスターを気にしない私が知っている特定のコーダーの一部は、ばかげて考案されたテスト条件を使用している（ニットを選ぶ）か、スタイルに基づいてコードの修正を要求していると感じました。
パーソナリティを排除し、目の前のタスクに集中することは、緊張を和らげるのに大いに役立つと思います。組織が十分に大きい場合、二重盲検テストは素晴らしいアイデアです。
問題を明確に表現できるテスターと、ソリューションを明確に実装するコーダーは素晴らしいチームです。
私がテスターと緊密に協力したチームでは、私たちは素晴らしくうまくいきました。テスターは、さまざまな決定が下された決定を理解し、開発者のスケジュールがどのようなものかを理解し、2つのグループの間に信頼関係を築きます。
テストがオフショアの不定形エンティティであるチームでは、そうではありませんでした。テスターの結果は、何が起こっているのかをあまり知らないため、関連性が低くなります。開発者は、プログラムの2つの部分に触れていない、重要でないと思われる詳細の洪水を恐れ始めます。数か月間、テストチームは、提出されたバグが修正されていないことに腹を立てます（スケジュールが台無しになり、開発者がデモの準備や要求された機能の追加などで忙しくなるため）。チームメンバーではなく「その他」。
密接に働くと物事はうまくいきます。誰かが両方のチームが調整され、同じページにいることを確認する必要があります。私の最高の経験、テストチームは、開発チームが招待されたハイレベルの会議（すべて）に招待され、全員がスケジュールを知っており、優先順位リストが統一され、開発者とテストの両方が同じ（up-最新の）要件ドキュメント。私の最悪の経験（テストなし以外）は、基本的に私たちのものをパッケージ化し、海外に出荷して見た後、1か月後にすべてのものを取り戻しました。テストチームの期待ではありません）。
devもtestも、どちらも成功しなければ成功しません。同じマシンの2つの半分のように作業し、より直接的なチームメンバーを尊重するのと同じくらい相手側を尊重する場合、問題はありません。2つの別々のマシンのように動作し、マシンが優れていると仮定すると、事態はひどくなります。
テスターと開発者が「テストチーム」と「開発チーム」ではなく、同じチームに属している場合、これらの問題が大幅に軽減されることがわかりました。これが、テスターとして、ウォーターフォール開発よりもアジャイルチームでの作業を強く好む理由だと思います。コミュニケーションが増え、ターンアラウンドが速くなり、開発者は、その作業がより透明になったときにテストに費やす時間と才能を高く評価します。
個人的にも、できることはたくさんあります。テスターとして、バグを見つけるだけでなく、肯定的なフィードバックを提供することで、この摩擦を減らすことができます。私は多くを教えることができなかった開発者のためにまだテストしていません、そして、開発者はコードを理解するために本当に働いているテスターに感謝します。優れた職人のように、開発者は誇りに思っています。バグがあるからといって見劣りするものではないことを知らせることが重要です
私が最も簡単に作業できると判断した開発者は、高品質を高く評価し、事前テスト（主に自動化された単体テストと手動スモークテスト）を含む、テスターが見る前に高品質のコードを書く努力をしてそれを実証しました。また、これらの開発者は、テストを容易にするためにコードレビューを行うようテストに依頼し、できるだけ早くプロセスにテスターを含めました（テストの負荷が軽い場合は、テスターがテスト戦略の計画を早期に開始できるようにします）。開発者は、テスターが急いで開発された領域、またはユニットテストが困難な領域を伝えることにより、テスターがコード内の脆弱な領域を見つけるのを支援できます。一般に、開発者がテスターの仕事を簡単にするためにできることはすべて高く評価され、テスターの時間だけでなくテスターの時間も大切にしていることを示しています。開発者がこれを行うと、
もう1つの問題は、多くの企業がQAを後から考えることが多いことです。多くの場合、土壇場でプロジェクトについて通知され、開発チームと比較して人員が大幅に不足しています。一部の地域では、開発者への道は技術サポート、QA、そして開発者です。ですから、開発者になりたいと願う人がいることもあります...そして、欠陥を見つけたときの態度は、その人が私ではなく開発者になることができるということです。
全体として、QAチームが大好きです。また、ユニットテストはQAとは別にソフトウェア開発の必要な部分であるべきだと思います。そのため、QAがバグを見つけると、ユニットテストが変更されてバグがテストされます。さらに、ユニットテストを行う開発者は、QAが何を見つけているかをよりよく理解できると思います。
さらに、多くのQAチームは手動で作業を行う必要があります。その場合、それは本当に退屈な仕事です。いくつかの場所では、QAはスクリプトを作成し、GUIのスクリプティングを許可する自動化プログラムを使用します（ボタンなどの画面上の何らかの画像認識を通じて）。その後、最初に大きな変更が発生するのはまだ難しいですが、それからすべてが自動化され、もっと楽しく思えます...
また、一部の開発者はQAを軽視しています。それでも、顧客よりもQAで欠陥を見つけたいと思います。...
私たちはここでテスターを愛していますが、私たちの多くはそれを手に入れる前の状態を覚えています。プロダクションに行った後にクライアントに問題を見つけさせるよりも、テスターに問題を見つけてもらうほうがましです。バグを作成したり、要件を誤って解釈したりしていない開発者は生きていません。
重要なのは、すべての専門家を礼儀正しく扱い、あなたがしていることをしているかどうかを尊重することです。自分の仕事が彼らの仕事よりも優れている、または重要であると考え始めると、あなたは失いました。
この質問に基づく： ソフトウェアテストの手法またはカテゴリ テスターとテスト全般に対する態度の調整が必要だと思います。
開発者として、私はテスターとの緊張を共有しました。
ある仕事では、テスターが「正しいこと」をテストすることはめったにありませんでした。製品のサーバーに新しい機能を実装すると、テスターはユーザーインターフェイスに関する大量のエラーを報告します。その製品では、ユーザーインターフェイスがコーディングされずに構成されたため、開発UIの問題の有無は、エンドユーザーが同様の問題のあるUIを使用するかどうかとまったく関係がありませんでした。テスターはこれを知っていましたが、外部の領域に関するバグを記録し続けました。
そうは言っても、優秀なテスターは金に見合うだけの価値があります-すぐにでもお粗末な開発者を優秀なテスターと交換します。優れたテスターは、高品質の製品を提供するパートナーです。
また、テスターを敵として扱っている開発者を知っています-テスターが障害を導入しているように。開発者にとって重要なのは、テスターが決してフォールトを導入しないことを認識することです-彼らはただそれを明らかにするだけです。
不快感は通常、コミュニケーションの悪さの結果であり、それは通常、プログラマーとテスターがコードの異なる観点を持っている結果です。プログラマーは、自分が取り組んでいる部分を詳しく知っていますが、システム全体にどのように適合するかを知らない場合があります（仕様で伝えられていること以外）。テスターは全体像を見ることができますが、コードの詳細を知りません。グループは、同じことに対して異なる用語と手順を使用する場合があります。
これにより、コンポーネントがアップストリームの障害に対応しているために、間違ったコンポーネントに対して欠陥が報告されたり、環境内で問題を再現できないために開発者が正当な欠陥を閉じたりする可能性があります（再現方法が本当に理解されていないため）問題を正しく）。これが頻繁に発生すると、グループ間の関係が緊張する可能性があります。
次に、11時間目に欠陥のバッチを取得する喜びがあります。締め切りが迫っており、直近のマネージャーからプレッシャーがかかってきています。そして、あなたが知っている問題について新たな欠陥を取得します。あなたはすでに修正しました、あなたが本当に行くのに時間がかかるする必要がありますする必要はありませんそれを証明するプロセスを通して。
QAチームを怒らせる本当に良い方法の1つは、優先度の高い欠陥のバックログが非常に大きいため、それらに到達することは決してないでしょう。」プログラムマネージャーのスプレッドシートで赤から緑に移動し、上級管理職からアタボーイを獲得し、QAチームが大量の偽の欠陥をファイリングするためのメトリックにヒットします。
悪いジュジュ。
これが本当なら、未熟さの兆候だと思います。冗談としてそれについて話すかもしれません。しかし、あなた（同じプロジェクトに取り組んでいる開発者とテスター）がチームのように感じない場合、結果は災害になります。
テストは、ソフトウェア開発ライフサイクルの非常に重要な部分です（アジャイルであろうとなかろうと）。そのため、テスターをバグに悩まされる人々として考えるのではなく、品質の高いソフトウェアの出荷を支援するチームメイトとして考えるべきです。