- File Size: 26069 KB
- Print Length: 315 pages
- Simultaneous Device Usage: Up to 5 simultaneous devices, per publisher limits
- Publisher: Addison-Wesley Professional; 1 edition (March 21, 2012)
- Publication Date: March 21, 2012
- Sold by: Amazon.com Services LLC
- Language: English
- ASIN: B007MQLMF2
- Text-to-Speech: Enabled
- Word Wise: Not Enabled
- Lending: Not Enabled
- Amazon Best Sellers Rank: #387,621 Paid in Kindle Store (See Top 100 Paid in Kindle Store)
How Google Tests Software 1st Edition, Kindle Edition
Use the Amazon App to scan ISBNs and compare prices.
The Amazon Book Review
Book recommendations, author interviews, editors' picks, and more. Read it now
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Customers who bought this item also bought
About the Author
Jason Arbon is a test engineer at Google and has been responsible for testing Google Desktop, Chrome, and Chrome OS. He also served as development lead for an array of open-source test tools and personalization experiments. He worked at Microsoft prior to joining Google.
Jeff Carollo is a software engineer in test at Google and has been responsible for testing Google Voice, Toolbar, Chrome, and Chrome OS. He has consulted with dozens of internal Google development teams helping them improve initial code quality. He converted to a software engineer in 2010 and leads development of Google+ APIs. He also worked at Microsoft prior to joining Google."
--This text refers to an alternate kindle_edition edition.
Would you like to tell us about a lower price?
There was a problem filtering reviews right now. Please try again later.
If you are thinking about purchasing this book, look at the preview first. It might be easy to read on a Kindle or IPad.
This is not an original printing of the book. It seems like someone scanned the book and printed it on the wrong sized paper (including a blurry, stretched cover). From reading other comments it sounds like I am not the only one that has received a bootleg copy of this book.
The argument is aligns well with the movement toward agile software development methods. The book goes on to breakdown testing responsibilities for software engineers (SWEs), software engineers in a test role (SETs), and Test Engineers (TEs). Almost half of the book deals with the roles and responsibilities of the TE, and in the Google model, they do have a higher-level role in testing. In essence, it breaks down like this:
* SWEs write unit tests for the software they write
* SETs write tools to enable testing without external dependencies and write automated functional tests
* TEs coordinate the overall testing activities for a product and focus on the user by doing exploratory testing
In addition, the book also outlines a number of tools (many of which have been open-sourced) that Google uses for testing in the context of these roles. The majority of the content focuses on web applications (it's Google after all), and some of the ideas won't apply if the majority of your development is for internal customers to your company - since you probably have user training and rules about frequency of release. However, I would say that you could apply 80% of the ideas in any context and probably adapt at least 10% (if not more) of the others to your situation.
Also, there is also a chapter on test managers and directors that has interviews with a number of prominent Googlers. Then, the book ends with a discussion on the future of the SET and TE roles at Google along with some of the errors Google made.
Google embarked on the transformation in 2007, and my company is currently trying to do something similar. I hope to be able to leverage these ideas in the months ahead. I recommend it to anyone who is or expects to be involved in such a change. I would also recommend it to any tester in an agile development shop. You may not agree with everything in the book, but tells of the future (if not the present) for much of the software testing industry.
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 hope for testers is that they will be more of a user advocate than a button masher.
Top international reviews
It has made me aware of a number of tools and techniques that could be used in testing.
Will hopefully try some of the ideas, albeit on a smaller scale.
Je pense que c'est un bon livre avec lequel on apprend des techniques et une organisation des tests qui ont du sens.
Cependant je suis très déçu du format et de la qualité du livre lui-même
Cela ressemble a une édition pirate comme on peut en trouver en Chine. La photo de couverture est d'une qualité plus que médiocre et le contenu est en A5 mais imprimé sur des pages A4. On se retrouve avec une petite écriture et un enorme bord vide tout autour qui ne sert à rien. C'est vraiment dommage.
The issue that I had with most, nearly all of them was: Why start testing at the end?
Why not prevent defects instead of having to find them? And be made responsible in case, they slipped through.
This book is different, like the company.
They try to catch a defect before it can make its way to the code, they will rather put off functionality, if it is not properly tested, and so on.
All things, that I personally think, make so much sense, and which are not followed by the PMs and Devs of the current business.
As I said before, this book is my favorite at least for this year. If not for the decade.
It motivated me to get back to programming, to be able to facilitate automatic testing to the dev people to overcome the pain for them. Great!
Dieses Buch zeigt, wie man heute Software testen sollte, welche Skills und Rollen man wirklich benötigt, und wie die Denkweise über "Qualitätssicherung und Test" bei der Software-Entwicklung sein sollte.
Bei Google produziert man mehr Software mit mehr Entwicklern und mehr Teams als vermutlich sonst irgendwo in einem Unternehmen und hat sich darüber viele Gedanken gemacht und über Jahre das Testen von Software optimiert. Ob Google das heute noch alles so macht (das Buch stammt aus 2012), kann ich nicht beurteilen, aber das Niveau gilt es für jedes Software-Team anzustreben - wobei sich nicht alle Themen in kleineren Software-Projekten anwenden lassen.
Wer sollte das lesen?
a) Projektleiter, die Software-Entzwicklungsteams leiten
b) Software-Entwickler, die Qualität während der konstruktiven Entwicklung in ihr Produkt/Projekt anstreben
c) Test-Engineers und solche die sich vom nörgelnden Klick-Tester weiter entwicklen wollen
Testmethoden oder Testwerkzeuge sind nicht das Thema des Buches und werden deshalb höchstens erwähnt. Eine Ausnahme ist ACC (attributes, components, capabilities), dem die Autoren einige Seiten spendiert haben.
I wasn't a big fan of this book. The forward and intro started very strong. I was elated with the little bit in the beginning that talks about good "Code Hygene", but then there's the admission that Google uses this book for "Noogler orientation" (why is this not noted on the book synopsis?), and the last half of the book is padded with several interviews with Googlers that just seemed to add more opinion than fact at the back of the book. Fluff. Lots of it.
It's not all bad though. If you are working at the scale of Google, this book explains the org chart and relationship of SWE, SET, TE, TEM's. I found this interesting (the first couple chapters), but I'm working with teams of 20, not 200! As a long-time developer already performing automated testing, there was nothing in this book that I can take and apply in my daily work.