開発テストケース（ユニットおよび開発統合）をQA（テスト）チームと共有しますか？

テストチーム（一部の組織では、いわゆるQAチーム）は、開発チームが（開発チームの）テストケースを彼らと共有する必要があると主張しています。彼らの主張は、開発テストケースがQAテストの出発点であるということです。

開発チームのメンバーとして、私は要求を理解していません。私自身、テスターは要件に基づいてソリューションをテストする必要があります。テストチームを詳細設計（低レベル設計）ドキュメントと共有する必要があるかどうかはわかりません。ただし、詳細設計は共有しています。

私はここでいくつかの投稿を読みました。QAチームは、より良いソリューションとスループットのために、テストケースを開発チームと共有する必要があると述べています。しかし、テストケースをQAテストチームと共有する開発チームはありません。

開発ユニットと統合テストケース、およびテスト結果を共有できれば、QAチームは非常に満足しているようです。

開発チームとQAチームが互いに話し合わない場合、一部のテストが不必要に2回行われ、一部のテストが忘れられるリスクがあります。最悪のシナリオの1つは、開発チームが数分または数時間で実行されるいくつかの優れた自動統合テストを実装し、QA担当者が同じタスクを数日または数週間かけて手動でテストする場合です。もう1つの悪いシナリオは、両方のグループが他のグループが特定の種類のテストを担当していると考えているため、それらのテストが省略されている場合です。

したがって、両方のグループがチームとして機能し、お互いに対してではないと仮定すると、どのグループによってどのテストが行​​われるかを詳細にお互いに通知し、2つのグループにアクティビティを調整させることが理にかなっています。

テストチーム（一部の組織では、いわゆるQAチーム）は、開発チームが（開発チームの）テストケースを彼らと共有する必要があると主張しています。

確かに、QAは、単体/統合テストでカバーされるものとカバーされないものについての一般的な理解を持つ必要があります。

彼らの主張はDevテストケースであり、QAテストの出発点です。

...彼らの推論に欠陥があるとしても。QA担当者の第一の信条は、開発者を信頼しないことです。「気にしないで！しっかりチェックしました！」巨大な生産問題への第一歩です。

Doc Brownが言うように、自動化されたテストで十分にカバーされているものに大量のQA時間を費やすことは良くありません。しかし、自動化されたテストで十分にカバーされているものに時間を費やさないのは無茶苦茶です。また、QAが実際にユニットテストを信頼すべきではない場合に、ユニットテストの詳細を文書化するのに長い時間を費やすことは無駄です（そのレベルの文書化により、開発者はユニットテストを少なくする/悪いものにします）。

最新のソフトウェアアーキテクチャでは、テストはコードをテストするだけでなく、機能を文書化する方法でテストすることを目的としています。

（仕様で意図されていることに加えて）コードの機能に関するこのドキュメントは、QAがコードの目的を理解し、要件に一致するかどうかを理解するのに役立ちます。これは、QA担当者がテストケースを作成するときにも役立つ情報であり、理論的にはすでにテストされているものを理解するのに役立ちます。テスト対象の領域には、追加のケースから利益を得られるものと、テストがまったくないものとして公開されるものがあります。

この露出の実際の詳細は、組織の構成、特にテスターの技術的な深さ（ソースコードの読み取りなど）に大きく依存します。

多少逆らうために...私は開発者テストを無視して自分の「独自の」テストを思いつくことがよくあります（私は大規模なQEチームのメンバーです）。開発者のテストを無視すると、問題/問題/機能を開発者の視点からのみ見るという考え方を回避できることがわかりました。

私のQEのモットーは次のとおりです。QEは、製品をテストすることによって付加価値を提供する必要があります。「単体テストのマージと実行」だけでは不十分なQAです。

この質問に対する私の最初の反応は、「依存する」です。

それは、「開発チームのテストケース」の意味によって異なります。

• 単体テスト（ホワイトボックステスト）しかない場合 QAチーム（統合およびシステムテスト）は、テストケースを活用できませんでした。単体テストは、ユニットを検証するためだけにあり、（ほとんど）要件を満たしていません。ホワイトボックステストは、統合テストやシステムテストの方法ではありません。

• あなたが行動テストをしている場合; QAチームはこれらを使用して、いくつかの統合シナリオを導出できます。

• TDDを使用している場合; 定義によれば、テストは、アプリケーションの要件、アーキテクチャ、および設計の実行可能なドキュメントです。QAチームは必ずこれらのテストケースを必要とします。
• グレーボックステストなどの一部のテスト設計方法では、コンポーネントやサブシステム（統合テスト）などのテスト対象を分離または模擬できるように、詳細な設計情報が必要です。したがって、詳細設計をQAチームと共有することも必要です。
• システムテスト担当者は、詳細な設計に煩わされることはありません。ユーザーシナリオに重点を置いています。したがって、開発テスト（ホワイトボックス）はそれらの用途にはなりません。

あなたのケースに対する私の控えめな推奨は、開発チーム内のテスター（QA）と設計テスト（機能、統合、システム）を前もってまとめるようなアジャイルアプローチの評価です。

テストした内容をQAチームと共有してはならない理由はありませんが、アプリケーションを適切に検証するために重要だと思われるテストを複製する必要があります。

1）彼らはコード/アプリケーション/何でもテストする責任があります。必要に応じてテストを複製することで、テストが適切に行われたことを確認します。

2）開発者は、コードの単体テストを担当します（ただし、一般に、一部の組織は開発者のコ​​ードもテストし始めています）。これは別のアプローチであり、通常はメソッドの決定ポイントをカバーすることに重点を置いています。

3）あなたが述べたように、最初に検討しなかった可能性のあるケースについて考えるのを助けるために、テストチームがテストケースをあなたと共有することが重要です。

4）要件に対してテストするのはテストチームの責任であると誰かが述べましたが、これは事実ですが、詳細な設計も非常に役立ちます。テストチームは、設計を行うことで、要件を確実にカバーするだけでなく、設計上の決定の一部を理解し、最終的にはより良いテストケースを作成するのに役立ちます。