開発とQAの間のより長い遅延のコスト
私の現在の立場では、QAがボトルネックになっています。残念なことに、QAがテストを終了できるように、現在のビルドから除外された機能が発生しています。つまり、開発中の機能は、開発者がすでに移行してから2〜3週間テストされない可能性があります。開発者がQAをより速く進めると、この時間ギャップはさらに大きくなるだけです。
私はコードコンプリートのコピーをめくって、欠陥を修正するコストが存在するほど指数関数的に増加することを示す「ハードデータ」スニペットを探しています。誰かがこの概念を裏付けるいくつかの研究を私に指摘できますか？私は、QAのボトルネックは、彼らが思っているよりもはるかにコストがかかるということを、権力に納得させようとしています。
IMHO、リファレンスは必要ありません。これはあなたができることです（むしろすべきです）：
遅延のコストを定量化！機能のテストに1週間かかると仮定しましょう。 2〜3週間の遅延は、少なくとも4週目まで機能が利用できないことを意味します。そして、それも100％の成功を前提としています。約5週間の遅延になるように、もう1週間の修正時間を追加します。
さて、可能であれば、プロジェクト/機能の予想される締め切りにアクセスしてください。クライアントはいつまでにそれを期待しますか？滑りますか？そうでない場合、結果として他の人はスリップしますか？それで、結果として「リリース」はどれくらい遅れますか？
そのリリースの「会社にかかるコスト」はどれくらいですか？つまり、クライアントはそのリリースからどれくらいの利益を期待できるでしょうか？彼らがそのリリースから5200ドル/年の利益を期待している場合、毎週スリップすると、失われた収益に100ドルがかかります。それがクライアントの見解です。このデータにアクセスできる場合とアクセスできない場合がありますが、考慮に入れて、遅延が関係にどのように影響するかを説明することは価値があります。
さて、開発者にとっての損失は何ですか？開発者が他の機能に移行したら、開発者に彼らのサイクルを断ち、以前の機能を「修正」するように依頼します。時間/労力の損失は何ですか？結果として無駄になる1時間ごとに給与を倍数として使用して、会社のコストに変換します。これを使用して、廃棄物が「食べている」「利益/収益」の量を表すことができます。
偶然見つけたものは、「コストオブディレイ」を使用して簡単に定量化できます。これは、製品開発フローのDon Reinersteinと、アジャイルソフトウェア要件のDean Leffingwellによって提唱されています。あなたは、経済的要因によってそのようなすべての主張を裏付けて、主要言語が$$である「より高い力」を納得させる必要があります-あなたはmust彼らを納得させるために彼らの言語を話します:)
運の獣！ （しゃれ意図:)
ここではCode Completeが適切なリソースだとは思いません。これはコードの問題ではなく、プロセスの問題であり、おそらく管理の問題です。
プロセスの一部が特に弱い場合は、 Theory of Constraints ：
制約を特定します。
これは、プロセス全体の中で最も遅い、または最も非効率的な部分を見つけることを意味します。あなたの場合、それはテスト中です。しかし、テストのどの部分？それは...ですか：
- テスト環境を準備していますか？
- 何をテストするかを決定していますか？
- 機能（受け入れ）テスト？
- 回帰テスト？
- 探索的テスト？
- テストからバグ/欠陥を報告しますか？
- バグを再現する手順を決定しますか？
- 開発者やプロジェクトマネージャーから説明を受けていますか？
- QAステージで見つかった問題を修正しますか？
これらはすべて非常に異なる問題であり、異なる解決策が必要です。どちらが最もコストがかかる/重要かを判断する必要があります。上記の活動はすべて時間がかかる（別名：お金）ため、付加価値時間に過ぎないので、経営陣にそれを正当化することは難しくありません。
制約を利用します。
つまり、制約プロセスをaround最適化します。テスターをアイドル状態にしないでください。これは基本的に次のようになります。
- テスターを開発チーム内に配置します（まだ配置していない場合）。開発者との継続的なフィードバックループがあります。
- テストの展開が頻繁に行われるため、常に新しいテストまたは修正されたテストがあります。
- コミュニケーションをより速く、より頻繁にします。たとえば、メールスレッドよりもインスタントメッセージングを優先します。
- テスターが利用可能な最高のツールを持っていることを確認する（高速マシン、マルチモニター、合理化されたバグ追跡など）
この段階では、テストプロセス自体を（まだ）最適化するのではなく、オーバーヘッドを減らすことが重要です。テスターの時間を無駄にしないでください。本当に無駄な時間（= /// =）をなくすことも、管理者にとって容易な売りです。
その他の制約に従属するアクティビティ
この時点で、テスターはそれ自体で可能な限り生産性が高いので、他の領域から生産性を借り始める必要があります。
- 開発者と運用スタッフに、テスターが何に取り組んでいるかに関係なく、テスターを最優先するように指示します。
- 部門を超えたチームがない場合は、事前に設定された時間に毎日会議室を予約して、テスターが予約するのに時間を浪費しないようにします。
- 開発者（および場合によっては操作）の時間のより大きな割合を機能作業から逸らします。たとえば、バグ修正、技術負債/リファクタリング、コードレビュー、ユニットテストに重点を置きます。
- 継続的かつ段階的にテストします。3週間は開発せずに、テスターに引き渡してください。開発者にコードをすぐにテストできるようにするよう働きかけます。足場またはプロトタイプUIを使用します。
制約を引き上げます。
テスターが生産性と最小限のオーバーヘッドの両方の面でフル稼働していて、それでもまだ十分に速くない場合は、テストへの投資を増やす必要があります。
- 手動のテスト展開に依存している場合は、継続的な統合および構成管理スクリプトを使用して自動化します。
- テスト計画の作成に長い時間がかかる場合は、より良い受け入れ基準（つまり、 [〜＃〜] invest [〜＃〜] ）の取得に取り組みます。ほとんどの組織は、最初はこれで非常に悪いです。
- 受け入れテストに時間がかかりすぎる場合は、自動化を開始してください。 CucumberやFitNesseなどのツールを使用するか、必要に応じてxUnitタイプのテストを記述します。 UIテストに長い時間がかかる場合は、Selenium、Watij、およびその他のブラウザー自動化ツールもあります。
- 回帰テストに時間がかかりすぎる場合は、それも自動化します。自動化できない場合は、コードのレビュー、単体テスト、静的分析ツールなどにさらに重点を置いて、ゲートから品質を改善することに焦点を当てます。開発者は、実際の数バグをQAに渡す前に（製品の欠陥は別の話です）。
- 探索的テストがボトルネックである場合は、リリース後までその一部を延期するか、テスト会社に委託して、複数のブラウザーで同じワークフローをテストするなどの高度に並列化可能なことを行うことができます。
- テスターが多くのバグを再現できない場合は、断続的なエラーの再現を開始できるように容量テスト環境を構築することを検討してください。または、詳細なログを保持しながら、自動受け入れテストを1日中並行して継続的に実行してみてください。
- バグの修正に時間がかかりすぎる場合は、プロジェクトのパーティション分割を開始するか、ソリューションの再設計を真剣に検討してください。または、代わりに、一部を修正しないでください。すべてのバグが重大であるとは限らないため、機能の作業と一緒にそれらに優先順位を付けることができるはずです。
- 他のすべてが失敗した場合は、より多くのテスターを雇います。
手順1に戻ります。
これはすべての常識ですが、残念ながら、少なくともほとんどの組織ではそうではありません。管理から多くの抵抗を得ている場合、非常に貴重な手法は Value Stream Mapping （無駄のない製造からの手法）です。これは、どれだけの時間を示すために使用できるため、実際にすべてのお金が無駄になっていますリリース候補者が次のステージに移動できない日。機会費用を理解するのは難しいですが、これは、それを視覚化して実証するために私が見つけた最良の方法の1つです。
そして、なしが機能する場合...多分あなたは機能不全の会社にいるかもしれませんが、手遅れになる前に出てください！
しかし、マネージャーの机に数枚の紙を落とし、問題にお金を投げるように依頼するだけでは、この問題を解決できません。彼らは、（正しく）お金を投げても実際には解決しない可能性があり、それはさらに悪い。 solutionsを提供する必要があります。それがこの答えです。 「より多くのテスターが必要」ではなく、「コスト/メリットの降順でこの問題を解決する方法のリストをここに示します」として問題を紹介すると、より多くの成功を収めることができます。
29と30ページには、探しているデータがあるかもしれませんが、フォローアップが必要な場合があります。
30ページのこの文で言及されている調査を調べます。
何十社もの企業が、プロジェクトの後半ではなく早期に欠陥の修正に集中するだけで、開発コストとスケジュールを2倍以上削減できることを発見しました（McConnell 2004）。
ところで、本を手に取り直して更新したのはあなたの質問でした:-)
あなたが説明しているのは、プロセスのボトルネックです。リーン理論は、プロセスには常にボトルネックがあると述べていますが、その重大度は大きく異なる可能性があります。 QAがさらに1人雇った場合、開発がボトルネックになる可能性があります。
コストを理解するために、次の状況を想像してみてください。開発者の1人を選びました。彼の仕事は決して品質保証されることはありませんが、常に無期限にキューに入れられます。想像してみてください。これは、QAが残りの開発者の作業をタイムリーに品質保証でき、遅延によるコストが発生しないことを意味します。
そのシナリオでは、遅延のコストは、開発者の仕事が無駄になるため、開発者の給与のコストです。
プロセスによって生み出された価値ではなく、コストの観点から私が議論する理由は、プロセスの価値ははるかに優れているとはいえ、それを文書化することは困難だからです。
私はコードコンプリートのコピーをめくって、欠陥を修正するコストが存在するほど指数関数的に増加することを示す「ハードデータ」スニペットを探しています。誰かがこの概念を裏付けるいくつかの研究を私に指摘できますか？
バグを発見するための指数コストは NIST調査 に基づいているようです。この調査は、明確な滝の段階を想定した調査でした。
Software Development Stage | Cost
-----------------------------------+------
Requirements and Design | 1X
Code and Unit Testing | 5X
Integration and System Testing | 10X
Beta Testing | 15X
Post Release | 30X
（ ここからここにテーブル ）
アジャイルソフトウェア開発方法論の目的の1つは、これらの個別の段階を削除し、これらのコストを削減することです。ウォーターフォールに他の方法を使用する場合、この数値は適用されません。
問題はQAにありません。実際、QAがテストを行っている場合、遅延はほとんど心配する必要はありません。もう一度説明させてください（繰り返しになりますが、これはプログラミング業界ではよくある誤解です）。QA要件（多分以前）から、開発、検証、リリース、サポートまで、SDLC全体を監視することにより、製品の品質を保証します。テストでは、コードに明らかな欠陥がないことを確認します。非常に大きく重要な違いがあります。真のQAが得られた場合、彼らはテスト/ V＆V部門全体で、なぜリリースに遅延してビジネス時間（したがってお金）がかかるのか、プロジェクト管理全体でプロジェクトのスケジュールを適切に管理しているか、またはすべての管理を行っているのかを尋ねます。生成されるコードなどに十分なテスターがいることを確認してください...
したがって、QAであなたが本当にテストを意味していると仮定すると、元の質問に戻ります。コードコンプリートはそれを正しく理解しました-欠陥のコストは挿入から修正までの時間です。早期検出は、早期に修正する場合にのみ役立ちますが、ほとんどの人の解釈は間違っています。
（注：私はここでデビルズアドボケイトを演じていますが、あなたの状況は何も知らないので、これを文字どおりに受け取らないでください）テスト部門による遅延の原因は代償ですが、もしそうなら、私は尋ねなければなりません彼らがあなたの欠陥を見つけるのを待っています、あなたは何をしています-あなたはあなた自身の欠陥を見つけてはいけませんか？おそらく、彼らの仕事が少ない（あなたからの欠陥が少ない高品質の入力による）場合、遅延はそれほど大きくなく、コストも低くなります-マネージャーとして、提供するコードの欠陥を減らす方法を尋ねます（あなたの議論に基づいて）テストによって発見された場合、それらの欠陥はあなた自身よりもコストがかかるので、テストします。
また、あなたのマネージャーとして、私はテストの仕事があなたの欠陥を見つけることではないと述べるかもしれません、彼らの仕事は欠陥がないことを見つけることです-あなたが彼らに欠陥を見つけることを期待しているなら、おそらくあなたの仕事を十分に行っていないかもしれません。
これへのアプローチ方法に注意してください。問題の解決策がない場合は、2番目に優れている可能性があります。