開発テストケース（ユニットおよび開発統合）をQA（テスト）チームと共有しますか？
テストチーム（一部の組織ではいわゆるQAチーム）は、開発チームが自分の（開発チームの）テストケースを共有する必要があると主張しています。彼らの主張は、開発テストケースがQAテストの開始点であるというものです。
開発チームのメンバーとして、私は要求を理解していません。私にとって、テスターは要件に基づいてソリューションをテストする必要があります。テストチームを詳細設計（低レベル設計）ドキュメントと共有する必要があるかどうかはわかりません。ただし、詳細設計は共有しています。
私はここでいくつかの投稿を読みました。QAチームは、より良いソリューションとスループットのためにテストケースを開発チームと共有する必要があると述べています。ただし、テストケースをQAテストチームと共有する開発チームはありません。
開発ユニットと統合テストケース、およびテスト結果を共有できれば、QAチームは非常に満足しているようです。
開発チームとQAチームが互いに話し合わない場合、一部のテストが不必要に2回行われ、一部のテストが忘れられるリスクがあります。最悪のシナリオの1つは、開発チームが数分または数時間で実行されるいくつかのNice自動統合テストを実装し、QA担当者が同じタスクを手動でテストし、そのタスクに数日または数週間を費やしている場合です。もう1つの悪いシナリオは、両方のグループが他のグループが特定のタイプのテストを担当していると考え、そのためこれらのテストが省略される場合です。
したがって、両方のグループがチームとして機能し、お互いに対してではないと仮定すると、どのグループによってどのテストが行われるかを互いに詳細に通知し、2つのグループにアクティビティを調整させることは理にかなっています。
テストチーム（一部の組織では、いわゆるQAチーム）は、開発チームが（開発チームの）テストケースを共有する必要があると主張しています。
確かに、QAは単体/統合テストでカバーされるものとカバーされないものについての一般的な理解を持っている必要があります。
彼らの主張は、DevテストケースがQAテストの開始点であるということです。
...彼らの推論に欠陥があるとしても。 QA担当者の第一のマントラは開発者を信用しないでくださいです。 「気にしないで！徹底的にチェックしました！」巨大な生産問題への第一歩です。
Doc Brownが言うように、自動化されたテストで十分にカバーされているものに大量のQA時間を費やすことは良くありません。しかし、自動テストで十分にカバーされているものにno時間を費やすのは無茶苦茶です。また、QAが実際にユニットテストを信頼すべきではない場合に、ユニットテストの詳細を文書化するのに長い時間を費やすことは無駄です（そのレベルの文書化により、開発者はユニットテストを少なくする/悪いものにすることになります）。
最新のソフトウェアアーキテクチャでは、テストはコードをテストするだけでなく、機能を文書化する方法でテストすることを目的としています。
コードが何をするかのこのドキュメント（仕様でを意図したものに加えて）は、QAの意図をよりよく理解するのに役立ちますコードの要件、および要件と一致するかどうか。これは、QA担当者がテストケースを作成するときにも役立つ情報であり、理論的にはすでにテストされているものを理解するのに役立ちます。テスト対象の領域には、追加のケースからメリットを得られるものと、テストがまったくないものとして公開されるものがあります。
この露出の実際の詳細は、組織の構成、特にテスターの技術的な深さ（ソースコードの読み取りなど）に大きく依存します。
多少逆らうために...私は開発者のテストを無視して自分の「独自の」テストを思いつくことがよくあります（私は大規模なQEチームのメンバーです）。開発者のテストを無視すると、問題/問題/機能を開発者の視点からのみ見るという考え方を回避できることがわかりました。
私のQEのモットーは次のとおりです。QEは、製品をテストすることによって付加価値である必要があります。 「単体テストのマージと実行」だけではQAが不十分です。
この質問に対する私の最初の反応は、「依存する」です。
それは、「開発チームのテストケース」の意味によって異なります。
単体テストしかない場合（white-box test）; QAチーム（統合およびシステムテスト）はテストケースを活用できませんでした。単体テストは、ユニットを検証するためだけにあり、要件を（ほとんど）満たしていないだけです。ホワイトボックステストは、統合テストやシステムテストの方法ではありません。
あなたが行動テストをしている場合; QAチームはこれらを使用して、いくつかの統合シナリオを導出できます。
- [〜＃〜] tdd [〜＃〜];を使用している場合定義によれば、テストは、アプリケーションの要件、アーキテクチャ、および設計の実行可能なドキュメントです。 QAチームは必ずこれらのテストケースを必要とします。
- gray-boxテストのような一部のテスト設計方法では、コンポーネントやサブシステム（統合テスト）などのテスト対象を分離または模擬できるように、詳細な設計情報が必要です。したがって、詳細設計をQAチームと共有することも必要です。
- システムテスト担当者は、詳細な設計に煩わされることはありません。ユーザーシナリオに重点を置いています。したがって、開発テスト（ホワイトボックス）はそれらの用途にはなりません。
あなたのケースに対する私の控えめな推奨は、開発チーム内のテスター（QA）と設計テスト（機能、統合、システム）を前もってまとめるようなアジャイルアプローチの評価です。
テストした内容をQAチームと共有してはならない理由はありませんが、アプリケーションを適切に検証するために重要だと思われるテストを複製する必要があります。
1）彼らはコード/アプリケーション/何でもテストする責任があります。必要に応じてテストを複製することにより、テストが適切に行われたことを確認します。
2）開発者は、コードの単体テストを担当します（ただし、一般に、一部の組織では、コードも開発者によるテストを開始しています）。これは別のアプローチであり、通常はメソッドの決定ポイントをカバーすることに重点を置いています。
3）あなたが言ったように、あなたが最初に考慮しなかったかもしれないケースを考えるのを助けるためにあなたのテストケースをあなたとテストチームが共有することは重要です。
4）要件に対してテストするのはテストチームの責任であると誰かが述べましたが、これは事実ですが、詳細な設計も非常に役立ちます。テストチームは、設計を行うことで、要件を確実にカバーするだけでなく、設計上の決定の一部を理解し、最終的にはより良いテストケースを作成するのに役立ちます。