プログラマーは、テストを設計する際にテスターをどれだけ助けるべきですか？
私は彼らがまったく助けになるとは思わない。私の心配は、彼らがテスターが彼ら自身のコードのためのテストを設計するのを助けるならば、彼らが彼らの自身の偏見とそのコードに関する盲点でテスターに「感染」するだろうということです。
テスターがテストを作成するために必要な情報を提供するには、要件が十分でなければならないと感じています。プログラマーが気になる実装の一部がある場合、ユニットテストを実装してその部分をテストするか、独自の非公式のシステムテストを実行してその部分をテストすることは彼らの義務だと思います。
しかし、私が知っている誰もがこれに同意しているわけではありません（そして、ある程度彼らのポイントを理解しています）。他の人はこれについてどう思いますか？これはどこでも文献で議論されていますか？
回答:
同意する。プログラマーは、テスターが機能仕様を理解し、研究のためのリソースを見つけるのを助けることができますが、テストへのアプローチ方法についての独自のアイデアでテスターの心を汚さないでください。
QAの領域では、開発者とテスターが平和的に共存する余地があると思います。:)
より具体的には、開発者は第1レベルのテスト（単体テストと基本的な統合テスト）を担当し、ほとんどの場合、テスターに引き渡す前に自分のものが機能することを確認する必要があると思います。
実装の詳細に完全に依存しない要件に基づいて受け入れテストを作成するのはテスター次第です（これは通常「ブラックボックステスト」と呼ばれます）。テスターと開発者が要件を理解する方法に矛盾がある場合は、プロジェクトマネージャー（存在する場合）または機能の設計段階で全員が同じページにいることを確認することで対処する必要がある問題です。
テストと開発の両方が共同作業であると思うので、もちろん（IMO）、開発者はテストのアイデアをテスターに提供すべきです。私はそれが彼らに感染したり、テスターを汚染したりするとは思いません。もちろん、テスターは他の多くのテスト手法でこれらのテストを強化する必要があります。
また、開発者を支援するテスターの大ファンです-私はキャリアの中で何度も設計アイデアを開発者とブレインストーミングし、それらを組み合わせてバグを修正しました（そして、バグと修正案を指摘しました）。開発者をテスターの集団で汚染したことがあります。
共同作業とは思えない場合は、開発者がテストするために「壁を越えて」コードを投げるだけで済み、品質が低下することになります。それが私の世界の真実ですが、（もちろん）ymmvです。
私の見方では、コードをテストするのはQAの仕事ではありません。テスターの仕事は、私のコードがそのタスクのすべての要件を満たしていることを確認することです。
QAに何かを渡すとき、コードの詳細ではなく、私が行っていたタスクを知っていることを確認します。「骨頭」のバグがあるQAには何も渡しません。それは私の時間、彼らの時間を無駄にします...そして、ほとんど全員の時間を無駄にします。
私の最後の仕事では、最初からQAを担当していました。それは、要件収集セッション、プロジェクト会議、設計会議にもありました。彼らは聞いて質問し、開発者がコードを書いている間にテスト計画を書いていました。それはうまく機能し、おそらくすり抜けたはずの多くの問題を見つけました。
ここであなたはかなり間違っていると思います。私はテスターであり、開発者であり、開発者がハイリスクまたは脆弱だと考えている領域に関するガイダンスからテスターとして大きな恩恵を受けています。開発者として、私はテスターに、私が詳しく調査していない問題を見つけてほしい。
あなたのコードが生の下水でなければ、「汚染」はありませんでした。それはまったく別の理由によるものです。
要件は、ビジネスアナリストが把握できたものだけを詳しく説明するため、QA専門家が関心を寄せる技術的な問題を伝えるという恐ろしい仕事をします。優れた開発者は、コードが「ハッピーパス」を中心に最適化されていることを認識し、何が考慮されずに残っているかを知りたいと思うでしょう。少なくとも、何が間違っているのか、QAにどのような分野を調査してもらいたいのかについての直感があります。また、設計に基づいて特定の機能に関するリスクの全体像を把握しています。
開発チームからのガイダンスがないテスターとして、私は時々、良いバグレポートを生成する間違ったアプローチを取りましたが、高リスクのコードパスと大きな問題を完全には行使しませんでした。顧客に出荷された開発チームと。
テスターは、開発者が重要だと言っていることだけをテストすることに制限すべきではありませんが、開発者がコードについて懸念していることを学ぶことによって、彼らは損害を受けません。実装の知識に基づいてアプローチを微調整できる場合があります。テスターが特に近視眼的である場合にのみ、リスクが最終的な言葉であるかどうかについて開発者の意見を考慮します。開発者が低リスクと判断したものを完全にシャットダウンするわけではありませんが、顧客への影響が大きくなる可能性のあるものにより多くの労力を注ぎます。
QAチームは、システムの要件収集者または開発者よりも大きな組み合わせのテストスコープを持つ領域を見つける可能性がありますが、設計の認識から恩恵を受けるより微妙な脆弱性を持つシステムのコンポーネントを認識しない場合がありますまたはシステムの実装。
私の経験では、QAと開発のコラボレーションにより、より高品質の製品が生み出されます。ブラックボックスハンドオフのみを行うことはお勧めしません。
テスターとして、私はプログラマーにテストケースを提案すること（それが私がそれらのテストケースだけに固執することを意味するわけではありませんが）や実装の詳細を記述することには全く異議はありません。誰かに「このビットは危険かもしれないと思うので、このビットをかなり徹底的にテストしたら本当に欲しい」と言ってくれると本当に役立つことがあります。実装の詳細のいくつかを知ることは、長年の経験を応用して、失敗する可能性が最も高いと思われるテストを選択するのに役立ちます。簡単に言及するだけで、いくつかのテストが突然優先リストを拡大することを意味する場合があります。
それは私を汚しますか？私はテスターの純粋さを保つためにプログラマーが熱心に努力しているという考えにちょっとくすぐられていますが、実際には-いいえ、これは神話です。通常、より多くの情報が私にとってより多くの質問を引き起こします。私はそれが考え方だと思います-私は無知だからバグを見つけません。私がテストしたすべてのシステムで、私はより多くの問題を見つけ、より多くの「興味深い」ものを見つけるほど、それを深く理解するようになりました。
私はQAを行っています。ほとんどのドメインとは異なり、コードの使用方法を知ることは、プログラミング言語を学ぶことよりもはるかに困難です。そのため、方法がわからないため、開発者が新しいwhizzbang機能のテストケースを提供してくれることを期待しています。いずれにせよ、QAの問題は、新機能の元のテストよりも、リグレッションや壊れたものをキャッチすることの方が重要です。いずれにせよ、結果が複雑な計算である場合、何が正しい答えで何が間違った答えであるか、または異常終了が良いか悪いかを知ることは困難です。
いずれにせよ、開発者は、正直なところ、おそらく自分の赤ちゃんの脆弱性を知っています。彼はおそらく、どのパラメーター値で、異なるアルゴリズムを選択する必要があるか、またはテーブル検索などでドメインを選択する必要があることを知っています。彼が厳密なテストについて誠実であれば、多くのコードをカバーする妥当なサイズのテストスイートを生成できるはずです。