回答:
Googleが使用する手法の一部を以下に示します。
バグを捕らえる上で効果の降順であると思われるものでこれらをランク付けしました。
大企業には通常、Q / A部門全体があり、コードをテストし、コードが想定どおりに機能することを確認する責任があります。それは通常あなたが説明したように-多くのマシンをテストする多くの人々です。テストは自動化されることもあれば、自動化されないこともあります。品質保証-ウィキペディアをご覧ください
多くの場合、開発者自身が開発プロセス中にバグを見つけます。また、多くの場合、顧客はバグを最初に発見します。
私が現在働いているような中小企業は、アジャイルテストの実践を使用しています
規模ではなく、会社の成熟度についてです :)貧弱な開発慣行を持つ大企業と、最先端にある小企業があります。
一般的に、成熟した開発チームは、次の1の活動に従事します。システムへの新しいバグの導入を最小限に抑え、2。既存のシステムのバグを見つけます。
ユニットテスト：これらは、メソッドが言うとおりに機能することを確認するための個々のメソッドの「ミニドライバー」です。これらは常に自動化されたテストです。
統合テスト：これらのテストは、システム内でより大きな機能ユニットが機能することを確認することを目的としています。これには、データベース統合またはサードパーティライブラリとの統合のテストが含まれる場合があります。これらも自動テストです。
受け入れテスト：受け入れテストは、ユーザーの要件をテストするために書かれています。これらは通常、「ハッピーパス」をテストするだけです。私のチームでは、これらのテストは、使用するように設計された機能をユーザーが使用しても問題がないことを示すように設計されています。手動でも自動でもかまいません。
機能テスト：これらのテストは受け入れテストに似ていますが、「不幸な道」もテストします。これらのテストは、それほど明白ではないシナリオをテストすることを意味します。手動でも自動でもかまいません。
回帰テスト：この用語を使用して、システムが顧客にリリースされる前にシステムの「完全なテスト」を行います。手動または自動。
ゴリラのテスト：（手動のみ）。これは、非常に賢い人間が意図的にアプリケーションを壊そうとするときの一種のテストです。
パフォーマンステストは、パフォーマンスが許容範囲内であり、時間の経過とともに低下しないことを確認することを目的としています。通常は自動化されています。
安定性テスト：これらのテストは、システムが長期にわたって安定したままであることを確認するように設計されています。自動化。
継続的インテグレーション：これは、コードを自動的にチェックアウトしてコンパイルし、自動テストを実行するシステムです。開発者がコードをコミットするたびに、より高速なテスト（ユニット、統合）が実行されます。他の一部は、夜間（受け入れ、機能）または毎週（パフォーマンス、安定性）実行します。
コードカバレッジレポート：テストされたコードの量を示します。テストカバレッジのないコードは、破損する可能性が高くなります。
コードを分析するさまざまなツール：これらは通常、潜在的なバグが発生しにくくするためにコードをリファクタリングする必要がある場所を示します。
ペアプログラミング：機能を提供するために協力する2人の開発者。「凝集ペアは、その部分の合計よりも優れています。」
最も重要なのは、自動化と継続的な統合です。
それは会社と開発する製品に依存します。
まず、多くの企業は、コードレビューや必須のリンティング（自動化されたバグ検出ツール）などのコーディングプラクティスを実施して、リポジトリに入力されるエラーの量を減らします。多くの企業もユニットテストを採用しています。これは私が働いている場合です（Google）。コードがチェックインされると、すべてに対してテストが実行され、新しいエラーが発生しないことが確認されます。
第二に、多くの企業には、行動の検証を担当するQA部門があります。これは特に金融業界でよく見られます（ミスが高額で検証ルールが複雑な場合）が、リコールが高額なユーザーに製品を販売する企業（Intel、Microsoftなど）にも存在します。
第三に、可能な場合はいつでも企業がドッグフーディングを行い（自分のユーザーに社内で製品を使用させる）、限定ベータ版をリリースします。この段階で多くのエラーが検出されます。たとえば、Microsoftで働く人々は、外部にあるものよりも新しいバージョンのOfficeとWindowsおよびDevStudioを使用します。その後、限られたユーザーグループまたは契約企業がそれをサンプリングします。同様に、Googleでは、リリース前にGMailとドキュメントの内部バージョンを使用しています。ゲーム会社は、製品やサーバーの負荷などをテストするためにオープンベータを組織しています。
もちろん、答えは「それは垂れ下がっています」ですが、私はこれまでで最大のプロジェクトからサンプルを提供します。
基本セットアップ：BizTalkで大量のデータを処理するためのバックエンドソフトウェア。
最初の防衛線はユニットテストです。私たちの場合、これらはソース管理にチェックインされたすべてに対して毎日実行され、通常、それらのいくつかはチェックイン前に開発者によって手動で実行されました。単体テストは主に開発者によって作成されましたが、テスターによる追加のテストで修正されることもありました。
次のステップは、毎週のVirtual PCビルドで、テスターは各コンポーネントの仕様ドキュメントに基づいて、データフローに対して一連の主に自動化されたエンドツーエンドのテストを実行しました。
その後、同じVirtual PCに本物に非常に近いビジネスデータが追加され、特定のユースケースで再度テストされました。
次に、Virtual PCを他の部門の他のシステムコンポーネント（ほとんどが仮想）と組み合わせて、データフローの最後までデータを入力するユーザーからのエンドツーエンドテストに基づいた統合テストサイクルを実施しました。
別のトラックでは、システムプロバイダーによってインストールパケットがテストされ、本番環境に正しくインストールされたかどうか、または何かが失敗した場合にロールバックできるかどうかが確認されました。
実稼働環境にインストールした後、全体の安定性をテストするために負荷テストとストレステストを実行しました（10個のBizTalkサーバー、8個のSQL Server、およびXMLアクセラレータなどのその他の特殊なハードウェアで実行する場合は、軽視しないでください）そして専用のアーカイブ-もちろんすべてがクラスター化されています）。
すべてのテストに満足したら、コードを実稼働しました。コードのバグを修正するのに非常に大きな遅延が発生し（テストサイクル全体で4〜6週間など）、これらのテストをすべて実行するのは高価ですが、全体的な安定性はかなり良好でした。実際、私が今まで見た中で最高です。繰り返しますが、毎日数百万ドルの価値があるシステムでは、それは非常に重要です。要件は異なる場合がありますが、それが私たちのやり方であり、機能しました。
元の質問は、提供された非常に詳細な回答のほとんどよりも概念的に一般的なようです。
より高いレベルから見てみましょう（あまり詳細ではありません）。ソフトウェアは、誰か（個人、会社、その他）の特定のニーズに対応するために開発されています。
これらのニーズは、ソースコードに実装される（建設段階で）個々のストーリー/要件にマッピングする必要があります。
ストーリー/要件を明確に定義することは、品質保証（QA）チーム（実際のソフトウェアテスター）が最終コードを検証し、実行されたときにそれらのストーリーと要件の要求に対応するために不可欠です。そのため、QAチームはその検証を行うための「テストケース」を作成します。
QAチームにリリースされたコードはテストされ、バグが特定されます。さまざまな種類と重大度のバグ。これらのバグは追跡され、開発者はそれらを割り当てて、最終的に修正を行います。
現在、仮想マシンを使用すると、1人のテスターが同じ実際のハードウェアで異なる環境を実行できます。ただし、QAフェーズ専用のコンピューターが必要になる場合があります。
全体的なプロセスを（おおよそ）理解するのに役立つことを願っています。
まあ、私は皮肉を言うのは嫌いですが、特定の「デバイス」オペレーティングシステムでの未解決のバグの数により、会社が大きく豊かになればなるほど、より多くのバグを作成してエンドユーザーに配信できるようになります。ソフトウェアが動作し、かっこよく見えるなら、とにかくそれをリリースするだけです。マネージャーが準備ができていると思うなら、準備ができています。そのとき、本当に厄介なバグが木工品から出てきて、エンドユーザーはモルモットになります。10年ほど後、ほとんどのバグが解決され（そしていくつかは適切な対策のために追加され）、会社は次の大きなアイデアに移行する準備が整います。