testing - 在 Dogfood 和 QA 之间取得平衡的技巧？

Question

大多数开发人员都知道吃自己的狗粮的想法，但同时从数学上证明，让 QA 人员（或测试人员）进行 QA 比让开发人员进行 QA 更便宜。

现在当然在任何一个方向上都没有必要成为极端主义者，但我注意到，取决于项目和开发人员（或 QA 人员或经理），平衡会以一种或另一种方式摇摆，但我很好奇在确定每个营地应该进行多少质量检查时，有哪些好的经验法则可以应用。

更新：虽然不是在每种情况下都在数学上，但乔尔关于 QA 的文章应该足够清楚，他实际上也有一个 dogfood :)

Answer 1

我几乎同意 Garry 的回答——除了他声称这与提高代码质量无关。我认为这绝对与此有关，以及他在第一段中提到的可用性。

如果你能吃到广泛的狗粮，你会得到：

• 比 QA 可能使用的更真实的数据（假设它是真实数据！）
• 纯粹的数字力量比 QA 可能使用的数据范围更广

我当然已经修复了很多次在 dogfooding 中发现的错误，而这种情况还没有经过 QA 测试。在许多情况下，您确实无法测试所有可能性，但 dogfooding 有助于测试更多。

让尽可能多的人接受狗粮（当然，对潜在问题设定适当的期望）。它当然不应该是“仅限开发人员”的事情（当然，除非您正在构建仅限开发人员的产品）。这并没有带走 QA 的宝贵工作——它增加了它。

不过，这在很大程度上取决于您正在开发的内容。我曾在一家公司工作，那里的员工永远不会有任何理由在日常生活中使用该产品，所以 dogfooding 并不可行。在另一家公司，我们正在构建一个 Web 代理，因此让公司的大部分人通过代理进行浏览是有意义的。我最近一直在研究针对消费者的同步产品，所以再次广泛地进行 dogfood 测试是有意义的。

Answer 2

Dogfooding 根本与 QA 无关。这是关于使用您自己开发的产品，以便您可以看到工作流程中可以改进的地方，并总体上感受到使用软件的痛点。

它不是为了提高代码的质量，而是为了让您的软件更易于使用并指导您选择功能开发。

Answer 3

正式与非正式

使用你自己的产品（“吃你的狗粮”）是质量保证的一部分，我会将其归为非正式测试类别，而不是通常由单独的 QA 部门进行的更正式的测试。

深度与广度

“吃你的狗粮”旨在为直接负责其设计和开发的人员提供使用产品或服务的第一手体验。对于功能丰富的应用程序，它可能会比正式测试更深入，同时考虑到特定的用户视角，当正式测试通常涵盖软件用例的广度并尝试以更客观和可衡量的术语运行时。

带来改变的小烦恼

还有一类非常特定于环境的缺点，只能在“现场”诊断（就像这种非常烦人的嘎嘎声，每当你以 72.52 英里/小时的速度巡航时，它似乎无处不在，让你绝对发疯，然而，当汽车停在车库时，没有一个机械师能够，也不愿意深入了解原因）。

裸软件与应用程序 + 实践集

使用自己的产品远远超出了软件本身；它不可避免地包含了整个“用户旅程”。“吃你的狗粮”让我们开发和更好地理解在一个领域内使用软件的技术。可以公平地说，某些软件在许多不同的环境中使用。正式测试可能无法深入涵盖这些上下文中的每一个，这仅仅是因为可能难以正式定义一旦发生变化后您需要执行哪些特定测试。或者，每次软件发生轻微变化时，在内部模拟这些上下文或遍历所有已知的测试用例可能太昂贵了。

内部变化与外部

正式测试确实擅长检查对软件所做的更改是否有效，但是正式测试正在努力的另一个重要进化领域是当您需要检测来自外部世界的软件环境或使用模式的变化时。使用您自己的产品将有助于更快地检测到这些变化，可能在用户告诉您之前（取决于用户反馈渠道的质量）。

“平衡”有什么问题？

因此，在使用你自己的产品和正式测试它之间没有平衡（尽可能多地做这两者，即你得到的回报是值得的）。一个是赞美另一个，而不是作为替代品。

谁应该做测试：区别

除非没有专门的资源来进行正式测试（单独的开发人员，开发人员进行所有测试），并且您必须选择可以将多少时间用于这两项活动中的任何一项。好吧，不要。这里的重要区别是，正式测试最好由独立的权威机构完成，即不向开发和设计团队报告的人。另一方面，每个人（设计师、开发人员、营销人员甚至 CEO）都应该尽可能多地使用公司的产品或服务，因为“dogfooding”背后的核心理念是让每个参与其中的人都能获得第一手的服务或产品体验他们在现实生活中做出了贡献。

你不能对所有东西都进行狗粮！或者你可以吗？

至于“你不能 dogfood 某些类型的软件”的论点，好吧，让我们不要专注于 dogfooding 的样子：吃你的狗粮，而是想想它的含义：获得第一手经验和“对齐”与这些实际用户的兴趣”。

自己吃食物的下一个最好的事情是在狗吃食物的同时观察它，而不是依靠别人告诉你你的狗喜欢或不喜欢什么。

虽然开发团队成员可能无法亲自将污水控制软件用于他们的日常工作，但没有什么能阻止他们花一些时间定期观察使用该应用程序的污水工程师，这不符合“dogfooding”的字母，但是当然抓住了它的精神。

Answer 4

我完全同意 Jon 的回答，补充说 dogfood 测试即使对于 QA 也很重要，而且通常没有完成。我不止一次开始使用一个产品，QA 的其他部分（有时甚至是我自己——哎呀）据说已经完成了测试，并且在正常使用中发现了不合理的错误。有时，正如 Joel on Software 文章所指出的，这只是糟糕的测试；教程中的第一个示例失败（例如 Deja Gnu）非常常见。但更多时候是因为 dogfooding 与系统测试是一个非常不同的过程：你不是在做你被告知要做的事情，而是在你不试图寻找错误时做你实际做的事情。

A very, very good test plan might cover some of those cases, but in the most embarrassing example in my own company, the test plan was part of the problem: A conspicuous option, which most hard-core developers would be certain to need, was officially unsupported, and hence untested, but necessary nonetheless. I suppose a more reasonable functional requirements definition wouldn’t have made that mistake; if you know of any company whose FRD’s are always entirely reasonable and which is hiring, do let me know :-)

Answer 5

有两个角色通常被描述为“QA”。

• 质量保证——保证质量计划正在执行的人。

• 测试人员——不编码的开发人员。

如果您的问题集中在“确保质量计划正在执行”上，那么这很容易：开发人员进行符合质量计划的工作，并且 QA 审核质量计划是否得到遵循。

由于您的问题集中在“不编码的开发人员”上，那么您首先没有太多的质量计划。在这种情况下，开发人员需要 (1) 将测试人员整合到他们的队伍中，(2) 创建质量计划，以及 (3) 根据该计划工作。

该计划可能涉及一些独立的测试。这可以通过让开发人员 A 为开发人员 B 编写测试来完成。也可以通过让开发人员 A 编写测试并在开始编码之前对这些测试进行同行评审来完成。

这个想法是开发人员编写、检查和测试他们自己的代码。一个开发组织。每个人都在编码——有些人比其他人多。

QA 确保开发人员确实始终如一且完全地做到这一点。

我不认为“不编码的开发人员”是一项可行的工作。这些是真正的初级开发人员。您可以利用它们来增加一些额外的技术技能；或者将他们浪费在他们花费大量时间被用户殴打并与开发人员争论的位置上。

利用“不编码的开发人员”的一种方法是让他们开始编写测试；然后使用它们来修复损坏的代码；然后从别人的设计中编码；然后自己做设计工作。

有很多方法可以阻止这些“不会编码的开发人员”。一是让他们猜测用户的意思。通过将他们对流程的知识缩小到他们在业务分析文档中找到的内容来做到这一点。另一个是让他们不得不与开发人员就业务分析文档的解释进行争论。

Answer 6

我相信你可以想出一个节省成本的方程式，但这只是时间点。开发人员应该在实际情况下始终“吃自己的狗粮”（为什么开发人员要为其他人创建 IDE 而自己不使用它？？？） - 但他们应该始终在某种程度上参与基础 QA 活动。我去过许多公司，那里的开发人员将代码扔到墙上（“我废话黄金综合症”） - 导致一个又一个循环的错误代码被测试，没有完全修复并再次测试。

经理应确定每个小组所做的测试水平，并随着时间的推移和每个相关人员的具体情况进行调整/调整。交付的代码越糟糕，测试 (TDD) 的时间就越多，应该花在改进开发人员上。

Answer 7

一般来说，DogFooding 没有那么有用，除非您碰巧正在开发作为开发人员也需要使用的开发人员工具。

在我工作的地方，我们确实使用我们自己的产品，但不像我们的客户那样广泛使用。由于我们的客户不从事软件开发业务。

Answer 8

如果您要构建员工每天都可以使用的东西，Dogfooding 是一个很好的解决方案，但不幸的是，我认为这对每个应用程序都是可行的。如果您正在编写即时消息客户端，那么 dogfooding 很容易。如果您为污水处理厂编写控制系统，那么可能不会。

QA 是关于软件的专业质量控制。我认为是否需要它的决定完全取决于被测系统的复杂性和故障成本。与制造业有一个（可能过于简单化）的类比。我可能会买一支没有通过质量控制部门的铅笔，但我绝对不会买没有通过质量控制部门的机票。