多くの企業にテスト部門があることを知っていますが、いくつかの概念を明確にできないため、この質問をしています。
1、単体テストはテスト部門/サードパーティ企業によって行われることになっていますか？
私自身の感覚では、これは開発者自身が行うべきだと思います。しかし、次のようなことわざがあります。
あなたはそれを書いた方法であなたのコードをテストする傾向があります。したがって、単体テストを行う方がよいでしょう。そして、あなたはプロのテスターではないので、ユニットテストが最高であることを確認することはできません。
これが間違っている場合、プログラマーが自分で単体テストを行うべきだと言った公式なものはありますか？
2、単体テストにもかかわらず、テスト部門は他にどのようなテストを行いますか？
これは一種の簡単な質問です。ランダムテストやストレステストがあるかもしれませんが、テスト部門が通常行っていることのリストを誰かに教えてもらえますか？
開発者は自分の作業をテストする必要がありますが（すべての人がテストしますが、非効率的な「run-test-last-change-fix-run-again」メソッドを使用する人もいます）、自分の間違いを見つけようとする心理的な問題があります。
間違いを犯していることを知っていれば、おそらくそれを避けようとするでしょう。後から考えると、間違いを見つけるのは明らかで簡単なことがよくありますが、それが起こった場合、これは真実ではありません。したがって、これは、実際に最善を尽くしていたときに、あなたが愚かであると誰もが考える「敗者」の状況を生み出します。
すべての開発者には独自のエラーパターンがあります。つまり、誰もが同じ間違いを何度も繰り返します。さまざまな理由がありますが、ここで最も重要なのは、自分の欠陥を知らない、または認めたくないということです。
あなたが急いでいるとき、あなたは角を切り始めます。これは悪いことではありません、これは人間です。問題は、あなたの記憶があなたの仕事に必要なすべての詳細ですでにいっぱいになっているということです。今、あなたの記憶のパフォーマンスはストレスによって低下します。これは、あなたが気付かないうちに重要な詳細を見落とすことを意味します-あなたの脳はすでに限界で働いています。そして、あなたはそれらを見逃していることに気付かないでしょう。そして、あなたの記憶がパニックモードにあるのであなたが気づいたすべてのものを覚えているわけではありません->本当に重要な（生命を脅かすような）情報だけが処理されます。
自己監視は単に人間には効果がありません。常に外部コントローラーが必要です。そうしないと破損します。
したがって、他の誰かにあなたの仕事をテストさせることは理にかなっています：
彼らは同じパターン（クリックする場所、ボタンをクリックする順序、入力の速さなど）を使用せず、好みの方法の外にあるという理由だけで、自分では見つけられない単純なバグをすばやく発見します。コンピュータを使用することの。
彼らの仕事はあなたの人生を惨めにすることです（一言で言えば）。上司がお金の価値がある場合、開発者はできるだけ少ないバグをテストに移そうとし、テストは「それらを表示する」ためにできるだけ多くのバグを見つけようとする競争環境を作ります。他のチームです）。これは本当にうまく機能します（人間のグループは競争するのが大好きです）が、あなたは仕事での心理的な力に注意する必要があります。これが本当にうまく管理されていない場合、それは多くのストレス（->より多くのバグがすり抜ける）、燃え尽き症候群、そして相互の憎しみを生み出すでしょう。上司が人間の管理に優れていない場合、これは裏目に出ます。
彼らは異なる仮定を持っています。彼らはコードを書かなかったので、それがどのように機能するのか見当がつかない。彼らはあなたの仕事を顧客のように見て、開発者が決して気にしないことを見るでしょう（「醜いように見える」、「十分に反応しない」）。彼らは製品を販売しやすくする問題を見つけることができます。開発者は通常、「十分に機能する」ことにのみ焦点を当てています（=正しいボタンを正しい順序でクリックしてもクラッシュしません）。
今あなたの質問：
単体テストは、テスト部門/サードパーティ企業によって行われることになっていますか？
いいえ。単体テストは、コードで実行できる最小のテストですが、それでもある程度の意味があります。テスト部門はそれらを実行してはいけません。それは自動化されたCIサーバーの仕事です。それは、コンピューターに適した愚かで退屈で反復的な作業です。
しかし、テスト部門に新しい単体テストを定義させることは理にかなっています。または、テストからのエラーレポートを新しい単体テストに変換する必要があります。
単体テストにもかかわらず、テスト部門は他にどのようなテストを行いますか？
いくつかの例：
プログラマーは自分でかなりのテストを行うべきだったと思いますが、そのほとんどは機能テストに帰着します。期待どおりに動作しますか？
テスト/QAの人々は、テストのより深い仕事をする傾向があります。セキュリティのバックグラウンドから来て、彼らはすべての入力が検証されていることを確認し、たとえばSQLインジェクションやCSSに対して脆弱なものはありません。また、さまざまなチームが完成品のさまざまな部分を構築する大規模なプロジェクトでは、テスト部門が完成品をテストして、負荷テスト、インストールテスト、さまざまなシナリオでのテスト、さまざまなOSなどの統合中にバグが発生しないことを確認します。テスト部門他のチームがそれが修正する価値のあるバグであるかどうかを判断し、それが既知の問題であるか設計によるものであることをクライアントベースに知らせることができるように、あらゆる状況で何が起こるかを知る必要があります。
ビデオゲームを少し見てみましょう。ビデオゲームでは、通常、設計された環境全体を移動するスプライトがあります。テスターは、スプライトが壁にぶつかったときに停止することを確認し、可能なすべての壁でスプライトをテストして、クリッピングの問題がないことを確認します。開発者は通常、エンジンをプログラムしてマップとインタラクションを作成しますが、報告されない限り、個々のクリッピングの問題を見つけることには関心がありません。
単体テストは、コードの記述を担当する開発者によって記述されます。それらは基本的にコーダーが使用するためのものです。私はそれらを使用して、QAに配信するコードに、テストを停止する（また、見栄えを悪くする）NPEなどの内部エラーがないことを確認します。プロジェクトには、協調して動作する必要のあるさまざまなコンポーネントが含まれます。単体テストでは、個々のコンポーネントが期待どおりに機能し、それらの相互作用がすべて期待どおりに機能することを確認できます。
他のグループによるテストは、製品の動作のさまざまな側面を調べることに焦点を当てています。
機能テストは、ビジネス要件が満たされていることを確認します
システム統合テストは、プログラムが実稼働環境と同様のコンテキストで動作することを確認します
負荷テストでは、多くの作業が行われたときにプログラムが期待どおりに動作することを確認します
ユーザーエクスペリエンステストでは、通常のユーザーがUIをナビゲートできることを確認します。
ペアプログラマーがテストとコードの記述を交互に行うピンポンTDDの概念があるため、2人目の視点から利益を得ることができます。これはおそらく、テストとコードレビューの即時取得の両方に最適な方法ですが、2人の従業員が単一のタスクに取り組んでいると考えると、経営陣を驚かせます。そのため、この機会は非常にまれです。それがなくても、テストでコードを壊そうとすることはプログラマーの利益になります。後で誰かにやらせるよりも、書いているときにコードを壊したいです。