How Google Tests Software

For the past few years, I've made sure to take a few extra weeks off around the Christmas holidays to brush up on my skillset, do a bit of research on new technologies coming out, and try to get in shape -- software testing wise -- for the new year. Back in 2013 I kept hearing of one particular book that had been published the year before: How Google Tests Software.

I found the book to be interesting, but I wondered if it was entirely relevant. It talked about lessening the importance of traditional quality assurance engineers  and having the focus being on the software developers. Software Developers in Test (SET) to examine code quality, writing code 100% of the time. Then there were Test Engineers (TE) who write automated test scripts that would mimic how an end user would use the product. Where would they find all those software developers who actually wanted to stick with QA?, I thought.


For most of my career, QA Engineers didn't need to know how to code. Sure, it helped, especially doing database testing with SQL -- or if you had managed to get hands-on experience with the expensive automation testing toolsets such as Segue Software's Silk Test (Purchased by Borland in 2006), or Mercury Interactive's testing toolset (Purchased by Hewlett-Packard in 2006) or even Rational Software's Rational Rose (purchased by IBM in 2003) -- but coding wasn't something you used on a day-to-day basis.

Being a QA Engineer used to mean that you simply needed tech writing skills... maybe some critical analysis. Have both creative and logical thinking. Know all the ins and outs of the software development process. Work well with developers. Develop models of how the software works and find possible weak points. Write thorough test scripts in MS Word or MS Excel. And with Agile catching on, you had to be very good at what you did, because you had to force all this process into two week sprints.

When working well, it was a very symbiotic relationship between Developer and QA. Two distinct mind sets: One of creation, and one of examination, but not like the relationshop between an artist and an art critic. It was more like the relationship between a writer and a copyeditor. The developer focuses on the technology. The QA Engineer focuses on the business requirements and the end user.

I never thought one book could change a field so drastically in such a short period of time.

The premise of the book was that quality wasn't some other department's responsibility... it was the software development's job. "Quality is a Development Issue, not a testing issue". It talked about having a Software Developer in Test who could:

• Go through the same questioning and examiniation process a traditional QA Engineer would go through
• Be able to correct code that could be improved, such as having functions that are given vague names. 
• Be able to refactor code that isn't testable
• Try to focus on 100% test coverage, coming up with an automation plan
• Look at poorly written APIs and rewrite them 
• Be able to code with fluency in C++, Java, Python, and JavaScript 

With the Test Engineer, this was someone who:

• Is more of a "user-developer" where they try to keep the end user of the product in mind.
• They don't code as as much as the Software Developer in Test, but they need some fluency.  
• They implement the automation plan and write the test scripts.

After reading this book, and seeing it mentioned more and more in the tech blogs, I was quite worried. What if this catches on? All of my experience would be obsolete.

The following year, I made sure to gain exposure to the automated testing world at my company.

-T.J. Maher
 Sr. QA Engineer
 Quincy, MA