Friday, January 03, 2014

The Google Test and Development Environment - Pt. 2: Dogfooding and Office Software

by Anthony Vallone

This is the second in a series of articles about our work environment. See the first.

There are few things as frustrating as getting hampered in your work by a bug in a product you depend on. What if it’s a product developed by your company? Do you report/fix the issue or just work around it and hope it’ll go away soon? In this article, I’ll cover how and why Google dogfoods its own products.


Google makes heavy use of its own products. We have a large ecosystem of development/office tools and use them for nearly everything we do. Because we use them on a daily basis, we can dogfood releases company-wide before launching to the public. These dogfood versions often have features unavailable to the public but may be less stable. Instability is exactly what you want in your tools, right? Or, would you rather that frustration be passed on to your company’s customers? Of course not!

Dogfooding is an important part of our test process. Test teams do their best to find problems before dogfooding, but we all know that testing is never perfect. We often get dogfood bug reports for edge and corner cases not initially covered by testing. We also get many comments about overall product quality and usability. This internal feedback has, on many occasions, changed product design.

Not surprisingly, test-focused engineers often have a lot to say during the dogfood phase. I don’t think there is a single public-facing product that I have not reported bugs on. I really appreciate the fact that I can provide feedback on so many products before release.

Interested in helping to test Google products? Many of our products have feedback links built-in. Some also have Beta releases available. For example, you can start using Chrome Beta and help us file bugs.

Office software

From system design documents, to test plans, to discussions about beer brewing techniques, our products are used internally. A company’s choice of office tools can have a big impact on productivity, and it is fortunate for Google that we have such a comprehensive suite. The tools have a consistently simple UI (no manual required), perform very well, encourage collaboration, and auto-save in the cloud. Now that I am used to these tools, I would certainly have a hard time going back to the tools of previous companies I have worked. I’m sure I would forget to click the save buttons for years to come.

Examples of frequently used tools by engineers:
  • Google Drive Apps (Docs, Sheets, Slides, etc.) are used for design documents, test plans, project data, data analysis, presentations, and more.
  • Gmail and Hangouts are used for email and chat.
  • Google Calendar is used to schedule all meetings, reserve conference rooms, and setup video conferencing using Hangouts.
  • Google Maps is used to map office floors.
  • Google Groups are used for email lists.
  • Google Sites are used to host team pages, engineering docs, and more.
  • Google App Engine hosts many corporate, development, and test apps.
  • Chrome is our primary browser on all platforms.
  • Google+ is used for organizing internal communities on topics such as food or C++, and for socializing.


We are interested to hear your thoughts on this topic. Do you dogfood your company’s products? Do your office tools help or hinder your productivity? What office software and tools do you find invaluable for your job? Could you use Google Docs/Sheets for large test plans?


  1. Dogfooding helps real world discovery of issues. But it also slants product features and tweaks to Use Cases that are overly specific to technologists as opposed to different use by every day laypeople. There should be broad parallels in use by different audiences in say Google Docs but in for example Google Photos, the Use Cases between in house programmers and the bulk of Photo Enthusiasts might be divergent

  2. Dogfooding vs company centered software?... In some situations I prefer not-G software. How can you be aware of your limitations without contact with "reality"?

  3. Google docs is a very important tool we use for development plans, and document related work. Dogfooding? we are getting there.

  4. I have two questions:
    1. How do you perform Dogfooding when you have product that is not used by internal teams?
    2. What actions QA team takes when the bug is discovered in Dogfooding to prevent such a instances in future?

    1. 1. There are very few Google products that fall in this category, but the short answer is that we don't. We rely on testing, beta users, and public feedback.
      2. When bugs are found during dogfooding, we improve our regular automated/manual test coverage to handle the cases.

  5. Project plan, document, version and bug tracking is important for any software development organizations such as companies, communities and freelance developers.

    Google products you mentioned above, really good and helpful.

    I'm wondering any organization has distributed development teams (managing documents for different development teams/controlling/reporting) is how doing this track process by using Google's tools.

    May be second book's name is "How Google manages a software?" and you could resolve my wonder with given samples in your book :-).

  6. I think dog fooding should be complemented with "cat fooding". That is, using competitors' products. When you are limited to your own products, you might not realize how better the competing products are, at least in some aspects. For example, some fractions of the Windows team at MS should be forced to use OS-X.

  7. I agree. Dog fooding should be complimented with cat fooding.

  8. Hi Anthony,

    Thanks for one more debatable post. Following are the inputs from my end.

    Do you dogfood your company’s products?
    Yes, We do. Before releasing any product it is require to get the views from internal team as well. For example if a company is developing a bug tracking application and they are using third party software for logging application bugs then they will loose customer confidence and at some level they will reduce focus to their application as well. When we DogFood our application and share it for using it we get comments to improve it.

    Do your office tools help or hinder your productivity?
    We divide the application usages from team to team so it does not hinder at any way.

    What office software and tools do you find invaluable for your job?
    We use software from Word processor to project planning from project initialization to finish.

    Could you use Google Docs/Sheets for large test plans?
    Have not tried but using it offline or where the internet access is not available is not a good choice.

  9. I'm really curious to see how teams form at Google. Also, Google seems to have really good cross company/team communication. How does Google communicate good programming/testing practices to everyone? How does cross team pollination happen?

    1. We communicate good practices in many ways:
      - Internal groups where we can ask the experts on topics like C++ or CSS.
      - Testing on the Toilet (some of these are posted externally on this blog)
      - Style guides
      - Test and development guides

  10. In my day job, we use a real requirements management tool to manage test plans and the like: doing it with a spreadsheet and manual tracking just ain't fun, and I would not try doing it with Docs/Drive. But I am delighted to hear that you are using Sites.


The comments you read and contribute here belong only to the person who posted them. We reserve the right to remove off-topic comments.