Google’s Test-Driven Development Process

Google has innovated a testing strategy that is different than the traditional testing approach seen at other companies. This new approach comes with benefits and drawbacks that need to be managed in order to effectively incorporate the testing methodologies in an organization. While Google’s approach to testing/quality can be replicated in other organizations, it may be smart to review an organization’s culture while implementing a strategy to improve software quality.

Google has a variety of differences from a traditional software organization, but the three I find most important are:

  1. They treat development and testing as the same discipline. Both of which are focused on engineering quality into software from the ground up.
  2. They divide their software developers into three distinct roles, each of which have equal development skillsets: Software Engineers (SWEs), Software Engineers in Test (SETs), and Test Engineers (TEs).
  3. And their organizational structure prioritizes testing by having a separate testing organization within Google that loans SET and TE resources to product development groups.

Quality is not the same as testing (Whittaker, Arbon, & Carollo, 2012). Google uses this mentality along with test-driven development to engineer quality software as free from defects as possible which is one of the benefits of their process. Software Developers writing their own tests ensure that the people that know the code are the ones to debug it while they are adding features. It falls on the Test Engineers to ensure that not only the features work at a high level (an end user level) but also that the features fulfill the needs of a client. Having a separate testing organization within Google helps not only ensure that the Test Engineers have a depth of knowledge across the company’s software portfolio but it helps remove the information silos. For example, a Test Engineer that works on that works on Google Chrome may transfer to the YouTube team and share their experiences and best practices with the new team so they can adopt new processes and improve their continuous integration process.

Downfalls of Google’s approach to testing include losing quality Test Engineers to other software projects in the organization. Losing a team member that provides a certain level of product knowledge could potentially cause an impact on the product. Another risk of Google’s using approach is in the implementation of the process itself. An organization needs to have quality as a key focus from C-level management down, otherwise any issues that come with change within the organization (changing daily duties, changing HR’s perception of the testing role in the organization and raise their compensation to match Software Engineers, ect). This is reminiscent of what Patrick Copeland’s struggle to implement change to his feature developer and testing teams receiving push-back from the engineers who had their own personal concerns with changes to the day-to-day operations (Whittaker, Arbon, & Carollo, 2012). He was able to overcome the challenge in order to develop Google’s current testing practices that student’s study to this day.

While Google’s exact testing approach can be copied to other organizations it is important to remember that not every organization is the same. It is likely a better strategy to learn Google’s process and how to best incorporate certain features of their approach to one’s own organization.

Works Cited

Whittaker, J., Arbon, J., & Carollo, J. (2012). How Google Tests Software. Upper Saddle River, NJ, USA: Addison-Wesley.