単体テストは開発ですか、それともテストですか？

ユニットテストと統合テストの役割について、テストマネージャーと話し合いました。彼女は、開発者にユニットと統合のテスト内容とその方法を報告するように要求しました。私の考えでは、単体テストと統合テストはテストプロセスではなく開発プロセスの一部です。セマンティクスを超えて、ユニットテストと統合テストをテストレポートに含めるべきではなく、システムテスターがそれらについて心配するべきではないということです。私の推論は2つのことに基づいています。

1. ユニットおよび統合テストは、常にインターフェイスと契約に対して計画および実行されます。正式な契約を使用するかどうかに関係なく、メソッドが何をすべきか、つまり契約をテストします。

   統合テストでは、2つの異なるモジュール間のインターフェイスをテストします。インターフェイスとコントラクトは、テストに合格するタイミングを決定します。ただし、システム全体の限られた部分を常にテストします。一方、システムのテストは、システムの仕様に照らして計画および実行されます。仕様は、テストに合格するタイミングを決定します。

2. ユニットテストと統合テストの幅と深さを（システム）テスターに​​伝えることには価値がありません。特定のビジネスレイヤークラスで実行される単体テストの種類を一覧表示するレポートを作成するとします。彼/彼女はそれから何を奪うことになっていますか？

   それからテストすべきものとすべきでないものを判断することは、すべての単体テストと統合テストに合格してもシステムがまだ仕様どおりに機能しない可能性があるため、誤った結論です。

これは役に立たないアカデミックな議論のように思えるかもしれませんが、私と同じように厳密に正式な環境で作業している場合、私たちが物事をどのように行うかを決定する上で実際に重要です。とにかく、私は完全に間違っていますか？

自動テストの作成は開発者の仕事です。テストはコードベースの一部であり、そのように扱われるべきです-それらは、プロジェクトの他の部分と同じコードレビュー、コーディング標準、ソース管理規律などに従う必要があります。

上記のテストの実行は、次の2つの理由で実行されます。1つ目は、開発者をガイドするツールとして。テストを実行して、作成したコードが想定どおりに動作することを確認し、追加のドキュメントとして使用し、変更によって既存の機能が損なわれないことを確認します。実際のTDDを行う場合、テストは技術仕様の信頼できるソースでもあります。テストを使用する2番目の理由は、QAおよび展開中です。すべての自動テストを実行することは、すべてのテストの最初のステップの1つでなければなりません。自動テストの実行は安価であり（実質的に人手は不要です）、自動テストが失敗した場合に手動テストを行うことはあまり意味がありません。

つまり、責任は次のようになります。

• 開発者は自動テストを作成します
• 開発者は、開発ワークフローの一部として、必要に応じて個別の自動テストを実行します
• QAはすべての自動テストをテストの最初の段階の1つとして実行します

ビルドサーバーがある場合、QAのタスク（自動化されたテストに関する）は、「ビルドサーバーのレポートを開き、すべてがグリーンであることを確認する」ということになります。

あなたにとって最も重要なのは、なぜ彼女がその報告書を必要とするのかを明確にすることだと思います。

さまざまな説明があり（いくつかの回答で示唆されています）、非常に異なる戦略が必要です。

• 彼女が合理的な人物であり、単にテストチームの作業に役立つ情報を取得したい場合は、共通の理解を得て、両方に適した何らかの解決策を考え出すことが理にかなっています。彼女と単体テストの性質、および単体テストと機能テスト、システムテスト、受け入れテストの根本的な違いについて話し合うことができます。うまくいけば、これらが非常に異なるレベルで機能し、どちらも他方を置き換えることができないことを彼女に理解してもらうことができます。
• 彼女がコントロールマニアまたは官僚であり、そのためだけにレポートを要求している場合、最小限の労力で気まぐれを満たすために何かを生成できます（@Docが提案したもの:-)。
• 彼女がパワーゲームに夢中なら、開発者からの報告を要求する権利があるかどうか疑問に思うかもしれません。私の経験では、開発者は通常、QA部門に報告することは想定されていません。

QAと開発の役割、および相互作用は、組織によって大きく異なる可能性があると思います。しかし一般的に、私のチームでは、QAチームがないようなふりをするようにメンバーに参加するように指示します。つまり、メンバーが本番環境にプッシュする変更に責任があるという意味です。順番に、QAチームは開発者のテストについてあまり想定しておらず、機能全体としてシステムをかなりの量テストしています。

このため、QAチームは、テストを開始する前に単体テストの有無をあまり気にしません。

QAチームにとって、ユニットテストが何をカバーし、何をカバーしていないのかを高レベルで理解することは有益だと思います。したがって、あなたの同僚は、面倒な詳細とは対照的に、高レベルの要約を求めているのかもしれません。

彼女は、開発者がユニットと統合のテスト内容とその方法を報告することを主張しました。

彼女は本当に、この種のテストが実際に「開発」の領域にあるのか、それともあなたのコードが単体テストでどれだけうまくカバーされているのかを理解しようとしているのでしょうか？あなたが与えた情報を見るだけで、彼女はコードのどの部分がカバーされ、どこでチームの努力を集中すべきかを知りたいだけのようです。

私は、開発の役割に移る前に、学校を出てすぐにテストチームで働いていましたが、これが彼女と彼女のチームにとってどのように価値があるかがわかります。

私はそれがあまり重要だとは思わない。

それらをQA / Testingに提供せず、適切なテストを行わず、本番で失敗した場合、指定どおりに動作することを確認せずにQAを本番に移行させるのは彼らのせいです。

それらをQA / Testingに提供し、それらが適切なテストを行わない場合...あなたがそれらを提供しなかったかのように同じ結果になります。

ただし、それらを提供すると、仕様と比較したり、バグを見つけたためにどのテストに欠陥があるか、または変更する必要があるかを提案できます。

本当に、私はそれらを提供することであまりマイナス面を見ません。仕様に照らして検証するために、まだQA /テスト中です。彼らが怠zyな方法を取り、すべてが合格したためにテストが十分であると頼るだけであれば、彼らの仕事で失敗したのは彼らです。彼らがまだ仕様を持っている限り、ユニット/統合テストの結果はただの綿毛であり、あなたを何らかの方法で傷つけることはできません。これが、開発者とQAがいる理由です。アプリが指定どおりに実行する複数のチェック。

開発者がミスを犯し、QAがミスを犯します。理想的には、同じアイテムで両方ともミスを犯さないことが理想的です。

単体テストは、テストがコードの断片がそれ自体でどのように機能するかを理解するのに役立つ可能性があるという開発者の責任です。ユニットテストを定期的に変更するとオーバーヘッドが発生する可能性がありますが、一部のドキュメントはこれをドキュメントの形式と見なして価値がある場合があります。

テストを渡す際のもう1つの価値は、これにより、基本的な機能を確保するという点で冗長なテストが2倍になることを回避できることです。

エンドユーザーはシステムがどのように機能するかを独自に理解している可能性があるため、これとは別のユーザー受け入れテストもあります。

製品の品質を保証するための方法論が定義されている場合（SOX準拠であるか、CMMIレベルを改善しようとしている場合はおそらくそうです）、製品はプロセスを示すために監査に立ち向かうことができなければなりません追跡された。

多くの場合、定義されたプロセスには単体テストが含まれます（これは良いことです）。残念ながら、これはまた、ユニットテストを文書化し、それらが実行されたことを証明して監査に立ち向かう必要があることを意味します。そのため、ユニットテストについてレポートする方法が必要です。

Sonarのようなツールを参考にしてください。コードカバレッジのレベルと単体テストの実行結果を報告します。

これは本当に企業に依存しますが、従来のアプローチでシステムテスターとして、またCDモデルのアジャイルチームでテスターとして働いた経験から、ユニットと統合のテストが何であるかを知ることは非常に役立ちます。

品質はチームの責任です-開発者、テスター、製品管理の両方が、それを保証する最良の方法です。

そのため、テストマネージャーは単体テストおよび統合テストの結果を知りたいと考えており、開発者にとってもう少し余分な作業が必要ですが、プロジェクト全体の作業を節約できます。テストマネージャーに情報を提供することで、テストチームの努力を重要かつ重要なことに集中できます。前述のように、コードの領域が単体テストされていない場合、チームは、重度のテストが行​​われている領域と比較して努力を集中できます。あなたは全員、時間通りにリリースされる高品質のソフトウェアという同じ究極の目標に向かって取り組んでいます。

この種の物を提供することは有益だと思います。単体テストの対象範囲は、開発とテストで把握されている必要があります。

明らかに、ビジネスに不可欠なものを何であれテストする必要があります。単体テストのカバレッジが優れているかどうかに関係なく、よく使用される機能を厳しくテストする必要があります。他の場所が単体テストでカバーされていることを彼らに知らせることは害になりません。コードは、この1つの小さなコントロールのエッジケースを既にチェックしていますか？この種のものは、ビジネスのあらゆる側面で知るのに役立ちます。

「Googleがソフトウェアをテストする方法」で説明されているアプローチに言及する価値はあります。テストと品質管理は全員の責任であり、基準は厳格です。

本物の伝統的な「テスト」部門と呼ばれるものの役割は、実際には開発者の生産性です。すなわち、組織が経済的に必要な厳密さのレベルに到達できるようにする自動化。