ほとんどの開発者は、自分のドッグフードを食べるという考えを認識していますが、同時に、開発者に QA をさせるよりも QA スタッフ (またはテスター) に QA をさせる方が安価であることが数学的に証明されています。
もちろん、どちらの方向にも過激派であることには意味がありませんが、プロジェクトと開発者 (または QA スタッフ、またはマネージャー) によって、バランスが何らかの形で変動することに気付きましたが、私は興味があります各キャンプでどれだけの QA を行うべきかを決定する際に適用する、いくつかの優れた経験則は何でしょうか。
更新:すべてのケースで数学的にではありませんが、QA に関する Joel の記事は十分に明確なはずです。彼は実際にドッグフードの 1 つも持っています :)
私は Garry の答えにほぼ同意します - ただし、それはコードの品質を向上させることではないと彼は主張しています。それは絶対にそれと、彼が最初の段落で言及した使いやすさに関係していると思います.
幅広いドッグフードを用意できる場合、次のものが得られます。
私は確かに、ドッグフーディングで見つかったバグを何度も修正しましたが、状況は QA によってテストされていませんでした。多くの場合、すべての可能性を実際にテストすることはできませんが、ドッグフーディングはより多くの可能性をテストするのに役立ちます。
できるだけ多くの人にドッグフードを提供してもらいます (もちろん、潜在的な問題について適切な期待値を設定してください)。それは確かに「開発者のみ」であってはなりません (もちろん、開発者のみの製品を構築している場合を除きます)。これは、QA の貴重な仕事を奪うものではなく、追加するものです。
ただし、開発しているものに大きく依存します。私は、従業員が日常生活で製品を使用する理由がまったくない会社にいたことがあります。そのため、ドッグフーディングは実際には実行可能ではありませんでした。別の会社では、Web プロキシを構築していたので、会社の大部分にプロキシを介してブラウズさせることは理にかなっています。私は最近、消費者を対象とした同期製品に取り組んでいるので、これもまた、広くドッグフードするのが理にかなっています。
ドッグフーディングは QA に関するものではありません。自分で開発している製品を使用して、ワークフローのどこを改善できるかを確認し、ソフトウェアを使用する際の一般的な問題点を感じることができます。
コードの品質を向上させることではなく、ソフトウェアを使いやすくし、機能開発の選択をガイドすることです。
ドッグフード テストは QA でも重要であり、多くの場合行われていないという補足とともに、Jon の回答に完全に同意します。QA の他の部分 (時には私自身でさえも) がテストを終了したと思われる製品を使い始めたことが何度もあり、通常の使用で不本意なバグを発見しました。Joel on Software の記事で指摘されているように、これはテストが不十分なだけの場合もあります。チュートリアルの最初の例が失敗するのは驚くほど一般的です (Deja Gnu など)。しかし、多くの場合、ドッグフーディングは体系的なテストとは非常に異なるプロセスであるためです。指示されたことを行っているのではなく、バグを見つけようとして いないときに実際に行っていることをやっているのです。
非常に優れたテスト計画は、これらのケースのいくつかをカバーする可能性がありますが、私の会社での最も恥ずかしい例では、テスト計画が問題の一部でした。公式にサポートされていないため、テストされていませんが、それでも必要でした. より合理的な機能要件の定義があれば、その間違いは起こらなかったと思います。FRDが常に完全に合理的で、採用している会社を知っている場合は、私に知らせてください:-)
公式対非公式
独自の製品を使用すること (「ドッグフードを食べること」) は品質保証の一部であり、別の QA 部門によって通常行われるより正式なテストとは対照的に、非公式のテスト カテゴリに分類します。
深さと幅
「ドッグフードを食べる」は、製品やサービスの設計と開発に直接責任を負う人々に、製品やサービスの使用を直接体験してもらうことを目的としています。機能が豊富なアプリケーションの場合、正式なテストよりも深くなると同時に、特定のユーザーの視点を入れることができます。正式なテストは通常、幅広いソフトウェアのユースケースをカバーし、より客観的で測定可能な用語で動作しようとします。
違いを生む小さな煩わしさ
また、「現場」でのみ診断できる環境に特有の欠点のカテゴリもあります (たとえば、時速 72.52 マイルでクルージングしているときはいつでもどこからともなく発生するような、本当に迷惑なガタガタ音など)。それでも、車がガレージにあるとき、メカニックは誰も原因に取り掛かることができず、また喜んで取り掛かりません）。
ネイキッド ソフトウェア vs. アプリケーション + プラクティス セット
独自の製品を使用することは、ソフトウェア自体をはるかに超えています。必然的に「ユーザージャーニー」全体が含まれます。「ドッグフードを食べる」ことで、ドメイン内でソフトウェアを使用するテクニックを開発し、理解を深めることができます。一部のソフトウェアは、さまざまな状況で使用されていると言っても過言ではありません。正式なテストでは、これらの各コンテキストを詳細にカバーできない場合があります。これは、何かが変更されたときに実行する必要がある特定のテストを正式に定義するのが難しい場合があるためです。または、これらのコンテキストを社内で模倣したり、ソフトウェアがわずかに変更されるたびにすべての既知のテスト ケースを実行したりするのは、費用がかかりすぎる可能性があります。
内部の変化と外部の変化
正式なテストは、ソフトウェアに加えられた変更が機能することを確認するのに非常に優れていますが、正式なテストが苦労している進化のもう 1 つの重要な領域は、ソフトウェア環境の変化や外界からの使用パターンを検出する必要がある場合です。独自の製品を使用すると、おそらくユーザーから通知される前に、これらの変更をより早く検出するのに役立ちます (ユーザー フィードバック チャネルの品質によって異なります)。
「天秤」の何が悪い？
そのため、独自の製品を使用することと、それを正式にテストすることとの間でバランスを取ることはできません (可能な限り両方を行います。つまり、得られる返品は努力する価値があります)。1 つは、別のものを補完することであり、代わりになることではありません。
誰がテストを行うべきか: 区別
これは、正式なテストを行うための専任のリソース (単独の開発者、すべてのテストを行う開発者) がなく、2 つのアクティビティのいずれかに専念できる時間を選択する必要がある場合を除きます。まあ、しないでください。ここでの重要な相違点は、正式なテストは、独立した機関、つまり開発および設計チームに直属しない人々によって行われるのが最善であるということです。一方、「ドッグフーディング」の背後にある核となる考え方は、関係者全員にサービスや製品を直接体験させることであるため、誰もが (デザイナー、開発者、マーケティング担当者、さらには CEO も) 会社の製品やサービスを可能な限り使用する必要があります。彼らは実際の生活の中で貢献しています。
すべてをドッグフードすることはできません。それともできますか？
「特定の種類のソフトウェアをドッグフードすることはできない」という議論に関する限り、ドッグフーディングがどのように見えるか、つまりドッグフードを食べることに集中するのではなく、それが何を意味するかを考えてみましょう。これらの実際のユーザーの興味」。
自分で食べ物を食べることの次善の策は、犬が何を好きか嫌いかを他の人に頼るのではなく、犬が食べ物を食べている間、犬を観察することです。
開発チームのメンバーは、日常業務で使用するために下水制御ソフトウェアを個人的に配置することはできないかもしれませんが、「ドッグフーディング」の文字に従わない下水道エンジニアがアプリを使用しているのを定期的に観察することに時間を費やすことを止めるものは何もありませんが、確かにその精神を捉えます。
コスト削減の方程式を思いつくことができると確信していますが、それはある時点でのことです。開発者は、実用的な場合は常に「自分のドッグフードを食べる」必要があります（開発者が他の人のためにIDEを作成し、それを自分で使用しないのはなぜですか？）-しかし、開発者は常に基本的なQA活動にある程度関与する必要があります。私は、開発者が壁を越えてコードを投げる（「I crap gold症候群」）多くの企業に行ってきました-悪いコードがテストされ、完全に修正されて再度テストされるのではなく、サイクルが繰り返されます。
管理者は、各グループが実施するテストのレベルを決定し、時間の経過とともに、関係する各人に固有の調整/調整を行う必要があります。配信されるコードが最悪の場合、開発者の改善を維持するために、テスト（TDD）に多くの時間を費やす必要があります。
一般に「QA」と呼ばれる 2 つの役割があります。
品質保証 -- 品質計画が実行されていることを保証する人々。
テスター -- コードを書かない開発者。
あなたの質問が「品質計画が実行されていることを保証する」ことに焦点を当てていた場合、それは簡単です。開発者は品質計画を満たす作業を行い、品質計画が守られていることを QA 監査します。
あなたの質問は「コーディングしない開発者」に焦点を当てているため、そもそも品質計画があまりありません。この場合、開発者は (1) テスターを自分のランクに統合し、(2) 品質計画を作成し、(3) その計画に従って作業する必要があります。
計画には、いくつかの独立したテストが含まれる場合があります。これは、開発者 A が開発者 B のためにテストを作成することによって実行できます。また、開発者 A がテストを作成し、コーディングを開始する前にそれらのテストをピア レビューすることによって実行することもできます。
アイデアは、開発者が自分のコードを書き、チェックし、テストするというものです。1 つの開発組織。誰もがコーディングします -- 一部は他のものよりも多くなります。
QA は、開発者が実際にそれを一貫して完全に行っていることを確認します。
「コードを書かない開発者」は、生きていける仕事とは思えません。これらは本当にジュニアレベルの開発者です。それらを活用して、追加の技術スキルを伸ばすことができます。または、ユーザーに打ち負かされたり、開発者と議論したりするためにかなりの時間を費やす立場で彼らを浪費します。
「コードを書かない開発者」を活用する 1 つの方法は、テストを書き始めることです。次に、それらを使用して壊れたコードを修正します。次に、他の誰かの設計からコードを作成します。その後、自分で設計作業を行います。
これらの「コードを書かない開発者」を思いとどまらせる方法はたくさんあります。1 つは、ユーザーが何を言おうとしているのかを彼らに推測させることです。これを行うには、プロセスに関する知識を、ビジネス分析ドキュメントで見つけたものだけに絞り込みます。もう 1 つは、ビジネス分析ドキュメントの解釈について開発者と議論しなければならない立場に置くことです。
一般に、DogFoodingは、開発者としても使用する必要のある開発者ツールを開発している場合を除いて、それほど有用ではありません。
私が働いている場所では、自社製品を使用していますが、顧客ほど広範囲には使用していません。私たちの顧客はソフトウェア開発のビジネスではないので。
ドッグフーディングは、スタッフが日常的に使用できるものを構築する場合に適したソリューションですが、残念ながら、すべてのアプリケーションで実行できるとは限りません。インスタントメッセージングクライアントを作成している場合、ドッグフーディングは簡単です。下水処理プラントの制御システムを作成する場合は、そうではないかもしれません。
QAは、ソフトウェアの専門的な品質管理に関するものです。必要かどうかの判断は、複雑さと障害のコストの観点から、テスト対象のシステムに完全に依存していると思います。製造業には（おそらく過度に単純化された）類似点があります。品質管理部門を通過していない鉛筆を購入するかもしれませんが、通過していない飛行機のチケットを購入することは絶対にありません。