データベースと独自の Swing フロントエンドを含むいくつかのバックエンド層を含む、かなり複雑な Java システムがあります。フロントエンドを模倣する外部関係者が接続できるバックエンド API があります。私たちの組織には、このシステムを共有する約 5 つのサイロがあります。このシステムを維持している開発者は合計で約 15 人です。
QA チームの規模について経験則はありますか?
編集：これまでの回答で提起された質問に基づいて、少しコンテキストを追加するには：
元テストチームのリーダーとして、できるだけ多くのテストを行うことをお勧めします。組織内の多くの人がソフトウェアに依存しているようです。早期にテストし、頻繁にテストします。
テストはすべての人の責任であることを認識することが非常に重要です。開発者は、優れた単体テストを作成する必要があります。UI開発者は、UIを手動でテストする必要があります。
テスト駆動開発を奨励し、メトリックを監視し（正式なバグ追跡システムを使用し、欠陥密度を追跡するなど）、継続的インテグレーションサービスをセットアップし、テスト容易性のためのコードを設計します（依存性注入にSpringなどのフレームワークを使用し、モックを使用します）および外部サービスのスタブなど-詳しく説明したいと思います）。バグを修正するためのコストは、後で見つけたときに指数関数的に高くなるため、正式なQAに入る前に見つけるのが最適です。
ジェフ
1つのQAから5または6人の開発者に始めます。次に、QAが実行する必要がある、または実行する必要がないと思われる作業の量に応じて、調整を開始します。
実は、あまりにも多くの要因が関係しているので、それは私自身の経験に基づいています。コードベースはどの程度開発されているか、安定していますか？それはどれくらい大きいですか？テストはどの程度包括的である必要がありますか？どのような種類のテストおよび分析ツールが関係していますか？マイルストーンリリースの頻度はどれくらいですか？どのような開発プロセスがありますか？どのくらいの手動テストとどのくらいの自動テストですか？
もっとたくさんの質問があります。したがって、任意の番号から始めて、そこから進んでください。
合理的なQAと開発の比率は、問題のアプリケーションの複雑さに関連してのみ導き出すことができます。
明らかに、uberdeveloperは、ワークフローが複雑なため、フルタイムで3つのQAしか効率的にテストできない複雑なアプリケーションを思い付く可能性があります。次に、比較的単純な入出力レポートアプリケーションをつなぎ合わせる3人のジュニア開発者に対して1つのQAが存在する可能性があります。
したがって、必要なQA担当者の数は、使用するソフトウェア開発者の数ではなく、要件の数と複雑さによって決まります。
その多くは、システムが何をするか、および欠陥の結果がどうなるかに依存しますか? 金融ソフトウェアを作成していますか? それともソーシャルネットワーキング？一方が失敗した場合のコストは他方よりも大きくなる可能性があるため、QA の取り組みはさまざまです。同様に、それが製品 (複数のユーザー ベースがインストールされており、パッチを適用するのが難しい可能性がある) の場合は、内部の場合よりも安定している必要があります。
また、基本的なシステム テストまたはボリューム テストと負荷テストも行うことを期待しているかどうかを尋ねる必要があります。UI テストと API テストの組み合わせを見ているようですね。
出発点として、あなたが「通常の」タイプのシステムについて話していて、基本的なシステム テストについて話していると仮定すると、私が使用する指標は、すべての労力の 33% がテストの労力になるということです。理論的には、これにより 1 対 2 の比率が得られますが、開発者が単体テストを行っていると仮定すると、おそらく 1 対 3 に引き伸ばされます。確かに、現在は 1 対 4 で実行しており、それでは十分ではありません (できるだけ早く修正します)。ビジネスは私に許可します）。
ただし、ソフトウェア開発プロセスがどの程度成熟しているか、および仕様がどのようなものかについても検討する必要があります。適切な数のテスターを確保するだけでなく、テストするための適切な情報を彼らに提供する必要があります。彼らがそれを持っていなければ、彼らは仕事をすることができず、間違いなくお金の無駄です。
そこに投入するもう1つのオプション-製品はしばらく開発中のようです. 通常のテスターのコアと同様に、短期間の請負業者を使用して、最初の主要なテストのためにまとめることをお勧めします。テストリソースを持ち込むだけの場合は、大きなバックログで開始したくありません。
いいえ、経験則はありません。組織ごとに要件、ニーズ、プロジェクトなどのセットがまったく異なるため、組織はそれぞれ異なります。自分の組織に適したものしか見つけることができません。
これは、コード ベースの関与度 (統合モジュールが多数存在するかどうか) と、ユーザー エクスペリエンスの関与度 (テストするビジュアル要素と入力コントロールが多数存在する場合) に依存する可能性があります。
かなり複雑なシステムの場合は、5 人の開発者ごとに 2 ～ 3 人の QA エンジニアを検討することをお勧めします。ただし、機能があまり変わらないか、関与が少ない場合は、5 人の開発者ごとに (おそらく 10 人の開発者ごとに) QA を 1 回行うだけで済むと思います。
3 人の開発者に対して 2 人のテスト エンジニアは、適切なスタートです。多くのテスト ケースに自動化できないもの (物理的なプラグの抜き差し、UI レンダリングの視覚的検証) が含まれている場合は、2 人のテスト エンジニアごとに 1 人のテスターを追加します。