開発とQAの間の長い遅延のコスト

私の現在の立場では、QAがボトルネックになっています。QAがテストを終了できるように、現在のビルドでは機能が保持されないという残念な事態が発生しました。つまり、開発中の機能は、開発者が既に移行してから2〜3週間はテストされない可能性があります。開発者がQAをより速く進めることで、この時間差は大きくなるだけです。

私はCode Completeのコピーをめくり続け、欠陥を修正するコストが存在するほど指数関数的に増加することを示す「ハードデータ」スニペットを探します。誰かがこの概念を裏付けるいくつかの研究を教えてくれますか？私は、QAのボトルネックが彼らが考えるよりもはるかに費用がかかるという力を説得しようとしています。

参照は必要ありません、私見。これがあなたができることです（むしろすべきです）：

遅延のコストを定量化する！機能をテストするのに1週間かかると仮定しましょう。2〜3週間の遅延は、少なくとも4週目まで機能が利用できないことを意味します。そして、それも100％成功すると仮定しています。約5週間の遅延になるように、さらに1週間の修正時間を追加します。

これで、可能であれば、プロジェクト/機能の予想される期限にアクセスできます。クライアントはいつまでにそれを期待しますか？滑る？そうでない場合、結果として他の人は滑るでしょうか？それで、結果として「リリース」はどれくらい遅れますか？

そのリリースの「会社へのコスト」とは何ですか。つまり、クライアントはそのリリースからどれだけ利益を期待していますか 彼らがそのリリースから年間5200ドルの利益を期待している場合、毎週滑って100ドルの損失を被ります。これがクライアントビューです。このデータにアクセスできる場合とできない場合がありますが、遅延が関係にどのように影響するかを考慮して説明する価値があります。

さて、開発者にとっての損失は何ですか？開発者が他の機能に移行したら、サイクルを中断して前の機能を「修正」するように依頼します。時間/労力の損失は何ですか？結果として無駄になる毎時間の給与を倍数として使用することで、会社のコストに変換します。これを使用して、無駄が「食い込んでいる」「利益/収益」の量を言うことができます。

つまずいたものは、「遅延コスト」を使用して便利に定量化できます。製品開発フローの原則でドンライナースタインによって、またアジャイルソフトウェア要件のディーンレフィンウェルによって提唱されています。経済的要因によってこのような主張をすべて支持し、第一言語が$$である「より高い力」を納得させることができなければなりません。

運の獣！（しゃれ:)

ここでは、Code Completeが適切なリソースであるとは本当に思いません。これはコードの問題ではなく、プロセスの問題であり、おそらく管理の問題です。

プロセスの一部が特に弱い場合は、制約の理論を打ち破るときです。

1. 制約を特定します。

   これは、プロセス全体の中で最も遅いまたは最も非効率的な部分を見つけることを意味します。あなたの場合、テスト中です。しかし、テストのどの部分ですか？それは...ですか：

   • テスト環境を準備していますか？
   • テスト対象を決定しますか？
   • 機能（受け入れ）テスト？
   • 回帰テスト？
   • 探索的テスト？
   • テストのバグ/欠陥を報告しますか？
   • バグを再現する手順を決定しますか？
   • 開発者またはプロジェクトマネージャーから説明を取得しますか？
   • QAステージで見つかった問題を修正しますか？

   これらはすべて非常に異なる問題であり、異なる解決策が必要です。最も費用がかかる/重要なものを決める必要があります。上記のすべての活動に時間（別名お金）がかかり、そのうちの2、3だけが付加価値時間であるため、経営陣に正当化するのは難しくありません。

2. 制約を活用します。

   つまり、制約プロセスを中心に最適化します。テスターをアイドル状態にしないでください。これは基本的に次のとおりです。

   • まだテスターを開発チームに入れていない場合は、開発者との継続的なフィードバックループがあります。
   • 頻繁にテストを展開するため、常に新しい/修正済みのテストがあります。
   • コミュニケーションをより速く、より頻繁にします。たとえば、電子メールスレッドよりもインスタントメッセージングを優先します。
   • テスターが最高のツールを使用できるようにする（高速マシン、複数のモニター、合理化されたバグ追跡など）

   この段階では、テストプロセス自体を（まだ）最適化することではなく、オーバーヘッドを削減することです。テスターの時間を無駄にしないでください。本当に無駄になっている時間をなくすことは、経営陣にとっても簡単なことです。

3. 他のアクティビティを制約に従属させます。

   この時点で、テスターは自分でできる限り生産的であるため、他の領域から生産性を借り始める必要があります。

   • 開発者と運用スタッフに、テスターが何に取り組んでいるかに関係なく、テスターを最優先にするよう指示します。
   • 機能横断型のチームがない場合は、事前に設定した時間に毎日会議室を予約して、テスターが予約するために時間を無駄にしないようにします。
   • 開発者（および場合によっては操作）の時間の一部を機能の作業から遠ざけます。たとえば、バグ修正、技術負債/リファクタリング、コードレビュー、ユニットテストに焦点を当てます。
   • 継続的かつ段階的にテストします-3週間開発しないで、テスト担当者に送ります。足場やプロトタイプUIなどを使用して、コードをすぐにテスト可能にするように開発者に働きかけます。

4. 制約を引き上げます。

   テスターが生産性と最小限のオーバーヘッドの両方で全能力で作業しており、それでもまだ十分に速くない場合、テストにもっと投資する必要があります。

   • 手動のテスト展開に依存している場合は、継続的な統合および構成管理スクリプトを使用して自動展開します。
   • テスト計画の作成に時間がかかる場合は、より良い受け入れ基準（つまりINVEST）の取得に取り組んでください。ほとんどの組織は、最初はこれが非常に悪いです。
   • 受け入れテストに時間がかかりすぎる場合は、自動化を開始してください。CucumberやFitNesseなどのツールを使用するか、必要に応じてxUnitタイプのテストを作成します。UIテストに時間がかかる場合は、Selenium、Watij、およびその他のブラウザー自動化ツールもあります。
   • 回帰テストに時間がかかりすぎる場合は、それも自動化します。それは自動化することができない場合は、ゲートの外の質の向上に焦点を当て、すなわち等の一層のコードレビューに重点を置いて、単体テスト、静的解析ツール、と開発者は非常に少ない実際があることをかなり確信する必要があるバグがそれを渡す前にQAへ（製品の欠陥は別の話です）。
   • 探索的テストがボトルネックである場合、リリース後までその一部を延期するか、テスト会社に委託して、複数のブラウザーで同じワークフローをテストするなどの高度に並列化できることを行うことができます。
   • テスターが多くのバグを再現できない場合は、容量テスト環境を構築して、断続的なエラーの再現を開始できるようにすることを検討してください。または、自動受け入れテストを1日中並行して継続的に実行し、詳細なログを記録してみてください。
   • バグの修正に時間がかかりすぎる場合は、プロジェクトのパーティション分割を開始するか、ソリューションの再構築を真剣に検討してください。または、代わりに、それらの一部を修正しないでください。すべてのバグが重要であるとは限らないため、機能の作業と並行して優先順位を付けることができます。
   • 他のすべてが失敗した場合、より多くのテスターを雇います。

5. 手順1に戻ります。

これはすべて常識であると言いたいのですが、残念ながら、少なくともほとんどの組織ではそうではありません。経営陣から多くの抵抗を受けている場合、価値のある手法はバリューストリームマッピング（リーンマニュファクチャリングからの手法）です。次のステージに移動します。機会費用は理解するのが難しいですが、これは私がそれを視覚化して実証するために見つけた最良の方法の1つです。

そして、もしそれでもうまくいかないなら...多分あなたは機能不全の会社にいるのかもしれません、手遅れになる前に出てください！

しかし、マネージャーの机に数枚の書類を落とし、問題に対してお金を投げるように頼むだけでは、この問題を解決することはできません。ひどい。ソリューションを提供する必要があります。それがこの答えです。「より多くのテスターが必要です」ではなく、「コスト/ベネフィットの降順でこの問題の解決を開始できる方法のリスト」として問題を紹介すると、より多くの成功を収めることができます。

29ページと30ページには、探しているデータが含まれている場合がありますが、フォローアップが必要な場合があります。

30ページのこの文で言及されている調査を検討します。

数十社の企業が、プロジェクトの後半ではなく早期に欠陥の修正に集中するだけで、開発コストとスケジュールを2倍以上削減できることを発見しました（McConnell 2004）。

ところで、それは私がそれをリフレッシュするために再び本を拾わせたあなたの質問でした:-)

説明しているのは、プロセスのボトルネックです。リーン理論によれば、プロセスには常にボトルネックが存在しますが、その重大度は大きく異なる可能性があります。QAが1人余分に雇用した場合、開発がボトルネックになる可能性があります。

コストを理解するには、次の状況を想像してください。開発者の1人を選びました。彼の作品は品質保証されることはありませんが、常に無期限にキューに入れられます。これは、QAが他の開発者の作業をタイムリーに品質保証でき、遅延のコストがないことを意味すると想像してください。

そのシナリオでは、遅延のコストは、開発者の仕事が無駄になるため、開発者の給与のコストです。

プロセスによって生み出される価値ではなくコストの観点から私が主張する理由は、プロセスの価値を文書化することは、たとえそれがはるかに優れているとしても、それが難しいからです。

私はCode Completeのコピーをめくり続け、欠陥を修正するコストが存在するほど指数関数的に増加することを示す「ハードデータ」スニペットを探します。誰かがこの概念を裏付けるいくつかの研究を教えてくれますか？

バグを見つけるための指数コストは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によって、元の質問に戻って、本当にTestを意味すると仮定します。Code Completeが正しかった-欠陥のコストは、挿入から修正までの時間です。早期発見は、早期に修正する場合にのみ役立ちますが、ほとんどの人の解釈は間違っています。

（注：私はここでデビルズの擁護者を演じていますが、文字通りあなたの状況を何も知らないのでこれを受け取らないでください）あなたのテスト部門による遅延の原因はコストですが、絶対に、あなたがいる場合、私は尋ねなければなりません彼らがあなたの欠陥を見つけるのを待っている、あなたは何をしている-あなたはあなた自身の欠陥を見つけてはいけない？おそらく、彼らからの仕事が少ない場合（あなたからの欠陥が少なく、高品質の入力を介して）、遅延はそれほど重要ではなく、コストも少なくなります-マネージャーとして、あなたが配信するコードの欠陥をどのように減らす計画を立てますか（あなたの議論に基づいて）テストし、自分でテストして発見した場合、これらの欠陥はよりコストがかかります。

また、あなたのマネージャーとして、私はテストではないがあなたの欠陥を見つける仕事であると述べるかもしれません、彼らの仕事は欠陥がないことを見つけることです-あなたが欠陥を見つけることを期待しているなら、あなたは十分にあなたの仕事をしていないかもしれません。

これにどうアプローチするかに注意してください。あなたが問題の解決策を持っていない場合、あなたは二番目に良いはずです。