私はソフトウェア開発者として働いており、今日、QAチームと次のことについて喧嘩をしました。
QAチームのメンバーは、同じ製品に取り組んでいる開発者の数をどのくらい超える必要がありますか?
これは何かをプログラムする方法についての質問ではないことを私は知っていますが、この質問はソフトウェア開発にかなり関係していると思います。ですから、この質問が閉じられないことを願っています。代わりに、SW開発会社での作業に優れた経験を持つプロのプログラマーから回答を得て、優れた統計を作成できるようにします。
私はソフトウェア開発者として働いており、今日、QAチームと次のことについて喧嘩をしました。
QAチームのメンバーは、同じ製品に取り組んでいる開発者の数をどのくらい超える必要がありますか?
これは何かをプログラムする方法についての質問ではないことを私は知っていますが、この質問はソフトウェア開発にかなり関係していると思います。ですから、この質問が閉じられないことを願っています。代わりに、SW開発会社での作業に優れた経験を持つプロのプログラマーから回答を得て、優れた統計を作成できるようにします。
答えは非常に主観的ですが、これが私の経験です。
Microsoft には強力なテスト開発組織があります。これは、従来の QA とは少し異なります。プログラマーを雇ってテストし、設計段階の早い段階で彼らをプロセスに関与させるからです。彼らの仕事はテストであり、特に製品のテストを自動化することです。私の経験では、テスターが機能をテストして自動化するには、開発者が製品のコードを作成してバグを修正するのとほぼ同じくらいの時間がかかります。これは、1:1 マッピングを意味します。これは、単体テストの作成にコードの作成と同じくらいの時間がかかるという経験則と非常によく似ています。
この組み合わせは、いくつかの基準によって異なります。
会社のほとんどのプロジェクトでは、私は1:1の比率で働いています。ただし、これはいくつかの要因によって異なります。
私の経験では、主に 2 種類の QA スタッフがいます。書かれたスクリプトに従って単純にアプリケーションと対話してエッジ ケースを見つける努力をする人と、実際に自動化されたテスト コードを自分で書き、新しいものを見つけようとする人です。開発チームのコードを壊すための革新的な方法 (ファジング、Selenium、API クライアントの作成)。
QA チームが主に前者のタイプの人で構成されている場合、開発者との比率が 1:1 以上であることがおそらく必須です。そうしないと、開発チームによって導入された新機能についていくのに苦労し、テスト ワークフローがさらに複雑になるため、製品に加えられた変更に抵抗することがよくあります。
一方、後者のタイプ (つまり、コーディングできるテスト エンジニア) は、生産的な開発チームにとって天の恵みです。コーダーはピアとして彼らと通信でき、テスターは、よりスマートでより抽象化されたテスト ハーネスとユーティリティを作成することで、自分のプロセスを自動化および改善するための便利な方法を見つけることができます。1 人の非常に優れたテスト エンジニアは、おそらく 2 ~ 3 人の開発者の作業をサポートできます。特に、これらの開発者が、テスターが出発点として使用できる有用な単体テストと統合テストを自分で作成している場合は特にそうです。
それに答えるには多くの要因があります。
私は、3:1 (QA/DEV) から .5:1 (QA/DEV) までさまざまな場所で働いてきました。要するに、製品を適切にテストするために必要な QA リソースの数にあり、それに対する包括的な答えはありません。
現在、私が働いている場所では、QA担当者ごとに3人の開発者がいます。これには浮き沈みがあります。QAで問題が見つかることもありますが、コードの変更以外にも解決策があります。たとえば、無意味な場所をクリックしないでください。
数回、私が働いたQAはありません。これは、顧客が開発者の問題になるとQAになるため、災害のレシピのようなものです。
多くの要因がありますが、最も重要なのは、アプリケーションに必要な品質レベルです。それは小さな Web サイトですか? または主要な医療機器?または金融システム?スペースシャトル用にコードを 1 行変更するだけで、数週間のテストが必要になる可能性があります...
プログレッシブ開発ショップでは、TDD、コードレビューなどのQA改善が実装されるにつれて、QAリソースの必要性(開発に対する比率として)は時間の経過とともに減少するはずです。私はQAがテストの純粋な実践に焦点を当てているのは無駄だと思います.QAはそうすべきです.プロセスを改善し、開発者が愚かだと感じるのを助けるために利用されます (リリース前にバグを取り除くことによって)。
それは、開発されている組織と Web/アプリによって異なります。すべての企業は、要件に応じて独自の開発: QA 比率を持っています。
つまり、プロジェクトのサイズと組織で利用可能なリソースに依存します。
私たちの組織では、比率は dev:QA が 5:2 であり、このためには、次のようないくつかのシナリオを理解する必要があります。
私たちの場合、1 人が単体テスト計画の作成に専念し、5 人のメンバーからなるチームが単体テスト ケースを実行してバグを修正しています。PL はコーディングにはまったく関与せず、プロセス/レビューのみを行っています。指向のもの
機能テストはパートタイムのテスターによって行われます。半分のリソースと 1 サイクルの機能テストは開発者によって行われます。
そのため、CMM レベルに基づくプロジェクトの規模、LOC の記述、会社のリソースによって異なります。
QA スタッフの数は、開発者の数に左右されるべきではありません。それは、製品の望ましい品質に依存する必要がありますが、他のものには依存しません。
ここにいる多くの人は、優れた開発者の仕事を「QAする」ことは、悪い開発者の仕事を「QAする」ことよりも簡単な作業だと言います。くそ、なぜそれが本当なのだ?「品質を保証する」(QA は「品質保証」です) とは、製品に「QA 合格」および「QA 不合格」のマークを付けるプロセスを設計することを意味します。私が知っているコード自体に依存するプロセスは、静的コード チェックとピア レビューの 2 つだけです。前者は多少使用されており、それを維持するために QA 担当者が必要になることもありますが、コードの「品質」と呼ばれるものは、魂のないマシンにとって重要なことではありません。また、ピア レビューは QA ではなくプログラマーによって行われます。これで、QA の量が開発者に依存しないことを納得していただければ幸いです。
当社が取り組んでいる領域では、競合がなく、市場が非常に狭いです。したがって、必要な情報はすべてバグ レポートから取得し、QA がないため、比率はゼロです。すべてのテストは開発者によって行われます。それでも、必要な品質のために QA 担当者を雇う必要がないため、私たちは生きています。
人数ではなく、費やした時間の観点から考えてください。十分にテストされ、「承認された」アプリケーションの場合、開発時間ごとに1時間のQA作業が行われる可能性があります。機能テストではなく、技術的なQAの役割について具体的に言及します。QAチームと開発チームは緊密に連携できる必要があります。これにより、QAチームは、開発の発生と同時にテストケースを作成できます。これは、すべてを実装コントラクトに書き込む必要があることを意味します(関数名、入力パラメーターなど)。
さて、これは一日の終わりにスタッフの質に依存します。1人のプログラマーが2つのQAと同じくらい多くの作業を行う場合、比率は1:2であり、その逆も同様です。ここのスタッフの質は#1でしょう。