大多数开发人员都知道吃自己的狗粮的想法，但同时在数学上证明了让QA员工（或测试人员）做QA比开发人员做QA更便宜。
当然，在任何一个方向都没有任何极端主义者，但我注意到，取决于项目和开发人员（或QA员工或经理），这种平衡会以某种方式摇摆不定，但我我很好奇在确定每个阵营应该做多少QA时应该采用什么样的好经验法则。
更新：虽然在每种情况下都不是数学上的，但Joel的article on QA should足够清楚，他实际上也有one of dogfood：）
答案 0 :(得分：9)
我几乎同意Garry的回答 - 除了他声称这与提高代码质量无关。我认为绝对 与此相关，以及他在第一段中提及的可用性。
如果你有一个广泛的狗食，你会得到：
我肯定已经修复了很多次在dogfooding中发现的错误，其中情况尚未经过QA测试。在许多情况下，你真的无法测试所有可能性，但是dogfooding有助于测试更多。
让尽可能多的人去吃狗食（当然，对潜在的问题设定了适当的期望）。它当然不应该是“仅限开发人员”的东西（当然，除非你正在构建一个仅限开发人员的产品）。这并没有带走质量保证的宝贵工作 - 它增加了它。
它依赖于大量你正在开发的东西。我一直在一家公司，员工在日常生活中永远不会有任何理由使用该产品，因此狗狗食物并不可行。在另一家公司，我们正在构建一个Web代理，因此有必要让公司的大部分人来浏览代理。我最近一直致力于针对消费者的同步产品，所以再次对狗食进行广泛宣传。
答案 1 :(得分：7)
Dogfooding根本不是QA。这是关于使用您自己开发的产品，以便您可以看到工作流程中的哪些内容可以改进，并且通常会感受到使用软件的痛点。
这不是关于提高代码质量，而是关于使您的软件更易于使用，并指导您选择功能开发。
答案 2 :(得分：4)
正式与非正式
使用您自己的产品（“吃你的狗的食物”）是质量保证的一部分，我会将其置于非正式测试类别，而不是通常由单独的质量保证部门进行的更正式的测试。
深度与广度
“吃你的狗的食物”旨在为直接负责其设计和开发的人提供使用产品或服务的第一手经验。对于功能丰富的应用程序，它可能比正式测试更深入，同时提出特定的用户观点，当正式测试通常涵盖广泛的软件用例并尝试以更客观和可衡量的术语操作时。
产生差异的小烦恼
还有一类缺点非常特定于一个只能在“现场”诊断出来的环境（就像这种非常讨厌的嘎嘎声，无论何时你以72.52mph的速度巡航并驱使你绝对坚果，但当汽车停在车库时，没有一个机械师能够，也不愿意接受这个原因。）
Naked Software vs. Application + Set of Practices
使用您自己的产品远远超出了软件本身;它不可避免地包含了整个“用户之旅”。 “吃你的狗粮”让我们可以开发并更好地理解在域内使用软件的技术。可以说，某些软件在许多不同的环境中使用。正式测试可能无法深入涵盖这些上下文中的每一个，仅仅因为可能很难正式定义一旦发生变化需要执行哪些特定测试。或者，在内部模仿这些上下文或者每次软件稍有变化时都要经历所有已知的测试用例可能过于昂贵。
内部变更与外部
正式测试非常擅长检查对软件所做的更改是否有效，但正式测试正在挣扎的另一个重要的发展领域是当您需要检测软件环境中的变化或来自外部世界。使用您自己的产品有助于更快地检测到这些变化，可能在用户告知之前（取决于用户反馈渠道的质量）。
“平衡”有什么不对？
因此，在使用您自己的产品和正式测试之间没有任何平衡（尽可能多地做两件事，即您获得的回报值得付出努力）。一个是赞美另一个，而不是作为替代品。
谁应该做测试：区别
除非没有专门的资源进行正式测试（独立开发人员，开发人员进行所有测试），否则您必须选择将多少时间用于这两项活动。好吧，不要。这里的重要区别是，正式测试最好由独立机构完成，即不向开发和设计团队报告的人员。另一方面，每个人（设计师，开发人员，营销人员甚至CEO）都应该尽可能地使用公司产品或服务，因为“dogfooding”背后的核心理念是为每个人提供服务或产品的第一手体验。它们在现实生活中有所贡献。
你不能Dogfood一切！或者你可以吗？
至于“你不能食用某些类型的软件”的论点，好吧，不要把注意力集中在狗狗食物的外观上：吃狗狗的食物，而是思考而不是意味着什么：获得第一手经验与这些实际用户“协调利益”。
自己吃食物的另一个最好的事情就是观察狗吃食物的时间，而不是依赖别人告诉你狗，你认为喜欢或不喜欢的狗。
虽然开发团队成员可能无法亲自将污水控制软件用于他们的日常工作，但没有什么能阻止他们花一些时间定期观察污水工程师使用该应用程序，这不遵循“dogfooding”的字母“但是肯定能抓住它的精神。
答案 3 :(得分：4)
我完全同意Jon的回答，附录中的狗食测试即使对于质量保证也很重要，而且往往没有完成。我不止一次开始使用QA的其他部分（有时甚至是我自己）已经完成测试的产品，并且在正常使用中发现了不合情理的错误。有时，正如Joel on Software文章所指出的那样，测试结果不佳;对于教程失败的第一个例子（例如Deja Gnu）来说，这是非常常见的。但更常见的是，因为狗狗食物是一个与系统测试完全不同的过程：你没有做你被告知要做的事情，当你不尝试时，你正在做你实际做的事情发现错误。
一个非常非常好的测试计划可能会涵盖其中一些案例，但在我自己公司最尴尬的例子中，测试计划是问题的一部分：一个显着的选项，大多数核心开发人员都会确定需要，是正式不受支持的，因此未经测试，但仍然是必要的。我认为更合理的功能需求定义不会产生错误;如果您知道任何公司的FRD总是完全合理且正在招聘，请告诉我： - ）
答案 4 :(得分：2)
通常将两种角色描述为“QA”。
质量保证 - 确保质量计划正在执行的人员。
测试人员 - 不编码的开发人员。
如果您的问题集中在“确保质量计划正在执行”，那么很容易：开发人员做工作符合质量计划和QA审核，质量计划得到遵循。
由于您的问题主要集中在“不编码的开发人员”上，因此您首先没有太多的质量计划。在这种情况下，开发人员需要（1）将测试人员整合到他们的队伍中，（2）创建质量计划，以及（3）根据该计划开展工作。
该计划可能涉及一些独立测试。这可以通过让开发人员A为开发人员B编写测试来完成。也可以通过让开发人员A编写测试并在开始编码之前对这些测试进行同行评审来完成。
这个想法是开发人员编写并检查和测试他们自己的代码。一个发展组织。每个人都有代码 - 比其他代码更多。
QA确保开发人员确实始终如一地完成这项工作。
我不认为“不编码的开发人员”是一份可行的工作。这些都是初级开发人员。您可以利用它们来增加一些额外的技术技能;或者将他们浪费在他们花费相当多的时间被用户殴打并与开发者争论的位置。
利用“不编码的开发人员”的一种方法是开始编写测试;然后用它们来修复损坏的代码;然后从别人的设计代码;然后自己做设计工作。
有许多方法可以阻止这些“不编码的开发人员”。一个是让他们猜测用户的意思。通过将他们对流程的了解缩小到他们在业务分析文档中找到的内容来做到这一点。另一个是将他们放在一个他们不得不与开发人员争论商业分析文件解释的位置。
答案 5 :(得分：2)
我相信你能想出一个关于节省成本的等式，但这可能是时间点。开发人员在实际应该总是“吃自己的狗食”（为什么开发人员会为他人创建一个IDE而不是自己使用它？） - 但他们应该在某种程度上参与基础QA活动。我去过很多公司，开发人员在墙上抛出代码（'I crap gold syndrome'） - 导致一个又一个循环的错误代码被测试，而不是完全修复并再次测试。
经理应确定每个小组的测试级别，并随着时间的推移调整/调整每个人的具体情况。交付代码的时间越差，测试（TDD）的时间越多，应该花费更多时间来改进开发人员。
答案 6 :(得分：1)
一般来说，DogFooding并不是那么有用，除非您正在开发开发人员也需要使用的开发人员工具。
在我工作的地方，我们使用自己的产品，但不像我们的客户那么广泛。由于我们的客户不从事软件开发业务。
答案 7 :(得分：1)
如果您每天都在构建可供员工使用的东西，Dogfooding是一个很好的解决方案，但不幸的是，我不认为这对每个应用程序都是可行的。如果您正在编写即时消息客户端，那么狗狗食物很容易。如果您为污水处理厂编写控制系统，那么可能不会。
QA是关于您的软件的专业质量控制。我认为您是否需要它的决定完全取决于被测系统的复杂性和失败成本。制造业有一个（可能过于简单的）类比。我可能会买一支没有通过质量控制部门的铅笔，但我绝对不会在没有飞机的情况下买票。