Coming into this I was expecting a relatively technical book on testing; specifically where Google finds it's unique niche in that realm. I was surprised to find out (very quickly) that this book is focussed much more on testing as a culture and as a mindset. This opens it up to be a book I'd recommend even to non-technical folks if they are in a software company.
The authors start with the overall path that Google had taken to get to the point they are with testing starting with no testers and quickly realizing that wasn't sustainable when they had become a verb rather than a proper noun. They then quickly jump into the roles that have developed into their idea of the "testers". A key point throughout the book is the reliance on keeping the "test team" in an organization small to focus resources on where they are really needed.
They spend a good majority of the book discussing the specific roles they have created in their organization for testers and what those specific roles do throughout the day.
Software Engineer in Test
These are the testers that are still writing code the majority of their time. They spend their time building tools, patterns, and systems that can be used to make the product engineers more productive and more willing to test their own software. Essentially, their job is making it easy for the software engineers to do the right thing and test their code. This can come in the form of creating test stubs that numerous teams use across the organization, build systems that automate away some of the infrastructure for running tests, etc.
The Test Engineer
The TE is an engineer that is as much in-tune with testing as in-tune with the product teams and the customers. They are the "pulling it all together" engineers. They make sure users flows are not broken, that risk areas are being tested, and that users are being looked after (usability, accessibility, etc.). They are a step further away from the software engineers than the Software Engineers in Test, but are very much in-tune with the products and the future vision.
They discuss a point that I found interesting here. The mention of agile methodologies doing away with much of what we used to think of as the "testing" phase. Since we now have the deployment capabilities to send a product to only small subsets of customers for testing (whether beta testers or real-world). Nothing specific to apply because of this, but worth considering. I hadn't thought about it much thus far. As we get further in this direction, it will be interesting to see how this mindset affects any role that we consider a test role.
In the final chapters of the book, the authors discuss the future of testing. A key point that very much summarizes the book and it's core idea is that they believe the "software engineer in test" will become a things of the past. They believe that the all testing will simply be a job requirement of the software engineer. That it will be so embedded in the culture that there won't have to be a separate title for it. This has been the direction they are seemingly headed and truly believe.
Overall, this was a good read. I'm not sure I come away with it with any specific thoughts or changes that should or could be made in my workplace, but I do think the thoughts and ideas expressed here are worth considering and instilling in a company culture.
It will be interesting to see in the coming years and decade what the role of a tester does become. Will we have them? I think so. As I think the authors would agree, there will always be a need for exploratory testing. Someone to side on behalf of users no matter how early in the process users choose to be involved.