What We Can Learn from Google about Software Testing
Google is one of the giant tech companies in the world. Today people can hardly imagine their lives without searching for something on Google or just watching some fun or informative videos on YouTube. Most of us could have thought about how Google manages to deliver so many features and meets the expectations of millions of users who use their products every single day. When any of the Google products go down, social media starts booming, and the work of millions of people just stops. You might also think that Google holds an army of software testers to accomplish such a huge amount of work daily.
But it turns out that the reality is quite the opposite.
There is a book authored by James Whittaker, Jason Arbon and Jeff Carollo called How Google Tests Software that helped me understand the testing mindset at Google.
First of all, software testers are pretty scarce at Google. And it is the scarcity of resources that forms the base of their secret sauce. Scarcity of resources creates a strong sense of ownership by those on a project and forces them to prioritize and optimize. Engineers become quick to see process inefficiencies and not repeat them.
There is no busy work in an attempt to add value where you are not needed.
Secondly, Google stopped treating development and testing as separate disciplines. Testing and development go hand in hand. Testing is considered to be a part of the development process itself. Quality is not equal to testing.
Quality is achieved by putting development and testing into a blender and mixing them until one is indistinguishable from the other.
Software Engineers (SWEs) at Google own features and the quality of those features. They spend most of their time designing documentation, overall software architecture, writing and reviewing code.
Software Engineers in Test (SETs) are also developers who build testing features and are responsible for testability and general test infrastructure. SETs write unit testing frameworks and automation that enable SWEs to test their features. Most of the feature testing is performed by the SWEs. SETs ensure that features are testable and that the SWEs are actively involved in testing. They make developers more productive and more quality-minded.
At Google, a test is just another feature of the application, and SETs are the owner of the testing feature. Tests are always expected to pass and when they fail, bugs are raised against the tests that must be fixed. This ensures that new functionality does not break existing ones and that any code changes do not break any tests. SETs are also actively involved in reviewing code written by SWEs.
Google takes code reviews seriously. Engineers must have their code reviewed by someone who has a “readability” in the relevant programming language. A developer can be granted readability after establishing a good track record for writing clean code in a particular programming language.
User-focused testing is the job of Google Test Engineers (TEs). TEs are product experts and risk analyzers. At Google, not all products receive the attention of a TE. Experimental and early-stage products without a well-defined mission certainly do not get any TE attention and should be tested by the people writing the code. If TEs are engaged, they mostly focus on exploratory testing, the weak points of the software, security, performance, reliability, usability, compatibility, globalization, or other concerns. TEs are great negotiators, creative, and able to deal with ambiguity. They also coordinate the work among contract testers, crowd-sourced testers, dog fooders, beta users.
At Google, the goal for any individual engineer should be to create impact. Google also encourages the innovativeness and creativity of the engineers. One of the key ways they do that is facilitating the movement of testers from project to project, which keeps them fresh and engaged and ensures that good ideas move rapidly around the company. Googlers can also take a day a week (20 percent of their time) to experiment and work on something besides their day job. Many of the tools at Google are the result of 20 percent efforts that eventually turned into real, funded products, such as GTA (Google Test Analytics), BITE (Browser Integrated Testing Environment), Google Bots, etc.
And finally, Google engineers give great importance to automation. They believe that
… human intelligence is too valuable to waste on something a computer can do and should be applied where intelligence and human judgment are best; a repetitive task is definitely not one of those areas.
Even though the testing approach described in the book dates back to 2010 or 2011 and could have transformed hugely since then, I personally find that most of the ideas can still be applied to the current companies. I highly recommend reading the book to learn more about how Google interviews testers, organizes testing activities, how engineers write and execute tests, and so on.
Thank you that you are still here! Feel free to share your thoughts in the comments.
