2009-07-14 10 views
7

私たちは、データベースと独自のSwingフロントエンドを含むいくつかのバックエンド層を含むかなり複雑なJavaシステムを持っています。私たちのフロントエンドを模倣する外部の当事者が付けることができるバックエンドAPIがあります。このシステムを共有する組織内には約5つのサイロがあります。合計で約15人の開発者がこのシステムを管理しています。QAからdevの比率

私たちのQAチームのサイズはどれほどの経験則ですか?

編集:これまでの回答で提起された質問に基づいてコンテキストのビットを追加するには:

  1. 私たちは、約4年のメジャーリリースとの間でマイナーなものの束を持っています。
  2. 私たちのプラットフォームには金銭的な変化の手があります。そのため、顧客に大きな意味を持つ計算があります。
  3. 私たちは正式なバグタッキングシステムを使用しています。
  4. 私たちはTDDを利用しません。
  5. 私たちは、連続統合のためのcruisecontrolのようなツールを使用します。
+0

回帰テストの完了までにどれくらいの時間がかかりますか?確かにこれに基づいているはずですか? – Jon

+6

私はこれが閉鎖したいと思っている人には同意しません。関連するプログラミングではありませんが、ソフトウェアの品質とソフトウェア開発のライフサイクルには密接に関連しており、絶対に重要です。 –

+0

regeressionが完了するまでに1週間以上かかります – akf

答えて

9

以前のテストチームのリードとして、できるだけ多くのテストを行うことをお勧めします。組織内の多くの人があなたのソフトウェアに依存しているように思えます。早期にテストし、頻繁にテストします。

テストが誰の責任でもあることを理解することは非常に重要です。開発者は良い単体テストを書く必要があります。 UI開発者は手動でUIをテストする必要があります。

私は、テスト駆動開発、メトリック(正式なバグ追跡システムの使用、欠陥密度の追跡など)、継続的な統合サービスの設定、テスト容易化のための設計コード(依存性のためにSpringのようなフレームワーク注入、外部サービス用のモックとスタブの使用など - 私は詳細に議論することを嬉しく思います)。バグを修正するコストは、後で見つけたときに指数関数的に高価になるので、正式なQAに入る前に見つけられることが最善です。

ジェフ

+1

"UI開発者は手動でUIをテストする必要があります"開発者向けの自動化されたUIテストに投資してはいけませんか、それとも時間とお金の無駄でしょうか? – akf

+1

自動化されたUIテストはうまくいきますが、それは本当に難しいです。 UIはテストのために設計する必要があり、理想的には非常に薄い層でなければなりません。つまり、モデルビューコントローラのようなパターンを使用し、UIにビジネスロジックがないことを確認することを意味します。 自動テストを行うことができれば、私もそれをやるでしょう。私はUI開発者が自分の変更を手動でテストする必要があり、必ずしも完全な回帰テストを手動で行う必要はないということを意味しました。 QAテスターは必然的に手動でUIテストの一部または全部を行います。 –

+0

Swingを使用しているので、FEST http://easytesting.org/swing/wiki/pmwiki.phpテストフレームワークをお勧めします。これにより、Swing GUIの機能テストを書くことができます。 – Nate

2

これは、コードベースがどの程度関わっているか(統合モジュールがたくさんあるかどうか)、ユーザーエクスペリエンスがどのように関係しているか(テストするビジュアル要素と入力コントロールがたくさんある場合)

かなり複雑なシステムの場合は、5人の開発者ごとに2〜3人のQAエンジニアを検討するとよいでしょう。しかし、機能が実際にはあまり変わっていない、またはそれほど関与していない場合は、5人の開発者ごとにわずか1 QA(10人の開発者でさえ)で逃げることができます。

+0

「これらの機能はあまり変わらないのですか? – Yishai

+0

私は比率を指定していましたが、実際にはプロジェクトに必要な数の開発者ではありませんでした。 – mkmurray

+0

システム上の5 Devsの1 QAは非常に薄く、10 Devsの1 QAはちょうど不条理です。良いTDDであっても、約1QAから3Devの良好な比率が必要です。 – AutomatedTester

2

いいえ、経験則はありません。すべての組織は全く異なる要件、ニーズ、プロジェクトなどを持っているため、各組織は異なります。組織に適したものだけを見つけることができます。

+0

+1:これがなぜ落とされたのか分かりませんが、このような決定を各企業に独特のものにする要因はたくさんあります。 – Troubadour

4

最初にQAを5〜6人の開発者にしてください。その後、QAが何をしなければならないと考えるか、何もする必要がないと思っている仕事量に応じて調整を開始します。

実際には、あまりにも多くの要因が関係しているので、これは自分自身の経験に基づいているだけです。あなたのコードベースはどのように開発されたか安定していますか?それはどれくらい大きいですか?テストはどの程度包括的である必要がありますか?どんな種類のテストと分析ツールが関係していますか?マイルストーンはどれくらいの頻度でリリースされますか?どのような開発プロセスがありますか?手動テストの量と自動テストの量

さらに多くの質問があります。だから、任意の数から始め、そこから行く。

3

はDEV比合理QAは、当該アプリケーションの複雑さに対して導出することができます。

明らかに、uberdeveloperは、ワークフローの複雑さのためにフルタイムで3つのQAしか効率的にテストすることができない複雑なアプリケーションを思い付く可能性があります。順番に、3つのジュニア開発者が比較的簡単な入出力レポートアプリケーションを結合するための1つのQAがあります。

必要なQA担当者の数は、使用するソフトウェア開発者の数ではなく、必要な数と複雑さによって決まります。

1

彼の視点がthis article(9年前)から変更されているかどうかはわかりませんが、Joelは2人のフルタイムの開発者につきフルタイムのQA人を1人お勧めします。私は、常に更新されているシステムで、この比率はかなり良いと言います。

また、システムを頻繁に変更しているのではなく、更新することはめったにない場合は、なぜ開発者が多いでしょうか。私はほとんどすべての状況で1:2が完璧な比率であることを自分自身に説得することを馬鹿げています。 :)

0

3人の開発者に2人のテストエンジニアがまともなスタートです。多くのテストケースで、自動化できないもの(物理的なプラグ/抜き取り、UIレンダリングの視覚検証)が含まれている場合は、2人のテストエンジニアに1テスターを追加します。

3

多くのことは、システムの機能と欠陥の結果によって異なります。あなたは金融ソフトウェアを書いていますか?またはソーシャルネットワーキング? 1つの失敗の可能性のあるコストは他のものよりも大きいため、QAの努力は様々です。同様に、パッチ(パッチを当てるのが難しいかもしれない複数のインストールされたユーザーベースを持つ)の製品であれば、内部の場合よりも安定している必要があります。

また、基本的なシステムテストやボリュームテスト、および負荷テストを行うことを期待しているかどうかを確認する必要があります。あなたはUIテストとAPIテストの組み合わせを検討しているようです。

「正常な」タイプのシステムを話していると仮定し、基本的なシステムテストを話していると仮定すると、私が取り組んでいる測定基準は、すべての努力の33%がテスト努力でなければならないということです。理論的には、これは1対2の比を示しますが、開発者がユニットテストを行っていると仮定すると、おそらく1から3に伸びるでしょう。確かに私は現在1から4で動作していますが、それは十分ではありません。ビジネスは私に許可します)。

しかし、ソフトウェア開発プロセスがどれほど成熟しているか、そして仕様がどのようなものかを考慮したいと考えています。適切な数のテスターを持つだけでなく、テストするための適切な情報を与える必要があります。それがなければ、彼らは仕事をすることができず、間違いなくお金を無駄にします。

もう1つのオプションを指定すると、製品がしばらく開発中のように聞こえます。定期的なテスターのコアと同様に、短期契約者を使用して最初の主要なテストを一括して行うこともできます。あなただけのテストリソースを持っていれば、大きなバックログでそれらを起動したくないのです。

関連する問題