個別のQAチームは、開発ライフサイクルで冗長ですか？
バックグラウンド：
開発者は、QA技術者と比較して、エンタープライズソフトウェアの開発/拡張後のダークコーナーを理解/理解するのに最適な人物です。
開発者は、このような暗いコーナーから発生する可能性のある生産上の問題の深さ/幅を評価できます。
品質上の理由から（のみ）、コスト削減ではなく、私の新しい雇用主は個別のQAチームを維持せず、テストケースを記述/追加/自動化/検証する責任を開発者（より優れた所有者）に移します。したがって、すべての新しいテストケースは、プロセスの一部として、既存のテストスイートに追加されます。
私の雇用主は、カスタマイズされたLinuxベースのOS on switchを使用してネットワークスイッチを製造しています。
私の職場では、回帰テストで従う最初のルールは回帰テストを避けるです。すべてのリリースのすべての機能、すべてのプラットフォームで作成された新しいテストケースをテストすることで、回帰テストを回避します。テストが失敗した場合、ログを既知の失敗のデータベースと照合し、いくつかのフィンガープリントを指摘します。
質問：
1）別のQAチームがソフトウェア開発ライフサイクルに何らかの価値を追加しますか？
2）倫理的なハッキングスキルを持つQAチームが結成された場合、高品質の製品を提供する価値はありますか？ネットワーク上で実行されるソフトウェア製品の場合
それは、開発およびテストされているシステムに依存すると言えます。
開発者はコードを最もよく理解しているかもしれませんが、それは、コードが使用されるすべてのビジネスケースを完全に理解していることを意味しません。
たとえば、保険ブローカーがポリシーと請求を管理および処理するために使用するWebアプリケーションについて考えてみます。多くの多くのルールとそのようなシステムに入るビジネスケースがあります。 1人の開発者がその詳細allを深く理解できる可能性はほとんどありません。一体、ほとんどのビジネスユーザーはおそらくシステム全体を知りません（ただし、開発者よりも多くのビジネスレベルの理解があります）。
この場合、別のQAチームがアプリケーション内のビジネスフローに関する特別なトレーニングを受けます。たぶん、彼らは開発者ではないかもしれません。彼らは、豊富な経験からQAに移行したビジネスアナリストかもしれません。あるいは、システムのコードに関連しない側面にもっと関心を持つ開発者かもしれません。彼らはすべての技術的な詳細を理解するわけではなく、理解する必要もありません。彼らはおそらく開発者が知っていること、あるいは知る必要さえあるビジネスケースを実行します。開発者テスト（通常、開発者が自分のワークステーションでローカルに行い、コードが基本レベル以上で機能することを確認する）とQAテスト（QAチームが実行して、より多くのビジネスケースセットが満たされることを確認する）は、さまざまな種類のテストと期待。
これはどのような価値をもたらしますか？システム全体を非常によく理解している経験豊富なQAテスターを経験しました。開発者による変更に基づいて、システムをテストしてすべてのパーツが適切にカバーされていることを確認する方法を知っています。また、開発者の時間を、本当にフルタイムの仕事であり、広範なビジネストレーニングが必要なものから解放します。これはすべて、本番環境でのバグの減少と全体的な品質の向上につながる可能性があり、顧客（およびの満足度は全体のポイントではありません）それ？）。
私の経験では、プロジェクトが大きく/複雑になるほど、完全なQAチームを持つことで得られる付加価値は大きくなります。開発者が1人（または少数）で、使用例が単純な小規模なシステムでは、付加価値はそれほど大きくなく、場合によっては、個別のQAチームを持つことは冗長（そしてコストがかかる）if =テストは、開発者が自分で管理するのに十分簡単です。
FrustratedWithFormsDesigner 1つのケースを表示 個別のQAが役立つ場合-複雑なシステム。
別のQAが役立つだけでなく、必須の規制された環境である場合もあります。独立した検証と検証の概念があります。独立とは、本番用のコードを記述していない個人または人々のグループによって行われることを意味します。一部の環境（私は航空宇宙およびヘルスケアでの経験があります）および特定の条件下では、ある程度の独立した検証または検証、あるいはその両方があることが義務付けられています。私のすべての経験において、開発チームは、ガベージが独立したQAテスターに引き渡されないことを確認するために、ある程度のテストを担当しています。さらに、独立したテストは、手動テスト、自動テスト、またはその両方の組み合わせです。
「個別のQA」が実際に何を意味するのかという問題もあります。 QAスタッフを各開発チームに組み込むことを意味しますか、それとも、開発チームからQAチームへの引き継ぎを意味しますか。両方のモデルで独立性を実現できます。
@FrustratedWithFormsDesignerで議論された点は間違いなく気に入っていますが、完全なソフトウェアシステムに関しては、テストタイプのより広い範囲を検討することは有用だと思います。私は誰が何をすべきかについて意見の違いがあると確信しています-そして私は議論を歓迎します:-)-しかし下の図は私の経験と意見を表す簡単なスケッチです。
あなたが観察するように、誰が何をテストすべきかに関して多くの重複があります。開発者は、単体テストだけでなく、記載されている他のカテゴリのテストの手段によって、完全で正しい製品（または機能）をQAに提供する責任があります。私が「セカンダリ」とマークしたものは、開発者が検討する必要がありますが、開発者の主要な責任ではありません。そのため、専任のQA担当者、つまりこれらの分野の専門知識を持つ人材が必要です。
ビジネスの利害関係者は別のレベルの検証を追加します。テストへの参加は会社ごとに大きく異なりますが、結局のところ、許容できる製品または許容できない製品を顧客に提供するのは彼らです。
私のチャートからのいくつかの重要なポイント：
単体テストは開発者の唯一の領域です。コーディングの専門知識を持つQA担当者は、内部の一部を覗き見するだけでなく、単体テストではなく機能テストやその他のテストの開発を支援したいと思うかもしれません。
QAは、@ FrustratedWithFormsDesignerで既に説明されているシステム全体の相乗効果を担当します。
セキュリティは皆のビジネスです！
もちろん、QAに引き渡す前に自分で十分にテストしました。しかし、開発者がアプリケーションに最も精通しているという事実自体が、誰かにELSEをテストしてもらう最良の理由です。
開発者はソフトウェアが何であるか想定であること、それが想定でどのように使用されるかなどを知っており、彼または彼女がしようとする場合は例外的です世間知らずのユーザーが想定している方法で使用して、予期しない方法でそれを壊してください。それは、X線視力を持つものにとってブラックボックスになることは決してありません。多くの場合、開発者は、プロジェクトに関与するすべての人の現実の世界での使用から最も削除される開発者です。