What do you think?
Rate this book
How Google Tests Software
2012 Jolt Award finalist! Pioneering the Future of Software Test Do you need to get it right, too? Then, learn from Google . Legendary testing expert James Whittaker, until recently a Google testing leader, and two top Google experts reveal exactly how Google tests software, offering brand-new best practices you can use even if you’re not quite Google’s size… yet! Breakthrough Techniques You Can Actually Use Discover 100% practical, amazingly scalable techniques for analyzing risk and planning tests…thinking like real users…implementing exploratory, black box, white box, and acceptance testing…getting usable feedback…tracking issues…choosing and creating tools…testing “Docs & Mocks,” interfaces, classes, modules, libraries, binaries, services, and infrastructure…reviewing code and refactoring…using test hooks, presubmit scripts, queues, continuous builds, and more. With these techniques, you can transform testing from a bottleneck into an accelerator –and make your whole organization more productive!
320 pages, Paperback
First published January 1, 2012
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 87 reviews
February 3, 2017
When I found out about the book "How Google Tests Software", it didn't take long until I had ordered a copy. I find it quite fascinating to read about how Google does things, whether it is about their development process, their infrastructure, their hiring process, or, in this case, how they test their software. I am a developer at heart, but I have worked for a few years as a tester, so testing is also dear to me.
It's quite an interesting book, and it makes some great points about the future of testing. However, despite the phrase "Help me test like Google" on the cover, it is not as useful as I had hoped when it comes to improving your own testing.The book starts off by describing the key roles at Google: SWE (Software Engineer), SET (Software Engineer in Test) and TE (Test Engineer). Briefly, the SWE builds features for Google's products, the SET develops testing infrastructure and larger-scale automatic tests, and the TE tests the products from a user's perspective. After the introductory chapter, there is a chapter each on the SET and TE roles, and there is also a chapter on the TEM (Test Engineer Manager) role. The final chapter is about the future of testing at Google (and in general).
Software Engineer in Test (SET)
As the different roles are explained in the respective chapters, there is also quite a bit of detail on how the testing is done at Google. The most interesting part in the chapter on the SET role is the part about the infrastructure. There is (of course) extensive support for running tests automatically. There is common infrastructure for compilation, execution, analysis, storage and results reporting of tests. Tests are categorized as small, medium, large or enormous. Small tests are basically unit tests where everything external is mocked out, and they are expected to execute in less than 100 ms.
Medium tests involve external subsystems, and can use database access, but generally run on one machine (use no network services), and are expected to run in under a second. Large and enormous tests run a complete application, including all external systems needed. They can be nondeterministic because of the complexity, and they are expected to complete in 15 minutes and 1 hour respectively. A good way to summarize them is that small tests lead to code quality, and medium, large and enormous tests lead to product quality. The common test execution environment for running the tests has been developed over time, and has several nice features. It will automatically kill tests that take too long to run (thus the time limits mentioned above).
It has several features to facilitate running many different test concurrently on a machine - it's possible to request an unused port to bind to (instead of a hardcoded port number that could clash with another test), writing to the file system can be done to a temporary location unique to the current test, and private database instance can be created and used to avoid cross talk from other tests. Further, their continuous integration system uses dependency analysis to run only tests affected by a certain change, thus being able to pinpoint exactly which change broke a certain test. This system has been developed by Google for many years, and has become quite capable and tailored to their way of working.
Test Engineer (TE)
The most interesting part in the TE chapter is the description of the process used for developing the test plan for a product. The test plan's purpose is to map out what needs to be tested for the product, and when it is done it should be clear what test cases are needed. It can be a challenge to find the right level of detail for a test plan, but it seems like they have found a good balance at Google.
The Google process for coming up with the test plan is called ACC, which stands for Attribute, Component and Capability. Attributes are the qualities of the product, the key selling points that will get the people to use the product. The examples given for Chrome include fast, secure and stable. There won't typically be that many attributes.
Next, the Components are the major subsystems of the product, around 10 seems to be a reasonable number to include. Finally there are the Capabilities, which are the actions the system can perform for the user. Whereas there are relatively few attributes and components, there can be quite a number of capabilities. The capabilities lie at the intersection of attributes and components. It is natural to create a matrix with attributes along one axis, and components along the other axis. Then each capability will fit in at the given coordinates. A key property for a capability is that it is testable, and each capability will lead to one or more test cases to verify its functionality. Thus the matrix is an aid in enumerating all the test cases that are needed.
The matrix allows you to look at what capabilities affect a certain module. If you look along the other dimension, you will see all capabilities supporting a certain attribute. The matrix is also useful in risk analysis, and when tracking testing progress.
In the same chapter, there is also a good story about a 10-minute test plan. James Whittaker did an experiment where he forced people to come up with a test plan for a product in 10 minutes. The idea was to boil it down to the absolute essentials, without any fluff, but still being useful. Because of the time constraint, most people just made lists or grids - no paragraphs of text. In his opinion (and I agree), this is the most useful level - it is quick to come up with and doesn't need a lot of busy-work filling out sections in a document template, and still it's a useful basis for coming up with test cases. The common theme in all cases was that people based the plan on capabilities that needed testing.
Tools
There are other interesting testing tools described in the book too. One such tool developed at Google is BITE - Browser Integrated Test Environment. When testing a browser-based app, like Google Maps, and something went wrong, there was a lot of information to extract and put into the bug report. For example, what actions lead up to the bug, what version of the software was running, how the bug manifest itself etc. The BITE browser extension keeps track of all the actions the tester made in the application, and supports filing a bug report by automatically including all the relevant information. It also has support for easily marking in a screen shot where the bug appeared.
Another interesting tool is Bots. It involves automatic tests where many different versions of Chrome fetch the top 500 webpages on the web. The resulting HTML is compared and detailed "diff"-reports are produced.
Tips
There was also a sprinkling of interesting ideas (that can definitely be of use in any test organization) throughout the book. Here are the ones that stuck in my head: When asking people to estimate a value for something (for example the frequency of a certain failure scenario), use an even number of values (e.g. rarely, seldom, occasionally, often). That way you can't just pick the middle value - you're forced to think about it more carefully.
Another example in the same area. If you want people's opinion of how likely a certain failure scenario is, you could just ask them about it. But another technique is to assign a value yourself, and then ask what they think. Then you have given them something to argue against. Often, people have an easier time to say what something isn't, then what it is.
There is also a quote from Larry Page that is referred to several times in the book (for example regarding the relatively few testers at Google) "Scarcity brings clarity", and (later on), Scarcity is the precursor of optimization. Worth thinking about.
As well as describing how the testing is done, and which tools are used, there are also a number of interviews with various people in the test organization. The chapter on TEM (Test Engineer Manager) in particular consists almost entirely of interviews, 8 in total. Most interviews in the book were interesting to read, but many of them weren't that useful in terms of tips or ideas to use in your own testing.
The Future of Testing
For me, the best chapter in the book was chapter 5, "Improving How Google Tests Software". It is the last and shortest chapter, only 7 pages. In it, James Whittaker shares some profound insights about testing at Google, and testing in general. One of the flaws he sees with testing is that testers are... testers. They are not part of the product development team. Instead, they exist in their own organization, and this separation of testers and developers gives the impression that testing is not part of the product; it's somebody else's responsibility. Further, the focus of testing is often the testing activities and artifacts (the test cases, the bug reports etc.), not the product being tested. But customers don't care about testing per se, they care about products.
Finally, a lot of the testing mindset we have today developed in a different era. When you released a product, that was it. There was no easy way to upgrade it, and users had to live with whatever bugs slipped through. However, these days so much of the software can be fixed and upgraded without a lot of fuss. In this environment, it makes less sense to have testers act as users and try to discover what bugs they might run into. Instead, you can release the software, and see what bugs the actual users encounter. Then you make sure these bugs are fixed and that the new release is pushed out quickly.
So his opinion is that testing should be the responsibility of all the developers working on the product. It should be their responsibility to test the product and to develop the appropriate tools (with some exceptions, for instance security testing). Whether you agree or disagree with this, it is definitely food for thought!
Conclusion
Initially, when I had just finished reading the book, I felt a little disappointed. It was interesting to read, but there didn't seem to be that much to take away from it and apply to your own testing. Pretty much all of the techniques and tools are tailored for Google and their needs, which is just as it should be. But that means that they may not be applicable to your own situation.
However, as I am going through it again while writing this review, I realize that there are quite a few good ideas in it - they just have to be adapted to your specific situation. So while not directly applicable, the ideas in the book serve as inspirations for how testing can be organized and executed.
It's quite an interesting book, and it makes some great points about the future of testing. However, despite the phrase "Help me test like Google" on the cover, it is not as useful as I had hoped when it comes to improving your own testing.The book starts off by describing the key roles at Google: SWE (Software Engineer), SET (Software Engineer in Test) and TE (Test Engineer). Briefly, the SWE builds features for Google's products, the SET develops testing infrastructure and larger-scale automatic tests, and the TE tests the products from a user's perspective. After the introductory chapter, there is a chapter each on the SET and TE roles, and there is also a chapter on the TEM (Test Engineer Manager) role. The final chapter is about the future of testing at Google (and in general).
Software Engineer in Test (SET)
As the different roles are explained in the respective chapters, there is also quite a bit of detail on how the testing is done at Google. The most interesting part in the chapter on the SET role is the part about the infrastructure. There is (of course) extensive support for running tests automatically. There is common infrastructure for compilation, execution, analysis, storage and results reporting of tests. Tests are categorized as small, medium, large or enormous. Small tests are basically unit tests where everything external is mocked out, and they are expected to execute in less than 100 ms.
Medium tests involve external subsystems, and can use database access, but generally run on one machine (use no network services), and are expected to run in under a second. Large and enormous tests run a complete application, including all external systems needed. They can be nondeterministic because of the complexity, and they are expected to complete in 15 minutes and 1 hour respectively. A good way to summarize them is that small tests lead to code quality, and medium, large and enormous tests lead to product quality. The common test execution environment for running the tests has been developed over time, and has several nice features. It will automatically kill tests that take too long to run (thus the time limits mentioned above).
It has several features to facilitate running many different test concurrently on a machine - it's possible to request an unused port to bind to (instead of a hardcoded port number that could clash with another test), writing to the file system can be done to a temporary location unique to the current test, and private database instance can be created and used to avoid cross talk from other tests. Further, their continuous integration system uses dependency analysis to run only tests affected by a certain change, thus being able to pinpoint exactly which change broke a certain test. This system has been developed by Google for many years, and has become quite capable and tailored to their way of working.
Test Engineer (TE)
The most interesting part in the TE chapter is the description of the process used for developing the test plan for a product. The test plan's purpose is to map out what needs to be tested for the product, and when it is done it should be clear what test cases are needed. It can be a challenge to find the right level of detail for a test plan, but it seems like they have found a good balance at Google.
The Google process for coming up with the test plan is called ACC, which stands for Attribute, Component and Capability. Attributes are the qualities of the product, the key selling points that will get the people to use the product. The examples given for Chrome include fast, secure and stable. There won't typically be that many attributes.
Next, the Components are the major subsystems of the product, around 10 seems to be a reasonable number to include. Finally there are the Capabilities, which are the actions the system can perform for the user. Whereas there are relatively few attributes and components, there can be quite a number of capabilities. The capabilities lie at the intersection of attributes and components. It is natural to create a matrix with attributes along one axis, and components along the other axis. Then each capability will fit in at the given coordinates. A key property for a capability is that it is testable, and each capability will lead to one or more test cases to verify its functionality. Thus the matrix is an aid in enumerating all the test cases that are needed.
The matrix allows you to look at what capabilities affect a certain module. If you look along the other dimension, you will see all capabilities supporting a certain attribute. The matrix is also useful in risk analysis, and when tracking testing progress.
In the same chapter, there is also a good story about a 10-minute test plan. James Whittaker did an experiment where he forced people to come up with a test plan for a product in 10 minutes. The idea was to boil it down to the absolute essentials, without any fluff, but still being useful. Because of the time constraint, most people just made lists or grids - no paragraphs of text. In his opinion (and I agree), this is the most useful level - it is quick to come up with and doesn't need a lot of busy-work filling out sections in a document template, and still it's a useful basis for coming up with test cases. The common theme in all cases was that people based the plan on capabilities that needed testing.
Tools
There are other interesting testing tools described in the book too. One such tool developed at Google is BITE - Browser Integrated Test Environment. When testing a browser-based app, like Google Maps, and something went wrong, there was a lot of information to extract and put into the bug report. For example, what actions lead up to the bug, what version of the software was running, how the bug manifest itself etc. The BITE browser extension keeps track of all the actions the tester made in the application, and supports filing a bug report by automatically including all the relevant information. It also has support for easily marking in a screen shot where the bug appeared.
Another interesting tool is Bots. It involves automatic tests where many different versions of Chrome fetch the top 500 webpages on the web. The resulting HTML is compared and detailed "diff"-reports are produced.
Tips
There was also a sprinkling of interesting ideas (that can definitely be of use in any test organization) throughout the book. Here are the ones that stuck in my head: When asking people to estimate a value for something (for example the frequency of a certain failure scenario), use an even number of values (e.g. rarely, seldom, occasionally, often). That way you can't just pick the middle value - you're forced to think about it more carefully.
Another example in the same area. If you want people's opinion of how likely a certain failure scenario is, you could just ask them about it. But another technique is to assign a value yourself, and then ask what they think. Then you have given them something to argue against. Often, people have an easier time to say what something isn't, then what it is.
There is also a quote from Larry Page that is referred to several times in the book (for example regarding the relatively few testers at Google) "Scarcity brings clarity", and (later on), Scarcity is the precursor of optimization. Worth thinking about.
As well as describing how the testing is done, and which tools are used, there are also a number of interviews with various people in the test organization. The chapter on TEM (Test Engineer Manager) in particular consists almost entirely of interviews, 8 in total. Most interviews in the book were interesting to read, but many of them weren't that useful in terms of tips or ideas to use in your own testing.
The Future of Testing
For me, the best chapter in the book was chapter 5, "Improving How Google Tests Software". It is the last and shortest chapter, only 7 pages. In it, James Whittaker shares some profound insights about testing at Google, and testing in general. One of the flaws he sees with testing is that testers are... testers. They are not part of the product development team. Instead, they exist in their own organization, and this separation of testers and developers gives the impression that testing is not part of the product; it's somebody else's responsibility. Further, the focus of testing is often the testing activities and artifacts (the test cases, the bug reports etc.), not the product being tested. But customers don't care about testing per se, they care about products.
Finally, a lot of the testing mindset we have today developed in a different era. When you released a product, that was it. There was no easy way to upgrade it, and users had to live with whatever bugs slipped through. However, these days so much of the software can be fixed and upgraded without a lot of fuss. In this environment, it makes less sense to have testers act as users and try to discover what bugs they might run into. Instead, you can release the software, and see what bugs the actual users encounter. Then you make sure these bugs are fixed and that the new release is pushed out quickly.
So his opinion is that testing should be the responsibility of all the developers working on the product. It should be their responsibility to test the product and to develop the appropriate tools (with some exceptions, for instance security testing). Whether you agree or disagree with this, it is definitely food for thought!
Conclusion
Initially, when I had just finished reading the book, I felt a little disappointed. It was interesting to read, but there didn't seem to be that much to take away from it and apply to your own testing. Pretty much all of the techniques and tools are tailored for Google and their needs, which is just as it should be. But that means that they may not be applicable to your own situation.
However, as I am going through it again while writing this review, I realize that there are quite a few good ideas in it - they just have to be adapted to your specific situation. So while not directly applicable, the ideas in the book serve as inspirations for how testing can be organized and executed.
January 5, 2013
I learnt about quite a few useful tools, especially pyAuto for driving Chrome automation, as well as Protocol Buffers for creating class definitions and serializing data easily. However, most of the content in this book is more management than technical focused, and would probably benefit someone who is already familiar with the testing scene as it currently is than new readers trying to find ways to improve their software quality.
August 31, 2017
Совершенно неувлекающее чтиво. С началом каждой главы я надеялась, что вот-вот будет что-то полезное, интересное, новое! Но нет. Книга написана 7 лет назад, мир изменился.
Наверное, полезно прочитать людям, которые никогда не сталкивались с тестированием, и вот решили начать. В противном случае вы читаете всё то, о чем и так прекрасно знаете.
Например, в части интервью очень много воды. Здесь мы узнаем, как достичь результата: сначала выполнять более высокоприоритетные задачи, и после этого приступать к низкоприоритетным. Спасибо, книга!
Большая часть книги написана в стиле:
— Скажите, как вам удалось достичь таких высот? У вас была какая-то тактика, и вы ее придерживались?
— У меня была кака-то тактика, и я ее придерживался.
Спасибо, книга!
Есть части в книге, где подробно описан процесс разработки ПО, описаны методы, есть тест-план, его альтернатива, описаны фишечки использования гугловых продуктов, но всю эту полезную информацию можно было уместить на Пятнадцати страницах А4, и не писать книгу, которая хочет засосать вас в болото жвачного чтива.
Наверное, полезно прочитать людям, которые никогда не сталкивались с тестированием, и вот решили начать. В противном случае вы читаете всё то, о чем и так прекрасно знаете.
Например, в части интервью очень много воды. Здесь мы узнаем, как достичь результата: сначала выполнять более высокоприоритетные задачи, и после этого приступать к низкоприоритетным. Спасибо, книга!
Большая часть книги написана в стиле:
— Скажите, как вам удалось достичь таких высот? У вас была какая-то тактика, и вы ее придерживались?
— У меня была кака-то тактика, и я ее придерживался.
Спасибо, книга!
Есть части в книге, где подробно описан процесс разработки ПО, описаны методы, есть тест-план, его альтернатива, описаны фишечки использования гугловых продуктов, но всю эту полезную информацию можно было уместить на Пятнадцати страницах А4, и не писать книгу, которая хочет засосать вас в болото жвачного чтива.
December 19, 2014
This is not a typical book. It has both good and bad.
The good: the level of technical detail, the clarity and the straightforward presentation of the authors. The book painted a picture where SET (software engineer in test) was the best technical job and TE (test engineers) are the best generalist job. (At least from a reader's point of view.) It certainly is encouraging and enlightening, particularly for google engineers.
The bad:
(1) the writing style. Oh my god, the authors have almost no writing style. The whole book reads like a training handout, it has verbatim interviews interspersed in the chapters. Short articles written by SETs, TEs inserted into the text. Long code segments interspersed with cultural discussions. Verbatim copies of blog posts. There is no consistent flow of thoughts. The book seriously lack readability improvement.
(2) the vision itself. All three authors have left Google after this book was published. I cannot help but asking, does the vision stand good with time? or it is just an wishful thinking of the group of engineers at the peak years of the testing effort of Google.
The good: the level of technical detail, the clarity and the straightforward presentation of the authors. The book painted a picture where SET (software engineer in test) was the best technical job and TE (test engineers) are the best generalist job. (At least from a reader's point of view.) It certainly is encouraging and enlightening, particularly for google engineers.
The bad:
(1) the writing style. Oh my god, the authors have almost no writing style. The whole book reads like a training handout, it has verbatim interviews interspersed in the chapters. Short articles written by SETs, TEs inserted into the text. Long code segments interspersed with cultural discussions. Verbatim copies of blog posts. There is no consistent flow of thoughts. The book seriously lack readability improvement.
(2) the vision itself. All three authors have left Google after this book was published. I cannot help but asking, does the vision stand good with time? or it is just an wishful thinking of the group of engineers at the peak years of the testing effort of Google.
October 1, 2014
This was an odd book. It's really 3 things: an internal training manual, a recruiting tool, and an external guide to Google's testing practices. The first two really got in the way of what would have otherwise been a very interesting book.
November 21, 2014
The best book on testing (or "facilitating engineering productivity", as it's known within the book and among the google SETs (software engineers in testing)) I've ever read, though most of this will be old hat to anyone who's digested the lessons of test-driven development. read on the advice of my new manager at google.
February 24, 2018
As a budding Quality Assurance Analyst at a relatively small software company, I decided to give this book a read to get an understanding of how a big company like Google approaches software testing. I found it to full of extremely helpful information and it opened my eyes to how the rest of the tech industry approaches software testing. It goes into detail about how Google ensures that its product line is of the highest quality, featuring the various types of positions in the "Engineering Productivity" department at Google: the Software Engineer in Test, the Test Engineer, and the Test Engineering Manager. The skills and responsibilities for each position is fleshed out in great detail and this book did an excellent job of describing Google's software testing practices in an easy to understand manner. If you're in software testing and are curious about this topic, you won't be disappointed.
November 15, 2017
If you are waiting for tricky testing details, then this book it not what you want.
It is mostly about high-level abstract things, it also contains lots of interviews with Google's top-managers somehow related to testing.
So get ready to learn how Google interviews QAs and how they assign them to projects.
It is mostly about high-level abstract things, it also contains lots of interviews with Google's top-managers somehow related to testing.
So get ready to learn how Google interviews QAs and how they assign them to projects.
May 12, 2014
Must read for everyone whose work related to software testing and quality assurance.
December 25, 2020
I am sort of confused with this book. Of course we should consider the book is dated to some extend, so this is not a clear representation of what Google does now in terms of testing.
I was pleasantly surprised to see that they don't test software as a typical large corp, they a lot of flexibility and fresh ideas. There were many good ideas and observations related to, for ex. test plans and the fact they get obsolete the moment they were written.
The interviews with some lead/management Googlers also were a huge part of insight.
Yet, the book says very little of "how" google performs testing, it's more focused on what practices they do, or what artifacts they produce, or how they split automation effort, which is good but in itself is not testing, it is a support activity arround testing. You will find very little examples of what Google considers excellent testing and how they perform it and it's mainly in the interviews part and in the appendecies.
The conclusion of the book was the part that really disappointed me. In essence, they created this culture of heavy reliance to formally document everything with test cases(which in fact was approach from the 80s that didn't work even back then) and they were "surprised" that it led to testing getting too focused on artifacts and less focused on finding real life bugs. The "solution" that the autors offer is - ditch testers, move to automation, outsource testing to clients and crowd testing. Well this is nor logical, nor meaningful solution of the problem.
Also, in many occasions in the book they mentioned exploratory testing as it was some magical solution to testing, but what they mean insteaed is they are using James Whittaker's rendering of it, which in fact, although interesting, has nothing to do with exploratory testing as it was meant by its creator or the group that studied it, developped it and knows it inside-out. Here it's practically Whittaker's "sitting on the toilet, what does that mean to me" definition of exploratory testing, and again this is not looked into great perspective.
In conclusion reading all this, Google seems to be a great engineering place, they seems to hire very clever and experienced people, some of their leadership stuff looks like someone you will like to learn from, BUT when it comes to testing, they don't seem to know what they are doing and they cover this with large amounts of dubious, shallow programatic checks or tons of user/crowd tests to cover their back.
I was pleasantly surprised to see that they don't test software as a typical large corp, they a lot of flexibility and fresh ideas. There were many good ideas and observations related to, for ex. test plans and the fact they get obsolete the moment they were written.
The interviews with some lead/management Googlers also were a huge part of insight.
Yet, the book says very little of "how" google performs testing, it's more focused on what practices they do, or what artifacts they produce, or how they split automation effort, which is good but in itself is not testing, it is a support activity arround testing. You will find very little examples of what Google considers excellent testing and how they perform it and it's mainly in the interviews part and in the appendecies.
The conclusion of the book was the part that really disappointed me. In essence, they created this culture of heavy reliance to formally document everything with test cases(which in fact was approach from the 80s that didn't work even back then) and they were "surprised" that it led to testing getting too focused on artifacts and less focused on finding real life bugs. The "solution" that the autors offer is - ditch testers, move to automation, outsource testing to clients and crowd testing. Well this is nor logical, nor meaningful solution of the problem.
Also, in many occasions in the book they mentioned exploratory testing as it was some magical solution to testing, but what they mean insteaed is they are using James Whittaker's rendering of it, which in fact, although interesting, has nothing to do with exploratory testing as it was meant by its creator or the group that studied it, developped it and knows it inside-out. Here it's practically Whittaker's "sitting on the toilet, what does that mean to me" definition of exploratory testing, and again this is not looked into great perspective.
In conclusion reading all this, Google seems to be a great engineering place, they seems to hire very clever and experienced people, some of their leadership stuff looks like someone you will like to learn from, BUT when it comes to testing, they don't seem to know what they are doing and they cover this with large amounts of dubious, shallow programatic checks or tons of user/crowd tests to cover their back.
August 29, 2019
In my day-to-day job as a software engineer I constantly encounter new and interesting problems in the realm of testing software. So when I found How Google Tests Software, I was very excited to find out what techniques Google employs to tackle some of these thornier problems at scale.
The opening chapters of the book do a really great job of describing the ethos of testing at Google, and very clearly defining what their goals are and how each of their roles and tools will contribute to that overall goal. Reading through these chapters I found myself chomping at the bit to find the nuggets of wisdom that I could apply in my own work.
However, past the opening chapters, for me the book really started to wane in terms of technical details, and I found myself working harder and harder to find the lessons that I could take away. While I appreciated the author's descriptions of the tools that Google uses internally, the overviews weren't enough for me to determine exactly what about the tools solved their testing problems, and it wasn't enough to really understand how to build a similar infrastructure at my company.
The latter half of the book focused heavily on interview transcripts with testing leaders at Google. While I did appreciate their war stories and takeaways, I felt the interviews didn't have quite enough useful information to justify the amount of space that they took up in the book. Even the last chapter felt like more of an anti-climax rather than a solid wrap-up of the book as a whole.
Overall, I thought the book had a lot of potential, but the pacing issues with the size of each chapter and the dearth of useful technical details really took a lot of the wind out of its sails.
The opening chapters of the book do a really great job of describing the ethos of testing at Google, and very clearly defining what their goals are and how each of their roles and tools will contribute to that overall goal. Reading through these chapters I found myself chomping at the bit to find the nuggets of wisdom that I could apply in my own work.
However, past the opening chapters, for me the book really started to wane in terms of technical details, and I found myself working harder and harder to find the lessons that I could take away. While I appreciated the author's descriptions of the tools that Google uses internally, the overviews weren't enough for me to determine exactly what about the tools solved their testing problems, and it wasn't enough to really understand how to build a similar infrastructure at my company.
The latter half of the book focused heavily on interview transcripts with testing leaders at Google. While I did appreciate their war stories and takeaways, I felt the interviews didn't have quite enough useful information to justify the amount of space that they took up in the book. Even the last chapter felt like more of an anti-climax rather than a solid wrap-up of the book as a whole.
Overall, I thought the book had a lot of potential, but the pacing issues with the size of each chapter and the dearth of useful technical details really took a lot of the wind out of its sails.
June 19, 2018
Bardzo dobra książka opisująca, jak ogólnie wygląda zarządzanie procesem testowym w Google. Znajdziemy tutaj trochę informacji, kim w całym procesie wytwarzania oprogramowania jest tester. Trzeba przyznać, że jego rola znacząco różni się od tego, jak wygląda ta praca w innych firmach wytwarzających oprogramowanie. Głównie dlatego warto jest tę książkę przeczytać. Google jest już jakby stadium końcowym, jak wielka może się stać dana korporacja i z tej perspektywy można się przyjrzeć, jak taki gigant przedefiniowuje procesy i role związane z całym procesem testowym.
This is a really good book that shows us in general how the whole process of managing testing in Google looks like. We can find there some pieces of information about the role of a tester in such an environment and realise that his role significantly differs from the role he has in different companies which create software. Mostly because of this, the book is worth reading. Google is in a way a final stage how the corporation can grow and from this perspective we can see how such a huge company redefines the process and roles connected to the whole process of testing.
This is a really good book that shows us in general how the whole process of managing testing in Google looks like. We can find there some pieces of information about the role of a tester in such an environment and realise that his role significantly differs from the role he has in different companies which create software. Mostly because of this, the book is worth reading. Google is in a way a final stage how the corporation can grow and from this perspective we can see how such a huge company redefines the process and roles connected to the whole process of testing.
January 24, 2021
A book that details how the software giant tests their products at huge scale. It explains what challenges does Google face for their products and features which are running at huge scale and how their test teams overcome them with collaboration with the development team.
The book clearly describes various roles at Google like SWE (Software Engineer), SET (Software Engineer in Test), TE (Test Engineer), TEM (Test Engineering Manager) and Test Engineering Director. This book explains each role in detail and the career path associated with the role. It also explains how test engineers are hired at Google and what qualities in an engineer makes them a good Googler vs not. The book also has excerpts from the interviews that the authors conducted with various SWEs, SETs, TEs, TEMs and Test Engineering Directors. The reader can learn about how engineers in different role come together to test and release a quality product from the organization: Google.
A nice read for test engineers who aspire to join Google and even for who do not want to join Google but understand how to test products which are huge in scale....Google level scale.
The book clearly describes various roles at Google like SWE (Software Engineer), SET (Software Engineer in Test), TE (Test Engineer), TEM (Test Engineering Manager) and Test Engineering Director. This book explains each role in detail and the career path associated with the role. It also explains how test engineers are hired at Google and what qualities in an engineer makes them a good Googler vs not. The book also has excerpts from the interviews that the authors conducted with various SWEs, SETs, TEs, TEMs and Test Engineering Directors. The reader can learn about how engineers in different role come together to test and release a quality product from the organization: Google.
A nice read for test engineers who aspire to join Google and even for who do not want to join Google but understand how to test products which are huge in scale....Google level scale.
March 23, 2021
Отличная книга по тестированию от Гугл для начинающих, продолжающих и освоившихся! Ручное и много автоматизированного тестирования. История и факты про процессы, инструменты, людей, команды и топов в тестировании.
Ставит мозги, утверждает и структурирует собственные догадки и находки. Опровергает ошибочные ожидания.
Много практических советов. Часть советов по инструментам уже успешно попробовал на практике.
Книга про софт, но также важные взаимозависимости и требования к тестированию на различном железе.
Книга уже классика и давно не новая, но все равно сильно рекомендую и для своей команды и организации, всем кто интересуется разработкой программных продуктов, качеством.
Также советую всем новичкам в тестировании как одно из первых пособий по тестированию и вхождению в ИТ.
На русском языке бесплатная электронная версия любезно предоставляется издательством Питер, ссылка в статье на Хабре, https://habr.com/ru/company/piter/blo...
Ставит мозги, утверждает и структурирует собственные догадки и находки. Опровергает ошибочные ожидания.
Много практических советов. Часть советов по инструментам уже успешно попробовал на практике.
Книга про софт, но также важные взаимозависимости и требования к тестированию на различном железе.
Книга уже классика и давно не новая, но все равно сильно рекомендую и для своей команды и организации, всем кто интересуется разработкой программных продуктов, качеством.
Также советую всем новичкам в тестировании как одно из первых пособий по тестированию и вхождению в ИТ.
На русском языке бесплатная электронная версия любезно предоставляется издательством Питер, ссылка в статье на Хабре, https://habr.com/ru/company/piter/blo...
June 21, 2018
Интересная в целом книга про то, как в Google тестировали несколько лет назад. Из полезного — очень много информации о граблях в автотестировании, образцы тест-планов, интересной документации, утилит (некоторые из которых, разумеется, устаревшие) и прочих плюшек.
Понравились главы про mindset в целом, личностные и технические качества тестировщика, его высокую цель и благородную миссию))
Книга скорее про видение профессии и образ мышления с явной hr-составляющей. Много интервью с сотрудниками, некоторые из которых крайне познавательны, некоторые — просто позитивная вода, из серии:
— "Как вы добились успеха в тестировании продукта?"
— "Очень хорошо работал!"
— "А как вы выстраивали процессы в команде?"
— "Сначала было сложно, потом стало полегче, а сейчас еще лучше!"
Но мне в целом книга понравилась; тем, кто хочет расширить кругозор в профессии — я бы смело порекомендовала.
Понравились главы про mindset в целом, личностные и технические качества тестировщика, его высокую цель и благородную миссию))
Книга скорее про видение профессии и образ мышления с явной hr-составляющей. Много интервью с сотрудниками, некоторые из которых крайне познавательны, некоторые — просто позитивная вода, из серии:
— "Как вы добились успеха в тестировании продукта?"
— "Очень хорошо работал!"
— "А как вы выстраивали процессы в команде?"
— "Сначала было сложно, потом стало полегче, а сейчас еще лучше!"
Но мне в целом книга понравилась; тем, кто хочет расширить кругозор в профессии — я бы смело порекомендовала.
February 28, 2024
As a Test Engineer I always thought that Testing statu quo all around the industry was far away from Computer Science creating, naturally, barriers between members of a development team. Although, developers usually don't have a Quality thinking to drive a holistic quality strategy, Testers usually don't have a code mindset either. These gaps frustrate me a lot.
Fortunately, this book was created and despite being 10+ years old, some topics are still valid. The main content that I take for my own personal career are the ones related to test automation strategy, risk analysis, innovation, what to look at when interviewing new peers.
So, if someone feels frustrated with the practices in the Testing industry, I encourage you to have a look at this book to get inspired and steal a couple of core ideas.
Fortunately, this book was created and despite being 10+ years old, some topics are still valid. The main content that I take for my own personal career are the ones related to test automation strategy, risk analysis, innovation, what to look at when interviewing new peers.
So, if someone feels frustrated with the practices in the Testing industry, I encourage you to have a look at this book to get inspired and steal a couple of core ideas.
October 5, 2021
Hm well, this is a bit tricky to rate and to review. Actually the whole book is more or less some kind of manual for the folks of google how to use their tools and how their process actually works out.
The note, that this book is something every new Googler (Noogler) has to read should have raised some alarms, but still it is interesting how testers have a different role their, than I am used to from other companies and projects. Especially the role of the SET (Software Engineer in Test) is a great idea. This way there are real experts that combine both roles and are available for projects that really need a helping hand.
Since I am always in in gamification, the testing game with the rewards is just awesome.
The note, that this book is something every new Googler (Noogler) has to read should have raised some alarms, but still it is interesting how testers have a different role their, than I am used to from other companies and projects. Especially the role of the SET (Software Engineer in Test) is a great idea. This way there are real experts that combine both roles and are available for projects that really need a helping hand.
Since I am always in in gamification, the testing game with the rewards is just awesome.
October 20, 2020
This book provides interesting views into how an organization (Google) worked to introduce more quality into their software development efforts. I particularly enjoyed the interviews with the team tasked with rolling out a new approach to testing within the organization. Tasking a small group of experts to drive a new program (new mindset, new approaches) into an organization is tough. And, getting exposure to how other's have faired is valuable.
Speaking of mindsets, in the spirit of "travelling light" and "delivering value", I also enjoyed the coverage of the Attribute, Component, Capability approach to figuring out and communicating test plans.
Speaking of mindsets, in the spirit of "travelling light" and "delivering value", I also enjoyed the coverage of the Attribute, Component, Capability approach to figuring out and communicating test plans.
December 13, 2017
Una muy buena descripcion de como google hace frente al asunto del testing.
A pesar de eso, senti un poco el hecho de que son Google y hacen todo muy pro y la mayoria no tenemos los recursos ni medios para hacer micjas recomendaciones.
Fuera de eso, da muchas ideas, insights y tips para hacer un mejor proceso de testing.
Aunque, un poco confusa su terminologia para ingenieros, testers, testers ingenieros, y asi...
De nuevo hace hinca pie en que un tester debe saber hacer desarrollo. Estoy de acuerdo con esto.
A pesar de eso, senti un poco el hecho de que son Google y hacen todo muy pro y la mayoria no tenemos los recursos ni medios para hacer micjas recomendaciones.
Fuera de eso, da muchas ideas, insights y tips para hacer un mejor proceso de testing.
Aunque, un poco confusa su terminologia para ingenieros, testers, testers ingenieros, y asi...
De nuevo hace hinca pie en que un tester debe saber hacer desarrollo. Estoy de acuerdo con esto.
January 13, 2019
I was really impressed by the responsibility that Google places on its software engineers for quality. Testing and quality belong to the entire team and not just a few people with the word Quality in their job title.
The end of the book was a surprise. It made me envision a future where quality was just built into the framework for developing applications and not something bolted on at the end. The tools are getting better and the practices are improving to the level that testers can focus on the user experience and not basic correctness.
The end of the book was a surprise. It made me envision a future where quality was just built into the framework for developing applications and not something bolted on at the end. The tools are getting better and the practices are improving to the level that testers can focus on the user experience and not basic correctness.
August 24, 2017
This book is more than 5 years old, and things move fast at a company like Google, so it's a bit outdated already. But looking beyond that, there are moments when teh book gives great insights on how google is doing certain things, and times when you say: I wish we could do the same!
So some good information, but don't expect too much from it. It"'s a rather quick read, and half of the book is interviews with people working at google.
So some good information, but don't expect too much from it. It"'s a rather quick read, and half of the book is interviews with people working at google.
October 30, 2018
This is really a four-star book, but I'm taking off one star because one chapter is more than a hundred pages long, I didn't like the page formatting, and there were more typos than I would like.
It's a pretty interesting book, great to see how Google does things. As I was reading I found myself mentally comparing my current work environment to the one described in the book and thinking about what we could do to improve our software development process.
It's a pretty interesting book, great to see how Google does things. As I was reading I found myself mentally comparing my current work environment to the one described in the book and thinking about what we could do to improve our software development process.
June 16, 2019
Interesting view on how Google did their testing back i 2012. After explaining the roles of Software Engineer in Test (SET) and Test Engineer (TE), explaining the types of tests and the tools they used, they end up saying that their approach presented several problems and they won't stick to it.
The book contains a lot of interviews and some of them are repeating or not interesting.
It's a somewhat obsolete reading, for historical purposes or to have more ideas about testing.
The book contains a lot of interviews and some of them are repeating or not interesting.
It's a somewhat obsolete reading, for historical purposes or to have more ideas about testing.
April 29, 2021
Meh. "Мы делаем хорошо, и не делаем плохо; мы сначала делаем продукт без тестов, но потом их добавляем, но не слишком рано, а то время зря потратим, и не слишком поздно, а то невозможно будет поддерживать." Ок, понял, спасибо.
Может я просто не очень глубоко погружен в тестирование. Иначе я никак не могу объяснить, почему книга показалась мне собранием очевидных советов, жестко Google-специфичных штук, и разговоров за жизнь.
Может я просто не очень глубоко погружен в тестирование. Иначе я никак не могу объяснить, почему книга показалась мне собранием очевидных советов, жестко Google-специфичных штук, и разговоров за жизнь.
August 7, 2018
An overview of testing processes in google, mostly about test-management.
From the first view I liked the book, but now when I think about it more, I see more weak places.
Though I find it useful as you can review & compare your testing/managing process.
From the first view I liked the book, but now when I think about it more, I see more weak places.
Though I find it useful as you can review & compare your testing/managing process.
March 28, 2021
A lot of the testing techniques would be difficult to implement without total company buy-in, but there were useful tips for coming at testing from different directions and finding your higher-risk areas.
June 14, 2021
Running tests should be like video games, and bugs are like over-parented kids - two big takeaways. Lots of other nuggets of wisdom, some dated but most quite applicable, especially enumerating the risk of every feature.
Read
January 1, 2022Не стала дочитывать. В большей степени книга про то, как всё у Гугла организовано. Интерес представляет больше с менеджерсткой точки зрения, чем с технической. Сейчас для меня это оказалось не актуальным.
January 16, 2024
Poorly written with too many repetitive meanderings about testing culture within google. But I still got some value out of reading between the lines. There are some good coverage around taxonomies for testing as career path but I am not the target audience.
August 2, 2017
I liked the real life examples of how the google engineers use their phones with the latest incremental release of android.
Displaying 1 - 30 of 87 reviews