QA対開発率
私はソフトウェア開発者として働いており、今日、QAチームと次のことについて口論をしました。
QAチームのメンバーは、同じ製品に取り組んでいる開発者の数をどれだけ超える必要がありますか？
これは何かをプログラムする方法についての質問ではないことは知っていますが、この質問はソフトウェア開発にほとんど関係していると思います。ですから、この質問が閉じられないことを願っています。代わりに、SWの開発会社で働いた経験のあるプロのプログラマーから回答を得て、良い統計を作成できるようにします。
答えは非常に主観的ですが、ここに私の経験があります。
Microsoftには強力なテスト開発組織があります。従来のQAとは少し異なります。なぜなら、私たちはプログラマを雇ってテストし、設計段階の早い段階でプロセスに関与させるからです。彼らの仕事は、テスト、特に製品のテストの自動化です。私の経験では、テスターが機能のテストと自動化に要する時間は、開発者が製品のバグをコーディングして修正するのとほぼ同じです。これは、1：1マッピングを意味します。これは、単体テストの作成にコードの作成と同じくらいの時間がかかるという経験則に非常に似ています。
この組み合わせは、いくつかの基準によって異なります。
- 開発者が行っている単体テストの量。それらが多ければ多いほど、必要なテストは少なくなります。
- 開発者が既存のライブラリを活用するのと比較して、ゼロから作成する量。使用中の既存のコードが多数あり、テスターがその機能も検証する必要がある場合、1：1マッピングのためにその沈没した開発コストを考慮する必要があります。
- 開発がどれほどダイナミックか。比較的小さな開発者の微調整がテスト可能なサーフェスに大きな変化を引き起こすUIを作成している場合、より多くのテスターが関与する必要があります。
- 機能のミッションクリティカル性。 GMailのようにカジュアルに使用され、現場でバグを容認して修正できるものを作成するには、必要なテスターが少なくなります。逆に、 医療用画像処理装置 に取り組んでいる場合、バグは現場で修正するのが難しく、発生したときには非常に悪いため、さらに多くのテストが必要です。
私の会社で働くほとんどのプロジェクトでは、比率は1：1です。しかし、これはいくつかの要因によって異なります。
- 開発出力。大量の出力があり、3つのQAが機能に取り組んでいる開発者を見てきました。
- 製品の品質バー。ミッションクリティカルで信頼性の高いシステムには、内部レポートWebサイトよりも高いQAバーが必要であり、より多くのQAスタッフが必要です。
- 一部のプロジェクトは、より多くの構成とシナリオでテストする必要があります。開発者は不変ですが、テストマトリックス全体をカバーするには、明らかにQAがさらに必要になります。
- テストの自動化の程度。テストを簡単に自動化できない場合は、手動パスを行うためにさらに多くの人が必要になります。
私の仕事の場所は、現在8：1のdev：qaです。その理由は、自動化されたテストを非常に真剣に受け止めているためです。すべての作業には、ほぼ完全な単体テストのカバレッジが必要です。また、Fitnessで機能テスト（すべてのユーザーストーリーにFitnesseテストが必要）、チェックインがCIサーバーで完全なテスト実行をトリガーし、開発者が頻繁にチェックインし、頻繁にリリースします。
これはすべて、数千のクラスと無数のシナリオを持つ巨大なアプリケーション上にあります。利点は、速度、俊敏性、そしてもちろんコストです。開発者（高価な開発者でも）がテストの作成に費やす余分な時間は、QAスタッフの雇用/管理、または本番環境でのバグの発見（QAスタッフでさえ人間である）の人的資本よりも短くなります。
私たちが持っている小さなQAスタッフは、Seleniumを使って独自の自動化されたテストを作成したり、新しい機能に従事したりすることに時間を費やしています。彼らは同じ機能を何度も何度も再ハッシュするのに比較的短い時間を費やします。
私の経験では、QAスタッフには2つの主要な種類があります：単純に記述されたスクリプトに従い、Edgeケースを見つけるためにアプリケーションと対話する人と、自動テストコードを自分で実際に書き、新しい人を見つけようとする人開発チームのコードを破壊する革新的な方法（ファジング、Selenium、APIクライアントの作成）。
QAチームが主に最初のタイプの人々で構成されている場合、開発者に対して1：1以上の比率がおそらく必要です。そうしないと、開発チームが導入した新しい機能に追いつくのに苦労し、テストワークフローをさらに複雑にするため、製品に加えられたanyの変更に抵抗することがよくあります。
一方、後者のタイプ（つまり、コーディングできるテストエンジニア）は、生産的な開発チームにとってgodsendです。コーダーはピアとして彼らと通信することができ、テスターはよりスマートでより抽象化されたテストハーネスとユーティリティを記述することにより、独自のプロセスを自動化および改善する便利な方法を見つけることができます。本当に優れたテストエンジニアの1人がおそらく2〜3人の開発者の作業をサポートできます。特に、これらの開発者が既にテスターが開始点として使用できる有用な単体テストと統合テストを書いている場合です。
多くの要因がありますが、最も重要なのはアプリケーションに必要な品質レベルですが、小さなWebサイトですか？または主要な医療機器？または金融システム？スペースシャトルのコードを1行変更すると、数週間のテストが必要になる場合があります...
プログレッシブ開発ショップでは、TDD、コードレビューなど、QAの改善が実装されるにつれて、QAリソースのニーズ（開発に対する比率として）が時間とともに減少するはずです。プロセスを改善し、開発者が愚かさを感じるのを助けるために利用する（リリース前にバグを削除することにより）。
QAスタッフの人数開発者の人数に依存しない。それは、製品の望ましい品質に依存する必要がありますが、他のものには依存しません。
ここで多くの人は、良い開発者の仕事を「QAに」するのは、悪い開発者の仕事を「QAに」するよりも簡単な作業だと言います。地獄、なぜそれは本当ですか？ 「品質を保証」すること、およびQAは「品質保証」であるということは、「QA合格」および「QA失敗」で製品をマークするプロセスを設計することを意味します。コード自体に依存するプロセスは、静的コードチェックとピアレビューの2つだけです。前者は多少使用されますが、それを維持するためにQAを必要とする場合がありますが、コードの「quality」と呼ばれるものは重要ではありません魂のない機械。また、ピアレビューはQAではなくプログラマによって行われます。これにより、QAの量が開発者に依存しないことを納得していただければ幸いです。
当社が取り組んでいる分野では、競争はなく、市場は非常に狭いです。したがって、バグレポートからすべての必要な情報を取得し、QAはありませんなので、比率はゼロになります。すべてのテストは開発者が行います。それでも、必要な品質はQAスタッフを必要としないため、私たちは生きています。
開発中の組織とWeb /アプリに依存します。すべての企業は、要件に応じて独自のdev：QA比率を持っています。
つまり、プロジェクトの規模と組織で利用可能なリソースに依存します。
私たちの組織では、比率はdev：QAが5：2であり、このためには次のようなシナリオを理解する必要があります。
ユニットテストに取り組んでいる人、私たちの場合、1人がユニットテスト計画を書くことに完全に専念し、5人のメンバーのチームがユニットテストケースを実行し、PLをコーディングに関与していないバグを修正しています指向のもの
機能テストは、開発者が行う機能テストの半分のリソースと1サイクルを言うことができるパートタイムテスターによって行われます
そのため、CMMレベルに基づいて、プロジェクトのサイズ、LOCの記述、および企業のリソースに依存します。
現在、私が働いているところでは、QA担当者ごとに3人の開発者がいます。 QAが問題を見つけることがあるため、これには浮き沈みがありますが、コードの変更以外にも解決策があります。無意味な場所をクリックしないでください。
私が仕事をしたQAはありませんが、問題が開発者の問題になると顧客がQAになるので、時には災害のレシピのようなものです。
人の数ではなく、費やした時間の観点から考えてください。十分にテストされ、「承認された」アプリケーションでは、開発時間ごとに1時間のQA作業が行われる可能性があります。機能テストではなく、技術的なQAの役割に特に言及します。 QAチームと開発チームは密接に連携できる必要があるため、QAチームは開発と同時にテストケースを作成できます。これは、すべてを実装コントラクト（関数名、入力パラメーターなど）に書き込む必要があることを意味します。